Re: HPT374 detection crash with 74811f355f4f69a187fa74892dcf2a684b84ce99

Re: HPT374 detection crash with 74811f355f4f69a187fa74892dcf2a684b84ce99

[Sergei Shtylyov]

Hello.

Masoud Sharbiani "مسعود شربیانی" wrote:

> Hi there, Looks like your commit 74811f355f4f69a187fa74892dcf2a684b84ce99
>  (hpt366: convert to use ->host_priv)

    Thanks for the bisection.

> has caused the following crash:

    Oops, we did it again. :-)

> (Full dmesg follows, as captured from a serial console)

> [   22.555200] hpt366: HPT374 chipset detected
> [   22.559489] hpt366 0000:03:06.0: IDE controller (0x1103:0x0008 rev 0x07)
> [   22.566278] HPT366_IDE 0000:03:06.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
> [   22.573729] usb 1-2: new full speed USB device using uhci_hcd and address 4
> [   22.580726] pci 0000:03:06.1: PCI INT A -> GSI 28 (level, low) -> IRQ 28
> [   22.587529] hpt366 0000:03:06.0: DPLL base: 48 MHz, f_CNT: 142, assuming 33 MHz PCI
> [   22.602705] hpt366 0000:03:06.0: using 50 MHz DPLL clock
> [   22.608181] hpt366 0000:03:06.0: 100% native mode on irq 28
> [   22.613831] hpt366 0000:03:06.1: no clock data saved by BIOS

    Aha, HPT374 workaround for reading BIOS clock data didn't get executed.

> [   22.731015] usb 1-2: configuration #1 chosen from 1 choice
> [   22.737191] ata2.00: ATA-6: ST3120022A, 3.04, max UDMA/100
> [   22.738880] hub 1-2:1.0: USB hub found
> [   22.746597] ata2.00: 234441648 sectors, multi 16: LBA48
> [   22.747804] hpt366 0000:03:06.1: DPLL base: 33 MHz, f_CNT: 139, assuming

    Uh, I wonder where did it get those 33 MHz DPLL base -- there's simply no 
such base.  Looks like memory addressed by .host_priv got corrupt...

MBR, Sergei

Re: HPT374 detection crash with 74811f355f4f69a187fa74892dcf2a684b84ce99

[Sergei Shtylyov]

Hello.

Masoud Sharbiani "مسعود شربیانی" wrote:

> Hi there, Looks like your commit 74811f355f4f69a187fa74892dcf2a684b84ce99
>  (hpt366: convert to use ->host_priv)

    Thanks for doing the bisection.

> has caused the following crash:

    Oops, we did it again. :-)

> (Full dmesg follows, as captured from a serial console)

> [   22.555200] hpt366: HPT374 chipset detected
> [   22.559489] hpt366 0000:03:06.0: IDE controller (0x1103:0x0008 rev 0x07)
> [   22.566278] HPT366_IDE 0000:03:06.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
> [   22.573729] usb 1-2: new full speed USB device using uhci_hcd and address 4
> [   22.580726] pci 0000:03:06.1: PCI INT A -> GSI 28 (level, low) -> IRQ 28
> [   22.587529] hpt366 0000:03:06.0: DPLL base: 48 MHz, f_CNT: 142, assuming 33 MHz PCI
> [   22.602705] hpt366 0000:03:06.0: using 50 MHz DPLL clock
> [   22.608181] hpt366 0000:03:06.0: 100% native mode on irq 28
> [   22.613831] hpt366 0000:03:06.1: no clock data saved by BIOS

    Aha, HPT374 workaround for reading BIOS clock data didn't get executed.

> [   22.731015] usb 1-2: configuration #1 chosen from 1 choice
> [   22.737191] ata2.00: ATA-6: ST3120022A, 3.04, max UDMA/100
> [   22.738880] hub 1-2:1.0: USB hub found
> [   22.746597] ata2.00: 234441648 sectors, multi 16: LBA48
> [   22.747804] hpt366 0000:03:06.1: DPLL base: 33 MHz, f_CNT: 139, assuming

    Uh, I wonder where did it get those 33 MHz DPLL base -- there's simply no 
such base.  Looks like memory addressed by .host_priv got corrupt...

MBR, Sergei

Re: HPT374 detection crash with 74811f355f4f69a187fa74892dcf2a684b84ce99

[Sergei Shtylyov]

Hello, I just wrote:

>> Hi there, Looks like your commit 74811f355f4f69a187fa74892dcf2a684b84ce99
>>  (hpt366: convert to use ->host_priv)

>    Thanks for doing the bisection.

>> has caused the following crash:

>    Oops, we did it again. :-)

    Already seeing Bart's mistake, see below:

>> (Full dmesg follows, as captured from a serial console)

