[Bug 102741] New: pata_hpt370x driver doesn't want to operate with Adaptec 1200A at UDMA/100

[Bug 102741] New: pata_hpt370x driver doesn't want to operate with Adaptec 1200A at UDMA/100

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=102741

            Bug ID: 102741
           Summary: pata_hpt370x driver doesn't want to operate with
                    Adaptec 1200A at UDMA/100
           Product: IO/Storage
           Version: 2.5
    Kernel Version: 3.18.0-9
          Hardware: i386
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IDE
          Assignee: io_ide@kernel-bugs.osdl.org
          Reporter: andi3@gmx.net
        Regression: No

This is an older machine. But hey, it is Linux, so we can expect a good support
instead of the common words from big players "replace your system with a more
modern one, as it's unsupported"

It's a bog-standard 1200 A "RAID" card by Adaptec. Even though I am not using
RAID at the moment, it may also operate as an add-in card for hard drives.
To minimize the mess, I have only ONE drive connected to the card right now.

The card is properly initialized using the pata_hpt370x kernel driver. However,
it will always show as UDMA/66 which simply cannot be. Of course, I've even
tried brand-new cables with it, but I think it has nothing to so with that.

The drive connected to it is a Samsung SpinPoint T133 (HD 400 LD), which
*definitly* can do UDMA/100.
The hardware is capable of doing so, too: 

# lspci -knn |grep HPT
01:09.0 Mass storage controller [0180]: HighPoint Technologies, Inc. 
HPT366/368/370/370A/372/372N [1103:0004] (rev 03)
 Subsystem: HighPoint Technologies, Inc. HPT370 UDMA100 [1103:0005]

# modinfo pata_hpt37x
filename:       /lib/modules/3.18.0-9-generic/kernel/drivers/ata/pata_hpt37x.ko
version:        0.6.23
license:        GPL
description:    low-level driver for the Highpoint HPT37x/30x
author:         Alan Cox
srcversion:     9767DBC95C3C8CD9B426A96
alias:          pci:v00001103d00000006sv*sd*bc*sc*i*
alias:          pci:v00001103d00000008sv*sd*bc*sc*i*
alias:          pci:v00001103d00000005sv*sd*bc*sc*i*
alias:          pci:v00001103d00000007sv*sd*bc*sc*i*
alias:          pci:v00001103d00000004sv*sd*bc*sc*i*
depends:        
intree:         Y
vermagic:       3.18.0-9-generic SMP mod_unload modversions 686 
signer:         Magrathea: Glacier signing key
sig_key:        64:24:93:B2:42:A8:8A:D6:3A:5D:EE:4A:7A:65:66:84:4C:ED:13:23
sig_hashalgo:   sha512

Now let's take a look at the dmesg from kernel:

[    1.992359] pata_hpt37x: HPT370 using 33MHz bus clock
[    2.015478] scsi host10: pata_hpt37x
[    2.023431] scsi host11: pata_hpt37x

[    2.023610] ata11: PATA max UDMA/66 cmd 0x8c00 ctl 0x9000 bmdma 0x9c00 irq
19
[    2.023614] ata12: PATA max UDMA/66 cmd 0x9400 ctl 0x9800 bmdma 0x9c08 irq
19

('ata12' is the Samsung drive; 'ata11' is currently empty.)

This can't be correct.
Why only at such low speed, i. e. UDMA/66?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102741] pata_hpt370x driver refuses to operate with Adaptec 1200A at UDMA/100

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=102741

Andreas E <andi3@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|pata_hpt370x driver doesn't |pata_hpt370x driver refuses
                   |want to operate with        |to operate with Adaptec
                   |Adaptec 1200A at UDMA/100   |1200A at UDMA/100

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102741] pata_hpt37x driver refuses to operate with Adaptec 1200A at UDMA/100

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=102741

Sergei Shtylyov <sshtylyov@ru.mvista.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sshtylyov@ru.mvista.com
            Summary|pata_hpt370x driver refuses |pata_hpt37x driver refuses
                   |to operate with Adaptec     |to operate with Adaptec
                   |1200A at UDMA/100           |1200A at UDMA/100

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102741] pata_hpt37x driver refuses to operate with Adaptec 1200A at UDMA/100

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=102741

