Bug 8510
| Summary: | OHCI constantly attempts suspending root hub on ALi motherboard | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Andrey Borzenkov (arvidjaar) |
| Component: | USB | Assignee: | Rafael J. Wysocki (rjwysocki) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | rjwysocki |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.22-rc2 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 7216 | ||
| Attachments: |
dmesg with USB_DEBUG showing constant attepmts to suspend root hub
kernel config |
||
|
Description
Andrey Borzenkov
2007-05-19 10:10:00 UTC
Created attachment 11543 [details]
dmesg with USB_DEBUG showing constant attepmts to suspend root hub
Created attachment 11544 [details]
kernel config
Reply-To: david-b@pacbell.net On Saturday 19 May 2007, Andrew Morton wrote: > On Sat, 19 May 2007 10:08:40 -0700 bugme-daemon@bugzilla.kernel.org wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=8510 > > A regression. From 2.6.16, yes... this has been around for a while, but nobody came up with a patch. I suggest someone with the hardware just provide an update to the drivers/usb/host/ohci-pci.c file using the PCI_DEVICE(PCI_VENDOR_ID_ITE, 0x8152), quirk table entry as a model. - Dave > > > > Problem Description: > > Kernel constantly tries suspend root hub which fails on this motherboard. > > Initially it also output messages to dmesg every second; now message is no > > more output but as debug shows kernel still constantly tries failed attepts. > > Workaround is to disable wakeup via sysfs; it was suggested that proper fix is > > to blacklist the drievr. As far as I an tell neccessary infrastructure is now > > available. Reply-To: david-b@pacbell.net On Saturday 19 May 2007, David Brownell wrote: > On Saturday 19 May 2007, Andrew Morton wrote: > > On Sat, 19 May 2007 10:08:40 -0700 bugme-daemon@bugzilla.kernel.org wrote: > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8510 > > > > A regression. > > From 2.6.16, yes... this has been around for a while, but nobody > came up with a patch. > > I suggest someone with the hardware just provide an update to the > drivers/usb/host/ohci-pci.c file using the > > PCI_DEVICE(PCI_VENDOR_ID_ITE, 0x8152), > > quirk table entry as a model. Grr, better yet: find out why the existing quirk entry for this particular laptop doesn't trigger. > > - Dave > > > > > > > Problem Description: > > > Kernel constantly tries suspend root hub which fails on this motherboard. > > > Initially it also output messages to dmesg every second; now message is no > > > more output but as debug shows kernel still constantly tries failed attepts. > > > Workaround is to disable wakeup via sysfs; it was suggested that proper fix is > > > to blacklist the drievr. As far as I an tell neccessary infrastructure is now > > > available. > > > On Sunday 20 May 2007, David Brownell wrote: > On Saturday 19 May 2007, David Brownell wrote: > > On Saturday 19 May 2007, Andrew Morton wrote: > > > On Sat, 19 May 2007 10:08:40 -0700 bugme-daemon@bugzilla.kernel.org wrote: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8510 > > > > > > A regression. > > > > From 2.6.16, yes... this has been around for a while, but nobody > > came up with a patch. > > > > I suggest someone with the hardware just provide an update to the > > drivers/usb/host/ohci-pci.c file using the > > > > PCI_DEVICE(PCI_VENDOR_ID_ITE, 0x8152), > > > > quirk table entry as a model. > > Grr, better yet: find out why the existing quirk entry for this > particular laptop doesn't trigger. > Because it is usig wrong subvendor. Runtime tested: ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd: block sizes: ed 64 td 64 ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKG] -> GSI 11 (level, low) -> IRQ 11 ohci_hcd 0000:00:02.0: OHCI Host Controller /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file 'devices' /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001' ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1 ohci_hcd 0000:00:02.0: created debug files ohci_hcd 0000:00:02.0: irq 11, io mem 0xf7eff000 ohci_hcd 0000:00:02.0: enabling initreset quirk ohci_hcd 0000:00:02.0: OHCI controller state ohci_hcd 0000:00:02.0: OHCI 1.0, NO legacy support registers ohci_hcd 0000:00:02.0: control 0x083 HCFS=operational CBSR=3 ohci_hcd 0000:00:02.0: cmdstatus 0x00000 SOC=0 ohci_hcd 0000:00:02.0: intrstatus 0x00000044 RHSC SF ohci_hcd 0000:00:02.0: intrenable 0x8000000a MIE RD WDH ohci_hcd 0000:00:02.0: hcca frame #0003 ohci_hcd 0000:00:02.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3) ohci_hcd 0000:00:02.0: roothub.b 00000000 PPCM=0000 DR=0000 ohci_hcd 0000:00:02.0: roothub.status 00008000 DRWE ohci_hcd 0000:00:02.0: roothub.portstatus [0] 0x00000100 PPS ohci_hcd 0000:00:02.0: roothub.portstatus [1] 0x00000100 PPS ohci_hcd 0000:00:02.0: roothub.portstatus [2] 0x00000100 PPS usb usb1: default language 0x0409 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: OHCI Host Controller usb usb1: Manufacturer: Linux 2.6.22-rc2-cfs-v13-1avb ohci_hcd usb usb1: SerialNumber: 0000:00:02.0 usb usb1: uevent usb usb1: usb_probe_device usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: uevent usb 1-0:1.0: uevent hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: no power switching (usb 1.0) hub 1-0:1.0: global over-current protection hub 1-0:1.0: power on to power good time: 2ms hub 1-0:1.0: local power source is good hub 1-0:1.0: no over-current condition exists hub 1-0:1.0: trying to enable port power on non-switchable hub hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000 /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001' usb usb1: remote wakeup needed for autosuspend --- Subject: [PATCH] Fix USB OHCI Subvendor for Toshiba Portege 4000 From: Andrey Borzenkov <arvidjaar@mail.ru> For Portege 4000 Subvendor is 1179 (PCI_VENDOR_ID_TOSHIBA) not 0x102f (PCI_VENDOR_ID_TOSHIBA_2) 00:02.0 USB Controller [0c03]: ALi Corporation USB 1.1 Controller [10b9:5237] (rev 03) (prog-if 10 [OHCI]) Subsystem: Toshiba America Info Systems Unknown device [1179:0004] Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at f7eff000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru> --- drivers/usb/host/ohci-pci.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c index 7970560..ca62cb5 100644 --- a/drivers/usb/host/ohci-pci.c +++ b/drivers/usb/host/ohci-pci.c @@ -137,7 +137,7 @@ static const struct pci_device_id ohci_pci_quirks[] = { /* Toshiba portege 4000 */ .vendor = PCI_VENDOR_ID_AL, .device = 0x5237, - .subvendor = PCI_VENDOR_ID_TOSHIBA_2, + .subvendor = PCI_VENDOR_ID_TOSHIBA, .subdevice = 0x0004, .driver_data = (unsigned long) broken_suspend, }, On Sun, 20 May 2007, Andrey Borzenkov wrote:
> On Sunday 20 May 2007, David Brownell wrote:
> > On Saturday 19 May 2007, David Brownell wrote:
> > > On Saturday 19 May 2007, Andrew Morton wrote:
> > > > On Sat, 19 May 2007 10:08:40 -0700 bugme-daemon@bugzilla.kernel.org
> wrote:
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8510
> > > >
> > > > A regression.
> > >
> > > From 2.6.16, yes... this has been around for a while, but nobody
> > > came up with a patch.
> > >
> > > I suggest someone with the hardware just provide an update to the
> > > drivers/usb/host/ohci-pci.c file using the
> > >
> > > PCI_DEVICE(PCI_VENDOR_ID_ITE, 0x8152),
> > >
> > > quirk table entry as a model.
> >
> > Grr, better yet: find out why the existing quirk entry for this
> > particular laptop doesn't trigger.
> >
>
> Because it is usig wrong subvendor. Runtime tested:
Does this fix the regression described in your email
"2.6.22-rc2: regression: STD fails with pci_device_suspend():
usb_hcd_pci_suspend+0x0/0x160 [usbcore]() returns -16"
?
Alan Stern
On Sunday 20 May 2007, Alan Stern wrote: > On Sun, 20 May 2007, Andrey Borzenkov wrote: > > On Sunday 20 May 2007, David Brownell wrote: > > > On Saturday 19 May 2007, David Brownell wrote: > > > > On Saturday 19 May 2007, Andrew Morton wrote: > > > > > On Sat, 19 May 2007 10:08:40 -0700 bugme-daemon@bugzilla.kernel.org > > > > wrote: > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8510 > > > > > > > > > > A regression. > > > > > > > > From 2.6.16, yes... this has been around for a while, but nobody > > > > came up with a patch. > > > > > > > > I suggest someone with the hardware just provide an update to the > > > > drivers/usb/host/ohci-pci.c file using the > > > > > > > > PCI_DEVICE(PCI_VENDOR_ID_ITE, 0x8152), > > > > > > > > quirk table entry as a model. > > > > > > Grr, better yet: find out why the existing quirk entry for this > > > particular laptop doesn't trigger. > > > > Because it is usig wrong subvendor. Runtime tested: > > Does this fix the regression described in your email > > "2.6.22-rc2: regression: STD fails with pci_device_suspend(): > usb_hcd_pci_suspend+0x0/0x160 [usbcore]() returns -16" > > ? > No. Unfortunately. Here is dmesg with patch and USB_DEBUG swsusp: Marking nosave pages: 000000000009f000 - 0000000000100000 swsusp: Basic memory bitmaps created Stopping tasks ... done. Shrinking memory... done (61536 pages freed) Freed 246144 kbytes in 1.99 seconds (123.69 MB/s) Suspending console(s) hub 1-0:1.0: hub_suspend ohci_hcd 0000:00:02.0: suspend root hub usb usb1: usb suspend usb usb1: usb resume usb usb1: finish resume hub 1-0:1.0: hub_resume ohci_hcd 0000:00:02.0: wakeup root hub sd 0:0:0:0: [sda] Synchronizing SCSI cache pnp: Device 00:09 disabled. Trying to free already-free IRQ 11 ACPI: PCI interrupt for device 0000:00:06.0 disabled ACPI: Unable to derive IRQ for device 0000:00:04.0 pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x230 [usbcore]() returns -16 suspend_device(): pci_device_suspend+0x0/0x70() returns -16 Could not suspend device 0000:00:02.0: error -16 PM: Writing back config space on device 0000:00:04.0 at offset 1 (was 2900001, writing 2900005) ACPI: Unable to derive IRQ for device 0000:00:04.0 ACPI: PCI Interrupt 0000:00:04.0[A]: no GSI ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 11 ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080 ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080 ata1.00: configured for UDMA/33 sd 0:0:0:0: [sda] 39070080 512-byte hardware sectors (20004 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA PM: Writing back config space on device 0000:00:0a.0 at offset f (was 38080100, writing 3808010b) PM: Writing back config space on device 0000:00:0a.0 at offset 6 (was 0, writing f7d00000) PM: Writing back config space on device 0000:00:0a.0 at offset 5 (was 1, writing eb41) PM: Writing back config space on device 0000:00:0a.0 at offset 4 (was 0, writing f7efd000) PM: Writing back config space on device 0000:00:0a.0 at offset 3 (was 0, writing 4008) PM: Writing back config space on device 0000:00:0a.0 at offset 1 (was 2900000, writing 2900007) ata2.00: configured for UDMA/33 pnp: Failed to activate device 00:05. pnp: Failed to activate device 00:06. pnp: Device 00:09 activated. sd 0:0:0:0: [sda] Starting disk eth1: PRI 31 variant 2 version 9.48 eth1: NIC 5 variant 2 version 1.02 Restarting tasks ... <7>hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000 usb usb1: remote wakeup needed for autosuspend done. swsusp: Basic memory bitmaps freed input: Power Button (FF) as /class/input/input8 ACPI: Power Button (FF) [PWRF] input: Lid Switch as /class/input/input9 ACPI: Lid Switch [LID] eth1: PRI 31 variant 2 version 9.48 eth1: NIC 5 variant 2 version 1.02 eth1: PRI 31 variant 2 version 9.48 eth1: NIC 5 variant 2 version 1.02 eth1: PRI 31 variant 2 version 9.48 eth1: NIC 5 variant 2 version 1.02 Has the $subject bug been fixed? yes, in 2.6.22-rc3 OK, so I'm closing the bug. Please reopen if necessary. |