ide/dma not working from 2.6.19 to 2.6.21

Hi,

I have a PCI Promise TX2 Ultra133 controller with a harddisk on an ARM platform (which is a barebone system with no BIOS). This setup used to work with the old linux-ide drivers on 2.6.19 but it does not work with 2.6.22-rc4, or 2.6.21. Here's the error output:

PDC20269: chipset revision 2
<6>PDC20269: ROM enabled at 0xa0210000
PDC20269: ROM enabled at 0xa0210000
PDC20269: PLL input clock is 37736 kHz
PDC20269: PLL input clock is 37736 kHz <6>PDC20269: 100% native mode on irq 84
PDC20269: 100% native mode on irq 84
<7>PCI: Enabling bus mastering for device 0000:07:01.0
<6> ide0: BM-DMA at 0x90050040-0x90050047 ide0: BM-DMA at
0x90050040-0x90050047, BIOS settings
: hda:pio, hdb:pio, BIOS settings: hda:pio, hdb:pio

<6> ide1: BM-DMA at 0x90050048-0x9005004f ide1: BM-DMA at
0x90050048-0x9005004f, BIOS settings
: hdc:pio, hdd:pio, BIOS settings: hdc:pio, hdd:pio

<7>Probing IDE interface ide0...
hda: HDS728080PLAT20, hda: HDS728080PLAT20, ATA DISK drive ATA DISK drive
<4>Warning: Primary channel requires an 80-pin cable for operation.
Warning: Primary channel requires an 80-pin cable for operation. <4>hda reduced to Ultra33 mode.
hda reduced to Ultra33 mode.
ide0 at 0x90050050-0x90050057,0x90050062 on irq 84ide0 at 0x90050050-0x90050057,0x90050062 on irq 84

<7>Probing IDE interface ide1...
<7>Probing IDE interface ide1...
<6>hda: max request size: 512KiB
hda: max request size: 512KiB
<4>hda: lost interrupt
hda: lost interrupt
<4>hda: lost interrupt
hda: lost interrupt
<4>hda: lost interrupt
hda: lost interrupt
<6>hda: 160836480 sectors (82348 MB)hda: 160836480 sectors (82348 MB) w/1719KiB Cache w/1719KiB Cach
e, CHS=16383/255/63, CHS=16383/255/63, UDMA(33), UDMA(33)

<4>hda: lost interrupt
hda: lost interrupt
<6>hda: cache flushes supported
hda: cache flushes supported
<6> hda: hda:<4>hda: dma_timer_expiry: dma status == 0x21 <4>hda: dma_timer_expiry: dma status == 0x21 <4>hda: DMA timeout error
hda: DMA timeout error
hda: dma timeout error: status=0x51 { hda: dma timeout error:
status=0x51 { DriveReady DriveReady Se
ekComplete SeekComplete Error Error }
}
hda: dma timeout error: error=0x84 { hda: dma timeout error:
error=0x84 { DriveStatusError DriveStat
usError BadCRC BadCRC }}

ide: failed opcode was: ide: failed opcode was: unknown unknown
<4>hda: lost interrupt
hda: lost interrupt

On 2.6.21 I have been using:
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y

On 2.6.19 I have exactly the same but also:

CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_AUTO=y

Could this have caused a problem?

Does IDE support in linux depend on certain BIOS settings or any other motherboard specific details? I am asking because neither the new ata nor the old ide layer worked for the cards I tried on ARM (JMB363, IT8212, Promise TX2 133 -> worked only with 2.6.19 old ide layer).

Finally is there a simplest, known-to-work pci ide controller you can suggest? So that I can start looking from there.

Thank you,
Bahadir

Hello.

You were very lucky then bacause actually it usually failed on anything
non-x86. ;-)

I guess this might be related to the driver update in 2.6.20-rc1 then -- I
made the driver calibrate the chip's PLL, so that it might work for non-x86 case too (where Promise BIOS isn't available to do this). The code is basically the same as in the libata's pata_2027x driver...

Hm, why all the messages are printed twice? :-O (I'll cut out the dupes to save bandwidth).

37.736 MHz is a pretty strange PLL clock... Basically, it's the halved PCI
clock, and that value signifies your PCI is probably running at 75 MHz -- which is serious overclocking... :-/
That could explain why the driver managed to work before -- the default
DPLL settings fit for 66 MHz PCI but made the UltraDMA fail with CRC errors on the plain 33 MHz PCI, IIRC...
I may suggest replacing #undef DEBUG by #define DEBUG in this driver,
rebuilding the kernel and posting the driver's output...

Oh, now I understand why it used to work for you before 2.6.20 -- UltraDMA
only failed with 80-conductor cable on non-x86. :-)
Have you been using the 40-conductor cable all the time?