--- Comment #1 from Sergei Shtylyov <sshtylyov@ru.mvista.com> ---
(In reply to Andreas E from comment #0)

> The card is properly initialized using the pata_hpt370x kernel driver.

pata_hpt37x, you mean. I've already fixed the subject.

> However, it will always show as UDMA/66 which simply cannot be. Of course,
> I've even tried brand-new cables with it, but I think it has nothing to so
> with that.

Sure.

> The drive connected to it is a Samsung SpinPoint T133 (HD 400 LD), which
> *definitly* can do UDMA/100.
> The hardware is capable of doing so, too:

> # lspci -knn |grep HPT
> 01:09.0 Mass storage controller [0180]: HighPoint Technologies, Inc. 
> HPT366/368/370/370A/372/372N [1103:0004] (rev 03)
>  Subsystem: HighPoint Technologies, Inc. HPT370 UDMA100 [1103:0005]

Yes, it's the original HPT370 chip.

> Now let's take a look at the dmesg from kernel:

> [    1.992359] pata_hpt37x: HPT370 using 33MHz bus clock
> [    2.015478] scsi host10: pata_hpt37x
> [    2.023431] scsi host11: pata_hpt37x
> 
> [    2.023610] ata11: PATA max UDMA/66 cmd 0x8c00 ctl 0x9000 bmdma 0x9c00
> irq 19
> [    2.023614] ata12: PATA max UDMA/66 cmd 0x9400 ctl 0x9800 bmdma 0x9c08
> irq 19
> 
> ('ata12' is the Samsung drive; 'ata11' is currently empty.)

> This can't be correct.
> Why only at such low speed, i. e. UDMA/66?

The HPT370 speed was artificiallly limited to UDMA/66, mimicking what I did for
drivers/ide/hpt366.c. And in case of the IDE driver, the reason was two--fold:

1) UDMA/100 is not properly reachable with 33 MHz PCI clock;
2) UDMA/66 showed much better figures than UDMA/100 on HPT370 I was testing on.

There were good reasons not to use DPLL clock, which is 48 MHz on HPT370[A].

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102741] pata_hpt37x driver refuses to operate with Adaptec 1200A at UDMA/100

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=102741

--- Comment #2 from Andreas E <andi3@gmx.net> ---
NAH!!! I can't believe it. This thing can do UDMA/100 but it was limited
artificially to /66. 
In any case, I think the driver messages should *inform* the user about this
being not their HDD(s) at fault, but forced to this speed by the driver itself.
Because every user would initially think that it's their fault, not the
driver's.

Is there any way I can force it to operate at UDMA/100? 
Some #define, anything? 

>2) UDMA/66 showed much better figures than UDMA/100 on HPT370 I was testing on.

Yes, that happened on the HPT370 *you* were testing on! But you shouldn't
project your results on everyone else's, IMHO. 
I'd definitely want to test it on *my* card first, before I believe you. Sorry
'bout that. :)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102741] pata_hpt37x driver refuses to operate with Adaptec 1200A at UDMA/100

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=102741

--- Comment #3 from Sergei Shtylyov <headless@email.ru> ---
(In reply to Andreas E from comment #2)

> NAH!!! I can't believe it. This thing can do UDMA/100

Well, I wouldn't call UDMA/100 with 66 MHz clock real UDMA/100.

> but it was limited artificially to /66.

"Shit happens". :-)

> In any case, I think the driver messages should *inform* the user about this
> being not their HDD(s) at fault, but forced to this speed by the driver
> itself. Because every user would initially think that it's their fault, not
> the driver's.

Makes sense.

> Is there any way I can force it to operate at UDMA/100? 
> Some #define, anything? 

With the IDE driver, there was a #define but that's not the case with the
libata one. Thank Alan Cox for that. :-)
However, it shouldn't be hard to do, just comment out the following lines:

                if (clock_slot < 2 && ppi[0] == &info_hpt370)
                        ppi[0] = &info_hpt370_33;
                if (clock_slot < 2 && ppi[0] == &info_hpt370a)
                        ppi[0] = &info_hpt370a_33;

[the rest skipped]

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102741] pata_hpt37x driver refuses to operate with Adaptec 1200A at UDMA/100

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=102741

--- Comment #4 from Andreas E <andi3@gmx.net> ---
Thanks! It's a butt-ugly hack, but better than nothing for the time being! And
yes, I know Alan was the author. (hence my modinfo output)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102741] pata_hpt37x driver refuses to operate with Adaptec 1200A at UDMA/100

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=102741

--- Comment #5 from Sergei Shtylyov <headless@email.ru> ---
(In reply to Andreas E from comment #4)

> Thanks! It's a butt-ugly hack, but better than nothing for the time being!

Please report your test results with and without the hack; running 'hdparm -t
/dev/sda' should be enough, probably.

> And yes, I know Alan was the author. (hence my modinfo output)

I have hacked on this driver a bit as well...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.