No DMA with HTP370 IDE controller
Hello,
[please CC me upon replying - thank you]
I have a Highpoint 370 PCI IDE controller, and both my 2.6.18.2 and Knoppix 5's 2.6.17 display the following messages:
Quoted 47 lines
HPT370: IDE controller at PCI slot 0000:01:09.0
HPT370: chipset revision 3
HPT370: 100% native mode on irq 11
HPT37X: using 33MHz PCI clockide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:DMA, hdf:DMA HPT37X: using 33MHz PCI clock ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pioProbing IDE interface ide2...
hde: ST340823A, ATA DISK drive
hdf: ExcelStor Technology J840, ATA DISK drive
ide2 at 0x9000-0x9007,0x9402 on irq 11
Probing IDE interface ide3...
hdg: LITE-ON LTR-52246S, ATAPI CD/DVD-ROM drive
ide3 at 0x9800-0x9807,0x9c02 on irq 11
hde: max request size: 128KiB
hde: 78165360 sectors (40020 MB) w/1024KiB Cache, CHS=65535/16/63, UDMA(100)
hde: cache flushes not supported
hde:<4>hde:dma_timer_expiry: dma status ==0x61
hde: DMA timeout error
hde: 0 bytes in FIFO
hde: timeout waiting for DMA
hde: dma timeout error: status=0x80 { Busy }
ide: failed opcode was: unknown
hde: DMA disabled
hdf: DMA disabled
ide2: reset: success
hde1 hde2 <<4>hde:dma_timer_expiry: dma status ==0x21
hde: DMA timeout error
hde: 0 bytes in FIFO
hde: timeout waiting for DMA
hde: dma timeout error: status=0x80 { Busy }
ide: failed opcode was: unknown
hde: DMA disabled
ide2: reset: success
hde5<4>hde:dma_timer_expiry: dma status ==0x21
hde: DMA timeout error
hde: 0 bytes in FIFO
hde: timeout waiting for DMA
hde: dma timeout error: status=0x80 { Busy }
ide: failed opcode was: unknown
hde: DMA disabled
ide2: reset: success
hde6 >
hdf: max request size: 512KiB
hdf: 80418240 sectors (41174 MB) w/1719KiB Cache, CHS=16383/255/63
hdf: cache flushes supported
hdf: unknown partition table
Quoted 8 lines
hde:
dma_timer_expiry: dma status ==0x21
hde: DMA timeout error
hde: 0 bytes in FIFO
hde: timeout waiting for DMA
hde: dma timeout error: status=0x80 { Busy }
ide: failed opcode was: unknown
hde: DMA disabled
ide2: reset: success
(hdf is naked, there's no error in partition detection)
The same messages appear when manually trying to enable DMA with hdparm. The hdparm reading of hde is:
Quoted 9 lines
/dev/hde:multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 65535/16/63, sectors = 78165360, start = 0
hda, which is on the mainboard controller and works as hde used to as well, reads:
Quoted 9 lines
/dev/hda:multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 65535/16/63, sectors = 117231408, start = 0
In the controller's setup utility, I can choose access modes. If i switch it from UDMA5 to PIO0, the only difference during boot is:
Quoted 1 line
ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio
instead of
Quoted 1 line
ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:DMA, hdf:DMA
Please help me getting DMA to work with this controller.
Thanks in advance,
~Mik
Signature · 4 lines
So, how can you tell me you're lonely? And say that you don't have no life? Let me take you by the hand and show you all the geeks of London I'll show you something to make you change your mind!
Quoted 6 lines · Michael Bueker
Hello,
[please CC me upon replying - thank you]
I have a Highpoint 370 PCI IDE controller, and both my 2.6.18.2 and Knoppix 5's 2.6.17 display the following messages:
Please try 2.6.20-rc4 and 2.6.20-rc3-mm1.
Both contain many fixes to IDE hpt driver (but -mm some more than vanilla).
Bart
Michael Bueker
AppliedQuoted 11 lines · Bartlomiej Zolnierkiewicz
Have you looked at changes to
drivers/ide/pci/hpt366.c? The code is not the same, there are a lot of fixes in -mm:hpt3xx-rework-rate-filtering.patch
hpt3xx-rework-rate-filtering-tidy.patch
hpt3xx-print-the-real-chip-name-at-startup.patch
hpt3xx-switch-to-using-pci_get_slot.patch
hpt3xx-cache-channels-mcr-address.patch
hpt3x7-merge-speedproc-handlers.patch
hpt370-clean-up-dma-timeout-handling.patch
hpt3xx-init-code-rewrite.patch
I applied all of these patches, but the errors remains just the same. I actually did it twice to be sure, but to no avail.
~Mik
Signature · 3 lines
Hey Fred, did you save that posting about restoring filesystems with vi and a toothpick? More importantly, did you print it out? - From "101 Things You Don't Want To Hear Your Admin Say"
Hello.
Quoted 12 lines · Michael Bueker
Quoted 11 lines
Have you looked at changes to
drivers/ide/pci/hpt366.c? The code is not the same, there are a lot of fixes in -mm:hpt3xx-rework-rate-filtering.patch
hpt3xx-rework-rate-filtering-tidy.patch
hpt3xx-print-the-real-chip-name-at-startup.patch
hpt3xx-switch-to-using-pci_get_slot.patch
hpt3xx-cache-channels-mcr-address.patch
hpt3x7-merge-speedproc-handlers.patch
hpt370-clean-up-dma-timeout-handling.patch
hpt3xx-init-code-rewrite.patch
Quoted 1 line
I applied all of these patches, but the errors remains just the same. I actually did it twice to be sure, but to no avail.
Then it's probably the same issue as here:
http://bugzilla.kernel.org/show_bug.cgi?id=7703
What's really strange is that my HPT370 is working fine. However, the
chip marking says it's HPT370A despite the revision ID is 3 (which should correspond to HPT370)...
Quoted 1 line
~Mik
WBR, Sergei
Quoted 6 lines · Sergei Shtylyov
Then it's probably the same issue as here:
http://bugzilla.kernel.org/show_bug.cgi?id=7703
What's really strange is that my HPT370 is working fine. However,
the chip marking says it's HPT370A despite the revision ID is 3 (which should correspond to HPT370)...
Unfortunately, I'm unable to compile a 2.4.18 kernel (my gcc is probably too new) for testing.
But anyways - do you think there's hope for fixing this? If I can provide you with any more helpful information, please tell me.
My controller is:
http://www.michael-bueker.de/files/hpt370/
01:09.0 Mass storage controller: Triones Technologies, Inc. HPT366/368/370/370A/372/372N (rev 03)
Subsystem: Triones Technologies, Inc. HPT370 UDMA100
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
Quoted 1 line
TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 120 (2000ns min, 2000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 9000 [size=8]
Region 1: I/O ports at 9400 [size=4]
Region 2: I/O ports at 9800 [size=8]
Region 3: I/O ports at 9c00 [size=4]
Region 4: I/O ports at a000 [size=256]
Expansion ROM at da020000 [disabled] [size=128K]~Mik
Signature · 3 lines
Hey Fred, did you save that posting about restoring filesystems with vi and a toothpick? More importantly, did you print it out? - From "101 Things You Don't Want To Hear Your Admin Say"
Quoted 11 lines · Michael Bueker
Quoted 6 lines · Sergei Shtylyov
Then it's probably the same issue as here:
http://bugzilla.kernel.org/show_bug.cgi?id=7703
What's really strange is that my HPT370 is working fine. However,
the chip marking says it's HPT370A despite the revision ID is 3 (which should correspond to HPT370)...Unfortunately, I'm unable to compile a 2.4.18 kernel (my gcc is probably too new) for testing.
Quoted 6 lines
But anyways - do you think there's hope for fixing this? If I can provide you with any more helpful information, please tell me.
My controller is:
Does the libata driver work?
Jeff
Hello.
Quoted 4 lines · Michael Bueker
Quoted 3 lines
Then it's probably the same issue as here:
Quoted 8 lines
Quoted 2 lines
What's really strange is that my HPT370 is working fine. However,
the chip marking says it's HPT370A despite the revision ID is 3 (which should correspond to HPT370)...Unfortunately, I'm unable to compile a 2.4.18 kernel (my gcc is probably too new) for testing.
But anyways - do you think there's hope for fixing this? If I can provide you with any more helpful information, please tell me.
Hope dies last. :-)
Unfortunately, I don't have enough time to work on this, and the fact that
it's not locally reproducible also doesn't help. I'll try to come up with something to test but not very soon...
Quoted 13 lines
My controller is:
http://www.michael-bueker.de/files/hpt370/
01:09.0 Mass storage controller: Triones Technologies, Inc. HPT366/368/370/370A/372/372N (rev 03)
Subsystem: Triones Technologies, Inc. HPT370 UDMA100
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=mediumQuoted 1 line
TAbort- <TAbort- <MAbort- >SERR- <PERR-
Quoted 8 lines
Latency: 120 (2000ns min, 2000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 9000 [size=8]
Region 1: I/O ports at 9400 [size=4]
Region 2: I/O ports at 9800 [size=8]
Region 3: I/O ports at 9c00 [size=4]
Region 4: I/O ports at a000 [size=256]
Expansion ROM at da020000 [disabled] [size=128K]Exactly what I have here but the chip marking is HPT370A. A bit puzzling...
Quoted 1 line
~Mik
WBR, Sergei
Quoted 1 line · Jeff Garzik
Does the libata driver work?
Nope. There's no verbose error messages, but the kernel dies about where the controller is addressed.
~Mik
Signature · 4 lines
So, how can you tell me you're lonely? And say that you don't have no life? Let me take you by the hand and show you all the geeks of London I'll show you something to make you change your mind!