Hm, that's interesting -- I'm not sure how the driver rewrite could have
affected the interrupt delivery for PIO commands (there's no prior "DMA interrupt recovery" messages). Might be some other issue here...

This is too familiar -- that's how the driver used to behave on

No.

As for the Promise -- it used to before 2.2.20-rc1, and it shouldn't since.

Your Promise card should actually be working...

MBR, Sergei

...non-x86 targets before the 2.6.20-rc1 change -- although it usually
exhibited it on higher speeds until the IDE core fekk back to UltraATA/33 or /44, then it started to work...

I meant "used to depend on BIOS settings" here.

MBR, Sergei

I don't know whether this is related or not. Recently I noticed that the PLL clock being detected higher than expected as 20MHz on my box. (It used be 16.6 MHz since my PCI bus is running at 33MHz...)

Reloading the pata_pdc2027x module then the problem goes away. I guess maybe somehow mdelay() is not as precise as before...

--
albert

(dmesg attached for reference)
The PLL clock is wrongly detected as 20MHz on my box, kernel 2.6.22-rc3.

[ 5545.255266] pata_pdc2027x 0000:02:05.0: version 0.9
[ 5545.255489] ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
[ 5545.374703] pata_pdc2027x 0000:02:05.0: PLL input clock 20027 kHz
[ 5545.404872] scsi2 : pata_pdc2027x
[ 5545.430357] scsi3 : pata_pdc2027x
[ 5545.433338] ata3: PATA max UDMA/133 cmd 0xe09897c0 ctl 0xe0989fda bmdma 0xe0989000 irq 0
[ 5545.433671] ata4: PATA max UDMA/133 cmd 0xe09895c0 ctl 0xe0989dda bmdma 0xe0989008 irq 0
[ 5545.916581] ata3.00: ATAPI, max UDMA/33
[ 5545.916590] ata3.01: ATAPI, max UDMA/33
[ 5546.080361] ata3.00: configured for UDMA/33
[ 5546.244197] ata3.01: configured for UDMA/33
[ 5546.410493] scsi 2:0:0:0: CD-ROM            LITE-ON  CD-RW SOHR-5238S 4S07 PQ: 0 ANSI: 5
[ 5546.437658] scsi 2:0:1:0: CD-ROM            HL-DT-ST DVDRAM GSA-4163B A105 PQ: 0 ANSI: 5
[ 5546.604481] sr0: scsi3-mmc drive: 52x/52x writer cd/rw xa/form2 cdda tray
[ 5546.604808] Uniform CD-ROM driver Revision: 3.20
[ 5546.607596] sr 2:0:0:0: Attached scsi CD-ROM sr0
[ 5546.612168] sr1: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
[ 5546.614075] sr 2:0:1:0: Attached scsi CD-ROM sr1
[ 5640.334685] ata3.00: disabled
[ 5640.334695] ata3.01: disabled
[ 5640.403451] ACPI: PCI interrupt for device 0000:02:05.0 disabled

==============================================================================================
The PLL clock clock is correct after rmmod and reload the module:

[ 5644.153643] pata_pdc2027x 0000:02:05.0: version 0.9
[ 5644.153723] ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
[ 5644.252954] pata_pdc2027x 0000:02:05.0: PLL input clock 16714 kHz
[ 5644.303470] scsi4 : pata_pdc2027x
[ 5644.319285] scsi5 : pata_pdc2027x
[ 5644.321207] ata5: PATA max UDMA/133 cmd 0xe09897c0 ctl 0xe0989fda bmdma 0xe0989000 irq 0
[ 5644.321215] ata6: PATA max UDMA/133 cmd 0xe09895c0 ctl 0xe0989dda bmdma 0xe0989008 irq 0
[ 5644.803308] ata5.00: ATAPI, max UDMA/33
[ 5644.803629] ata5.01: ATAPI, max UDMA/33
[ 5644.967144] ata5.00: configured for UDMA/33
[ 5645.130975] ata5.01: configured for UDMA/33
[ 5645.287539] scsi 4:0:0:0: CD-ROM            LITE-ON  CD-RW SOHR-5238S 4S07 PQ: 0 ANSI: 5
[ 5645.291669] sr0: scsi3-mmc drive: 52x/52x writer cd/rw xa/form2 cdda tray
[ 5645.294295] sr 4:0:0:0: Attached scsi CD-ROM sr0
[ 5645.300189] scsi 4:0:1:0: CD-ROM            HL-DT-ST DVDRAM GSA-4163B A105 PQ: 0 ANSI: 5
[ 5645.305716] sr1: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
[ 5645.306736] sr 4:0:1:0: Attached scsi CD-ROM sr1

[albertcc@p4ht-s june_2007]$

It's not the most accurate of things once power management and the like get invovled. HT doesn't help it either. You should have get much more accurate timing information if you query gettimeofday before/after and do a few loops.

Alan

Thanks for the advice. Patch to follow.

--
albert

Recently the PLL input clock of pata_pdc2027x is sometimes detected higer than expected (e.g. 20.027 MHz compared to 16.714 MHz). It seems sometimes the mdelay() function is not as precise as it used to be. Per Alan's advice, HT or power management might affect the precision of mdelay().

This patch calls gettimeofday() to mesure the time elapsed and calculate the PLL input clock accordingly.

---

Did more test. For mdelay(100) the usec_elapsed is usually 99287. However, sometimes the usec_elapsed is 118934, longer than expected.

Jun 26 12:12:29 p4ht-s kernel: [ 9156.490991] ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
Jun 26 12:12:29 p4ht-s kernel: [ 9156.610175] usec_elapsed[118934]
Jun 26 12:12:29 p4ht-s kernel: [ 9156.610511] pata_pdc2027x 0000:02:05.0: PLL input clock 16817 kHz

After the patch, the PLL input clock detected looks more accurate. For your review, thanks.

diff -Nrup 00_libata-dev/drivers/ata/pata_pdc2027x.c 01_gettimeofday/drivers/ata/pata_pdc2027x.c
@@ -689,10 +689,12 @@ static long pdc_detect_pll_input_clock(s
 	void __iomem *mmio_base = host->iomap[PDC_MMIO_BAR];
 	u32 scr;
 	long start_count, end_count;
-	long pll_clock;
+	struct timeval start_time, end_time;
+	long pll_clock, usec_elapsed;
 
 	/* Read current counter value */
 	start_count = pdc_read_counter(host);
+	do_gettimeofday(&start_time);
 
 	/* Start the test mode */
 	scr = readl(mmio_base + PDC_SYS_CTL);

@@ -705,6 +707,7 @@ static long pdc_detect_pll_input_clock(s
 
 	/* Read the counter values again */
 	end_count = pdc_read_counter(host);
+	do_gettimeofday(&end_time);
 
 	/* Stop the test mode */
 	scr = readl(mmio_base + PDC_SYS_CTL);

@@ -713,7 +716,11 @@ static long pdc_detect_pll_input_clock(s
 	readl(mmio_base + PDC_SYS_CTL); /* flush */
 
 	/* calculate the input clock in Hz */
-	pll_clock = (start_count - end_count) * 10;
+	usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 1000000 +
+		(end_time.tv_usec - start_time.tv_usec);
+
+	pll_clock = (start_count - end_count) / 100 *
+		(100000000 / usec_elapsed);
 
 	PDPRINTK("start[%ld] end[%ld] \n", start_count, end_count);
 	PDPRINTK("PLL input clock[%ld]Hz\n", pll_clock);

applied

Hi,

Could you also fix pdc202xx_new driver?

"buggy" code should be very similar if not identical...

I was going to do that but since I'm only working part-time in the last
few days, this keeps being deferred. Also, I need to find the card...

MBR, Sergei

Recently the PLL input clock of Promise 2027x is sometimes detected higer than expected (e.g. 20.027 MHz compared to 16.714 MHz). It seems sometimes the mdelay() function is not as precise as it used to be. Per Alan's advice, HT or power management might affect the precision of mdelay().

This patch calls gettimeofday() to mesure the time elapsed and calculate the PLL input clock accordingly.

---
(I have the Promise adapter at hand, so it's easier for me to verify.) Attached please find the patch and the test result on my box for your review:

[   72.186805] PDC20275: chipset revision 1
[   72.196768] start[1039788039] end[1039620652] pll[16804952]
[   72.196819] PDC20275: PLL input clock is 16804 kHz
[   72.226586] PDC20275: 100% native mode on irq 10

Maybe Bahadir could also help to verify if it helps to his "hda lost interrupt" problem.

@@ -306,11 +306,13 @@ static long __devinit read_counter(u32 d
  */
 static long __devinit detect_pll_input_clock(unsigned long dma_base)
 {
+	struct timeval start_time, end_time;
 	long start_count, end_count;
-	long pll_input;
+	long pll_input, usec_elapsed;
 	u8 scr1;
 
 	start_count = read_counter(dma_base);
+	do_gettimeofday(&start_time);
 
 	/* Start the test mode */
 	outb(0x01, dma_base + 0x01);

@@ -322,6 +324,7 @@ static long __devinit detect_pll_input_c
 	mdelay(10);
 
 	end_count = read_counter(dma_base);
+	do_gettimeofday(&end_time);
 
 	/* Stop the test mode */
 	outb(0x01, dma_base + 0x01);

@@ -333,7 +336,10 @@ static long __devinit detect_pll_input_c
 	 * Calculate the input clock in Hz
 	 * (the clock counter is 30 bit wide and counts down)
 	 */
-	pll_input = ((start_count - end_count) & 0x3ffffff) * 100;
+	usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 1000000 +
+		(end_time.tv_usec - start_time.tv_usec);
+	pll_input = ((start_count - end_count) & 0x3ffffff) / 10 *
+		(10000000 / usec_elapsed);
 
 	DBG("start[%ld] end[%ld]\n", start_count, end_count);
 

Hello.

     ^ h

                                       ^ a

Except for types in description:

MBR, Sergei ;-)

typos fixed manually

added

Said he, while making his own typo. :-)

MBR, Sergei

:)

--
albert

applied, thanks!

Hi,

As per the "hda lost interrupt" problem, I tried 2.6.22 and it didn't make any difference. Then I tried 2.6.21 with pdc202xx_new.c file from 2.6.19 (the working one). I had to only retain pdcnew_config_drive_xfer_rate() from 2.6.21 to make it compile, and I still had the same result. I guess this means its a change outside the driver that breaks it on my platform? I will git-bisect and see.

Thanks,
Bahadir