Promise, DMA and RAID5 problems running 2.4.1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
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 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
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=",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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
"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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
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 --- pdc202xx.c.old Fri Jul 28 21:08:30 2000 +++ pdc202xx.c Fri Feb 9 09:08:55 2001 @@ -747,14 +747,11 @@ { unsigned long high_16 = pci_resource_start(HWIF(drive)->pci_dev, 4); byte udma_speed_flag= inb(high_16 + 0x001f); - int i = 0; OUT_BYTE(udma_speed_flag | 0x10, high_16 + 0x001f); - ide_delay_50ms(); - ide_delay_50ms(); + mdelay(100) OUT_BYTE(udma_speed_flag & ~0x10, high_16 + 0x001f); - for (i = 0; i < 40; i++) - ide_delay_50ms(); + mdelay(2000); /* 2 seconds ?! */ } unsigned int __init pci_init_pdc202xx (struct pci_dev *dev, const char *name) @@ -767,7 +764,6 @@ if ((dev->device == PCI_DEVICE_ID_PROMISE_20262) || (dev->device == PCI_DEVICE_ID_PROMISE_20265) || (dev->device == PCI_DEVICE_ID_PROMISE_20267)) { - int i = 0; /* * software reset - this is required because the bios * will set UDMA timing on if the hdd supports it. The @@ -779,11 +775,9 @@ */ OUT_BYTE(udma_speed_flag | 0x10, high_16 + 0x001f); - ide_delay_50ms(); - ide_delay_50ms(); + mdelay(100); OUT_BYTE(udma_speed_flag & ~0x10, high_16 + 0x001f); - for (i=0; i<40; i++) - ide_delay_50ms(); + mdelay(2000); /* 2 seconds ?! */ } if (dev->resource[PCI_ROM_RESOURCE].start) {