From mboxrd@z Thu Jan 1 00:00:00 1970 From: Reuben Farrelly Subject: Re: [PATCH] Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug] Date: Sat, 21 Jan 2006 23:41:34 +1300 Message-ID: <43D20FDE.8070700@reub.net> References: <43D1C4E9.7030901@reub.net> <20060120214723.79111715.akpm@osdl.org> <43D1E9A4.8090504@reub.net> <43D1F192.3060406@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <43D1F192.3060406@pobox.com> Sender: linux-acpi-owner@vger.kernel.org To: Jeff Garzik Cc: Andrew Morton , stern@rowland.harvard.edu, linux-kernel@vger.kernel.org, greg@kroah.com, "linux-ide@vger.kernel.org" , neilb@cse.unsw.edu.au, linux-acpi@vger.kernel.org List-Id: linux-ide@vger.kernel.org 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