>> [   22.555200] hpt366: HPT374 chipset detected
>> [   22.559489] hpt366 0000:03:06.0: IDE controller (0x1103:0x0008 rev 0x07)
>> [   22.566278] HPT366_IDE 0000:03:06.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
>> [   22.573729] usb 1-2: new full speed USB device using uhci_hcd and address 4
>> [   22.580726] pci 0000:03:06.1: PCI INT A -> GSI 28 (level, low) -> IRQ 28
>> [   22.587529] hpt366 0000:03:06.0: DPLL base: 48 MHz, f_CNT: 142, assuming 33 MHz PCI
>> [   22.602705] hpt366 0000:03:06.0: using 50 MHz DPLL clock
>> [   22.608181] hpt366 0000:03:06.0: 100% native mode on irq 28
>> [   22.613831] hpt366 0000:03:06.1: no clock data saved by BIOS

>    Aha, HPT374 workaround for reading BIOS clock data didn't get executed.

>> [   22.731015] usb 1-2: configuration #1 chosen from 1 choice
>> [   22.737191] ata2.00: ATA-6: ST3120022A, 3.04, max UDMA/100
>> [   22.738880] hub 1-2:1.0: USB hub found
>> [   22.746597] ata2.00: 234441648 sectors, multi 16: LBA48
>> [   22.747804] hpt366 0000:03:06.1: DPLL base: 33 MHz, f_CNT: 139, assuming

>    Uh, I wonder where did it get those 33 MHz DPLL base -- there's 
> simply no such base.  Looks like memory addressed by .host_priv got 
> corrupt...

    No, that's just wrong pointer arithmetics there:

        struct hpt_info *info = host->host_priv + (hwif->dev == host->dev[1]);

The 'host_priv' is declared as 'void *', hence in case the condition abobe is 
true, there will be added only 1 to host->host_priv, not sizeof(struct 
hpt_info) as it should've been...

MBR, Sergei

Re: HPT374 detection crash with 74811f355f4f69a187fa74892dcf2a684b84ce99

[Masoud Sharbiani "مسعود شربیانی"]

On Fri, Sep 5, 2008 at 9:32 AM, Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> Hello, I just wrote:
>
>>> Hi there, Looks like your commit 74811f355f4f69a187fa74892dcf2a684b84ce99
>>>  (hpt366: convert to use ->host_priv)
>
>>   Thanks for doing the bisection.
>
>>> has caused the following crash:
>
>>   Oops, we did it again. :-)
>
>   Already seeing Bart's mistake, see below:
>
>>> (Full dmesg follows, as captured from a serial console)
>
>>> [   22.555200] hpt366: HPT374 chipset detected
>>> [   22.559489] hpt366 0000:03:06.0: IDE controller (0x1103:0x0008 rev
>>> 0x07)
>>> [   22.566278] HPT366_IDE 0000:03:06.0: PCI INT A -> GSI 28 (level, low)
>>> -> IRQ 28
>>> [   22.573729] usb 1-2: new full speed USB device using uhci_hcd and
>>> address 4
>>> [   22.580726] pci 0000:03:06.1: PCI INT A -> GSI 28 (level, low) -> IRQ
>>> 28
>>> [   22.587529] hpt366 0000:03:06.0: DPLL base: 48 MHz, f_CNT: 142,
>>> assuming 33 MHz PCI
>>> [   22.602705] hpt366 0000:03:06.0: using 50 MHz DPLL clock
>>> [   22.608181] hpt366 0000:03:06.0: 100% native mode on irq 28
>>> [   22.613831] hpt366 0000:03:06.1: no clock data saved by BIOS
>
>>   Aha, HPT374 workaround for reading BIOS clock data didn't get executed.
>
>>> [   22.731015] usb 1-2: configuration #1 chosen from 1 choice
>>> [   22.737191] ata2.00: ATA-6: ST3120022A, 3.04, max UDMA/100
>>> [   22.738880] hub 1-2:1.0: USB hub found
>>> [   22.746597] ata2.00: 234441648 sectors, multi 16: LBA48
>>> [   22.747804] hpt366 0000:03:06.1: DPLL base: 33 MHz, f_CNT: 139,
>>> assuming
>
>>   Uh, I wonder where did it get those 33 MHz DPLL base -- there's simply
>> no such base.  Looks like memory addressed by .host_priv got corrupt...
>
>   No, that's just wrong pointer arithmetics there:
>
>       struct hpt_info *info = host->host_priv + (hwif->dev == host->dev[1]);
>
> The 'host_priv' is declared as 'void *', hence in case the condition abobe
> is true, there will be added only 1 to host->host_priv, not sizeof(struct
> hpt_info) as it should've been...
>

Hey I can try that now....stay tuned.

Masoud
> MBR, Sergei
>
>