I just built a system that uses a K7V motherboard with the KT133
chipset. It has an onboard Promise PDC20265 ATA-100 controller. Im
running RH6.2.
I built a 2.4.1 kernel with support for the controller and it booted up
fine with the "ide=reverse" parameter. It was when I tried adding new
drives (all IBM-DTLA307045 s) that I realised that the cylinder/head
translation is different and I cant use the whole drive unless its
partitioned while attached to the other IDE ports.
The only option was to attach it to the normal ports and move the drive
back after partitioning. I dont see any jumpers or BIOS options to
change this so it must be a kernel setting, but I dont see anythere
there.
Second, I set up raid mirroring for 4 drives(2 raid, 2spare). Since one
drive isnt available yet, one of the 2 raid partitions are set as
'failed-disk'. All drives are connected to the ATA-100 controller. This
worked fine and I could even boot off of /dev/md0 until I setup raid5.
The main problem started after I setup raid5 on the remaining space
(3raid, 1spare), total space of about 82GB. One of the 3 raid disks were
set to failed, so it included the spare in the array and continued
reconstruction.
After doing hdparm -tT /dev/md4 a couple of times or transfering data to
it, I get the following message:
hda: dma_intr: bad DMA status
hda: dma_intr: status=0x50 { DriveReady SeekComplete }
hda: dma_intr: bad DMA status
hda: dma_intr: status=0x50 { DriveReady SeekComplete }
hda: dma_intr: bad DMA status
hda: dma_intr: status=0x50 { DriveReady SeekComplete }
hda: dma_intr: bad DMA status
hda: dma_intr: status=0x50 { DriveReady SeekComplete }
hda: DMA disabled
hdb: DMA disabled
and the system freezes completely. I have no option, but to do a cold
reboot.
Without DMA support, everything is fine, but hdparm gives me a mere 8.xx
MB/s transfer rate.
Anyone else have very similar problems?
A.Sajjad Zaidi
On 7 Feb 01 at 19:12, A.Sajjad Zaidi wrote:
> I just built a system that uses a K7V motherboard with the KT133
> chipset. It has an onboard Promise PDC20265 ATA-100 controller. Im
> running RH6.2.
>
> hda: dma_intr: bad DMA status
> hda: dma_intr: status=0x50 { DriveReady SeekComplete }
> hda: dma_intr: bad DMA status
> hda: dma_intr: status=0x50 { DriveReady SeekComplete }
> hda: dma_intr: bad DMA status
> hda: dma_intr: status=0x50 { DriveReady SeekComplete }
> hda: dma_intr: bad DMA status
> hda: dma_intr: status=0x50 { DriveReady SeekComplete }
> hda: DMA disabled
> hdb: DMA disabled
>
> and the system freezes completely. I have no option, but to do a cold
> reboot.
It is known bug which I reported to Andre already. Open
drivers/ide/ide.c in favorite text editor, and replace strange
body of ide_delay_50ms() with simple mdelay(50). Promise driver
invokes ide_delay_50ms with interrupts disabled, so it freezes
here forever. If you have NMI watchdog, you'll get nice oopses.
As for DMA failure itself, I have no idea what is wrong in your
case, but I found that mine Promise works with Linux only iff there
is master on each channel, slave alone does not work. And I did not
tried master+slave together.
Petr Vandrovec
[email protected]
> It is known bug which I reported to Andre already. Open
> drivers/ide/ide.c in favorite text editor, and replace strange
> body of ide_delay_50ms() with simple mdelay(50). Promise driver
> invokes ide_delay_50ms with interrupts disabled, so it freezes
> here forever. If you have NMI watchdog, you'll get nice oopses.
Its a bug in the promise driver. ide_delay_50ms() is being friendly to the
rest of the box. If the reset path for the promise cant be polite then it
should use mdelay() itself.
On 7 Feb 01 at 19:33, Alan Cox wrote:
> > It is known bug which I reported to Andre already. Open
> > drivers/ide/ide.c in favorite text editor, and replace strange
> > body of ide_delay_50ms() with simple mdelay(50). Promise driver
> > invokes ide_delay_50ms with interrupts disabled, so it freezes
> > here forever. If you have NMI watchdog, you'll get nice oopses.
>
> Its a bug in the promise driver. ide_delay_50ms() is being friendly to the
> rest of the box. If the reset path for the promise cant be polite then it
> should use mdelay() itself.
Iff CONFIG_BLK_DEV_IDECS is set then yes, doing schedule is better.
But I do not see any benefit in doing
unsigned long timeout = jiffies + ((HZ + 19)/20) + 1;
while (0 < (signed long)(timeout - jiffies));
over
mdelay(50);
And on my box, busy while loop is executed, not schedule(HZ/20)...
Thanks,
Petr Vandrovec
[email protected]
> Iff CONFIG_BLK_DEV_IDECS is set then yes, doing schedule is better.
> But I do not see any benefit in doing
>
> unsigned long timeout = jiffies + ((HZ + 19)/20) + 1;
> while (0 < (signed long)(timeout - jiffies));
On that bit we agree.
On Wed, 7 Feb 2001, Alan Cox wrote:
> > Iff CONFIG_BLK_DEV_IDECS is set then yes, doing schedule is better.
> > But I do not see any benefit in doing
> >
> > unsigned long timeout = jiffies + ((HZ + 19)/20) + 1;
> > while (0 < (signed long)(timeout - jiffies));
>
> On that bit we agree.
What do you want fixed?
Send a patch and lets try it....
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035 Web: http://www.aslab.com
Mark Hahn wrote:
> > drives (all IBM-DTLA307045 s) that I realised that the cylinder/head
> > translation is different and I cant use the whole drive unless its
> > partitioned while attached to the other IDE ports.
>
> no, it's just that the bios doesn't perform the LBA geometry lie
> outside the hd[abcd].
Hmm, thats weird, because hd[abcd] were the ones without the LBA geometry.
Maybe it was because ide was reversed (ide=reverse lilo parameter).
> boot with hde="6666,255,63" (or whatever).
Thanks, I was searching for something like that.
> > Second, I set up raid mirroring for 4 drives(2 raid, 2spare). Since one
> > drive isnt available yet, one of the 2 raid partitions are set as
> > 'failed-disk'. All drives are connected to the ATA-100 controller. This
>
> do you understand that you can't really have raid on ide involving
> two drives on the same channel?
Is that just because of performance or are there other problems? Its working
fine as it is, but Im considering setting up all drives as masters (2x
ATA-100, 2x ATA-66).
"A.Sajjad Zaidi" wrote:
> > do you understand that you can't really have raid on ide involving
> > two drives on the same channel?
>
> Is that just because of performance or are there other problems? Its working
> fine as it is, but Im considering setting up all drives as masters (2x
> ATA-100, 2x ATA-66).
It's because IDE is a blocking bus - each drive must complete its' task before
the data bus is released for the next IO operation. So, the first drive will
finish writing to the disk before the second drive can start. (That's one
reason why SCSI is preferred for high end systems - you can "disconnect" from
an IO operation to allow other IO's to be sent to other devices on the same
bus)
--
Stephen Wille Padnos
Programmer, Engineer, Problem Solver
[email protected]
Petr Vandrovec wrote:
> It is known bug which I reported to Andre already. Open
> drivers/ide/ide.c in favorite text editor, and replace strange
> body of ide_delay_50ms() with simple mdelay(50). Promise driver
> invokes ide_delay_50ms with interrupts disabled, so it freezes
> here forever. If you have NMI watchdog, you'll get nice oopses.
>
> As for DMA failure itself, I have no idea what is wrong in your
> case, but I found that mine Promise works with Linux only iff there
> is master on each channel, slave alone does not work. And I did not
> tried master+slave together.
> Petr Vandrovec
> [email protected]
Ok, I changed ide.c and stopped getting the freeze, but bad DMA status errors
were still showing up.
Then I connected all the drives as masters (2x ATA-100, 2x ATA-66) and havent
gotten anything yet. Buffered disk reads are still about 36.50 MB/sec on the
raid5 device, so its fast enough for what I need.
Next step is to see how well Reiserfs works here.
Thank you everyone who has helped.
A.Sajjad Zaidi
On Wed, Feb 07, 2001 at 12:53:36PM -0800, Andre Hedrick wrote:
> On Wed, 7 Feb 2001, Alan Cox wrote:
>
> > > Iff CONFIG_BLK_DEV_IDECS is set then yes, doing schedule is better.
> > > But I do not see any benefit in doing
> > >
> > > unsigned long timeout = jiffies + ((HZ + 19)/20) + 1;
> > > while (0 < (signed long)(timeout - jiffies));
> >
> > On that bit we agree.
>
> What do you want fixed?
> Send a patch and lets try it....
How about this?
--
Vojtech Pavlik
SuSE Labs