Re: [BUGREPORT 1/3] Kernel Oops with HPT372A IDE controller

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]

Hello, I wrote:

>>>> Kernel Oops with HighPoint RocketRAID ATA133 aka HPT372A/N since 
>>>> kernel 2.6
>>>> Now tested with kernel 2.6.17-rc4

>>>> Kernel is on bootable CD-ROM
>>>> Modules are loaded from initrd

>>>> This is what I copied from screen:

>>>> Loading hpt366
>>>> [17179578.396000] HPT372A: IDE controller at PCI slot 0000:01:0a.0
>>>> [17179578.400000] ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
>>>> [17179578.404000] ACPI: PCI Interrupt 0000:01:0a.0[A] -> Link [APC1] 
>>>> -> GSI 16 (level, high) -> IRQ 18
>>>> [17179578.408000] HPT372A: chipset revision 2
>>>> [17179578.412000] HPT372A: 100% native mode on irq 18
>>>> [17179578.416000] hpt: HPT372N detected, using 372N timing.
>>>> [17179578.420000] FREQ: 125 PLL: 45
>>>> [17179579.536000] No Clock Stabilization!!!
>>>> [17179579.540000] hpt: no known IDE timings, disabling DMA
>>>> [17179579.544000] hpt: HPT372N detected, using 372N timing.
>>>> [17179579.548000] FREQ: 156 PLL: 66
>>>> [17179579.664000] No Clock Stabilization!!!

>>>    Please try my latest patches. This one should fix this (and oops 
>>> should be gone):

>>> http://marc.theaimsgroup.com/?l=linux-ide&m=114677223914159&w=2

>> all patches applied, but I still get Kernel Oops :-(

>> some smal difference here:

>>   HPT372A: IDE controller at PCI slot 0000:01:0a.0
>>   ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
>>   ACPI: PCI Interrupt 0000:01:0a.0[A] -> Link [APC1] -> GSI 16 (level, 
>> high) -> IRQ 18
>>   HPT372A: chipset revision 2
>>   HPT372A: 100% native mode on irq 18
>> + HPT37X: no clock data saved by BIOS
>> + HPT3xxN detected, FREQ: 124, PLL: 45
>> + HPT37xN unknown bus timing [48 4].

>    Hm, the BIOS seems to behave nastier than expected -- looks like it
> reprograms DPLL but doesn't save the initial f_CNT (needed to determine the
> PCI clock). Well, I know that it always sets DPLL to 50 MHz, no matter 
> what's the chip, so will try to work around this... :-/

    OTOH, there might be another reason to that: the BIOS saves f_CNT but the 
register it uses for this isn't mapped to the PCI config. space, only to the 
I/O space (it's undocumented, after all). Andy Shaw's report seems to confirm 
this -- his RAID BIOS seems to be modern enough to save the f_CNT but the 
driver probably fails to read it (I don't have the full boot log yet).
    So, try the attached patch please. Foli, if this won't help, can you tell 
what version your HighPoint BIOS is?

MBR, Sergei

[-- Attachment #2: HPT3xx-read-f_CNT-from-port.patch --]
[-- Type: text/plain, Size: 490 bytes --]

Index: linus/drivers/ide/pci/hpt366.c
===================================================================
--- linus.orig/drivers/ide/pci/hpt366.c
+++ linus/drivers/ide/pci/hpt366.c
@@ -1020,7 +1020,7 @@ static void __devinit hpt37x_clocking(id
 	 * reading the f_CNT register itself in hopes that nobody has
 	 * touched the DPLL yet...
 	 */
-	pci_read_config_dword(dev, 0x70, &temp);
+	temp = inl(pci_resource_start(dev, 4) + 0x90);
 	if ((temp & 0xFFFFF000) != 0xABCDE000) {
 		int i;