New: pata_hpt370x driver doesn't want to operate with Adaptec 1200A at UDMA/100
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: [email protected]
Reporter: [email protected]
Regression: NoThis 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?
Signature · 2 lines
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
https://bugzilla.kernel.org/show_bug.cgi?id=102741
Andreas E <[email protected]> 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/100Signature · 2 lines
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
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=102741
Sergei Shtylyov <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected] 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
Signature · 2 lines
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
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=102741
--- Comment #1 from Sergei Shtylyov <[email protected]> --- (In reply to Andreas E from comment #0)
Quoted 1 line
The card is properly initialized using the
pata_hpt370xkernel driver.
pata_hpt37x, you mean. I've already fixed the subject.
Quoted 3 lines
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.
Quoted 8 lines
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.
Quoted 9 lines
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
Quoted 6 lines
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].
Signature · 2 lines
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
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=102741
--- Comment #2 from Andreas E <[email protected]> ---
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?
Quoted 1 line
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. :)
Signature · 2 lines
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
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=102741
--- Comment #3 from Sergei Shtylyov <[email protected]> --- (In reply to Andreas E from comment #2)
Quoted 1 line
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.
Quoted 1 line
but it was limited artificially to /66.
"Shit happens". :-)
Quoted 4 lines
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.
Quoted 2 lines
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]
Signature · 2 lines
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
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=102741
--- Comment #4 from Andreas E <[email protected]> ---
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)
Signature · 2 lines
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
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=102741
--- Comment #5 from Sergei Shtylyov <[email protected]> --- (In reply to Andreas E from comment #4)
Quoted 1 line
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.
Quoted 1 line
And yes, I know Alan was the author. (hence my modinfo output)
I have hacked on this driver a bit as well...
Signature · 2 lines
You are receiving this mail because: You are watching the assignee of the bug.