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

[bugzilla-daemon@bugzilla.kernel.org]

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.