by Reuben Farrelly

[permalink] [raw]

Subject: Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

On 21/01/2006 6:47 p.m., Andrew Morton wrote:

>> I've now done in excess of 20 reboots with this code and haven't had either
>> problem show up at all.
>>
>> So for now I'll keep a record of things for a bit longer, but I guess I've
>> reason to be fairly confident that both this USB/IRQ problem and my ATA/IRQ
>> problem are now fixed.
>>
>> It does make me wonder if the ACPI update in rc1-mm2 fixed it, and was actually
>> the cause of most of my problems......it would be nice to know for sure.
>
> We probably won't know. Did you ever test 2.6.16-rc1 plus 2.6.16-rc1-mm1's
> acpi.patch? If that plays up we'd have confirmation.

It has been OK over 15x reboots (just tested now). 2.6.16-rc1-mm1 wasn't the
usual standard award winning release for me because of the reiserfs problems so
I only booted into it once and ran it for a couple of hours before retreating to
2.6.15-rc1.

Last *known* problematic release on that box was 2.6.15-mm4.

2006-01-21 08:32:38

by Jeff Garzik

[permalink] [raw]

Subject: [PATCH] Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 46c4cdb..4691f8d 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -4794,7 +4794,14 @@ ata_pci_init_native_mode(struct pci_dev
pci_resource_start(pdev, 1) | ATA_PCI_CTL_OFS;
probe_ent->port[p].bmdma_addr = pci_resource_start(pdev, 4);
ata_std_ports(&probe_ent->port[p]);
- p++;
+
+ if (pci_resource_start(pdev, 0) &&
+ pci_resource_len(pdev, 0) &&
+ pci_resource_start(pdev, 1) &&
+ pci_resource_len(pdev, 1) &&
+ pci_resource_start(pdev, 4) &&
+ pci_resource_len(pdev, 4))
+ p++;
}

if (ports & ATA_PORT_SECONDARY) {
@@ -4804,10 +4811,23 @@ ata_pci_init_native_mode(struct pci_dev
pci_resource_start(pdev, 3) | ATA_PCI_CTL_OFS;
probe_ent->port[p].bmdma_addr = pci_resource_start(pdev, 4) + 8;
ata_std_ports(&probe_ent->port[p]);
- p++;
+
+ if (pci_resource_start(pdev, 2) &&
+ pci_resource_len(pdev, 2) &&
+ pci_resource_start(pdev, 3) &&
+ pci_resource_len(pdev, 3) &&
+ pci_resource_start(pdev, 4) &&
+ pci_resource_len(pdev, 4) > 8)
+ p++;
}

probe_ent->n_ports = p;
+
+ if (p == 0) {
+ kfree(probe_ent);
+ probe_ent = NULL;
+ }
+
return probe_ent;
}

@@ -4815,6 +4835,10 @@ static struct ata_probe_ent *ata_pci_ini
{
struct ata_probe_ent *probe_ent;

+ if (!pci_resource_start(pdev, 4) ||
+ !pci_resource_len(pdev, 4))
+ return NULL;
+
probe_ent = ata_probe_ent_alloc(pci_dev_to_dev(pdev), port);
if (!probe_ent)
return NULL;

Attachments:

patch.pci-region-check (1.51 kB)

2006-01-21 10:41:37

by Reuben Farrelly

[permalink] [raw]

Subject: Re: [PATCH] Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

On 21/01/2006 9:32 p.m., Jeff Garzik wrote:
>
> On the libata side of things, does this patch produce any useful results?
>
> Jeff
>
>
>
>
> ------------------------------------------------------------------------
>
> diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
> index 46c4cdb..4691f8d 100644
> --- a/drivers/scsi/libata-core.c
> +++ b/drivers/scsi/libata-core.c
> @@ -4794,7 +4794,14 @@ ata_pci_init_native_mode(struct pci_dev
> pci_resource_start(pdev, 1) | ATA_PCI_CTL_OFS;
> probe_ent->port[p].bmdma_addr = pci_resource_start(pdev, 4);
> ata_std_ports(&probe_ent->port[p]);
> - p++;

I've patched 2.6.15-mm4 with this, and yes, this patch changed the behaviour:

OK TIMEOUT OK OK TIMEOUT TIMEOUT TIMEOUT TIMEOUT OK TIMEOUT TIMEOUT OK TIMEOUT
TIMEOUT TIMEOUT

OK was when we got through to completion of single user mode, TIMEOUT - see below.

So no oopsing with that patch applied, which is a definite improvement.
Previously to this I was seeing the OOPSing most of the time and the TIMEOUTS
more occasionally.

---

Now, looking at the timeouts, here's the log from a boot:

ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 193
ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 4 ports 1.5 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq led slum part
ata1: SATA max UDMA/133 cmd 0xF8804D00 ctl 0x0 bmdma 0x0 irq 50
ata2: SATA max UDMA/133 cmd 0xF8804D80 ctl 0x0 bmdma 0x0 irq 50
ata3: SATA max UDMA/133 cmd 0xF8804E00 ctl 0x0 bmdma 0x0 irq 50
ata4: SATA max UDMA/133 cmd 0xF8804E80 ctl 0x0 bmdma 0x0 irq 50
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1 is slow to respond, please be patient
ata1 failed to respond (30 secs)
scsi0 : ahci
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2 is slow to respond, please be patient
ata2 failed to respond (30 secs)
scsi1 : ahci
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata3 is slow to respond, please be patient
ata3 failed to respond (30 secs)
scsi2 : ahci
ata4: SATA link down (SStatus 0)
scsi3 : ahci

When there is no timeout it looks like this:

ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 193
ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 4 ports 1.5 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq led slum part
ata1: SATA max UDMA/133 cmd 0xF8804D00 ctl 0x0 bmdma 0x0 irq 193
ata2: SATA max UDMA/133 cmd 0xF8804D80 ctl 0x0 bmdma 0x0 irq 193
ata3: SATA max UDMA/133 cmd 0xF8804E00 ctl 0x0 bmdma 0x0 irq 193
ata4: SATA max UDMA/133 cmd 0xF8804E80 ctl 0x0 bmdma 0x0 irq 193
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1: dev 0 ATA-6, max UDMA/133, 156301488 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ahci
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: dev 0 ATA-6, max UDMA/133, 156301488 sectors: LBA48
ata2: dev 0 configured for UDMA/133
scsi1 : ahci
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata3: dev 0 ATA-6, max UDMA/133, 156299375 sectors: LBA48
ata3: dev 0 configured for UDMA/133
scsi2 : ahci
ata4: SATA link down (SStatus 0)
scsi3 : ahci

Note the different IRQ numbers (50, 193) and how when it breaks, the ATA
interfaces have a different IRQ to the AHCI controller.

There's a full log up at http://lkml.org/lkml/2006/1/11/492 from when I posted
on lkml and at http://www.reub.net/files/kernel/ when the box isn't down for
testing ;-)

This may be a separate but related problem to the oops, I guess.

reuben