Re: No DMA with HTP370 IDE controller

Re: No DMA with HTP370 IDE controller

[Michael Bueker]

Bartlomiej Zolnierkiewicz wrote:
> 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

-- 
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"

Re: No DMA with HTP370 IDE controller

[Sergei Shtylyov]

Hello.

Michael Bueker wrote:

>> 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.

    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)...

> ~Mik

WBR, Sergei

Re: No DMA with HTP370 IDE controller

[Michael Bueker]

Sergei Shtylyov wrote:
>    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
>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

-- 
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"

Re: No DMA with HTP370 IDE controller

[Jeff Garzik]

Michael Bueker wrote:
> Sergei Shtylyov wrote:
>>    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/

Does the libata driver work?

	Jeff

Re: No DMA with HTP370 IDE controller

[Sergei Shtylyov]

Hello.

Michael Bueker wrote:

>>    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.

    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...

> 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
> 
>> 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]

    Exactly what I have here but the chip marking is HPT370A. A bit puzzling...

> ~Mik

WBR, Sergei

Re: No DMA with HTP370 IDE controller

[Michael Bueker]

Jeff Garzik wrote:
> Does the libata driver work?

Nope. There's no verbose error messages, but the kernel dies about where 
the controller is addressed.

~Mik

-- 
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!