Bug 8510 - OHCI constantly attempts suspending root hub on ALi motherboard
OHCI constantly attempts suspending root hub on ALi motherboard
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: USB
i386 Linux
: P2 normal
Assigned To: Rafael J. Wysocki
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2007-05-19 10:10 UTC by Andrey Borzenkov
Modified: 2007-06-06 07:59 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.22-rc2
Tree: Mainline
Regression: ---


Attachments
dmesg with USB_DEBUG showing constant attepmts to suspend root hub (81.77 KB, text/plain)
2007-05-19 10:12 UTC, Andrey Borzenkov
Details
kernel config (49.51 KB, text/plain)
2007-05-19 10:15 UTC, Andrey Borzenkov
Details

Description Andrey Borzenkov 2007-05-19 10:10:00 UTC
Most recent kernel where this bug did *NOT* occur:
2.6.16.20

Distribution:
Mandriva, kernel is vanilla kernel.org

Hardware Environment:
Toshiba Portege 4000
lspci:
00:00.0 Host bridge: ALi Corporation M1644/M1644T Northbridge+Trident (rev 01)
00:01.0 PCI bridge: ALi Corporation PCI to AGP Controller
00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
00:04.0 IDE interface: ALi Corporation M5229 IDE (rev c3)
00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link 
Controller Audio Device (rev 01)
00:07.0 ISA bridge: ALi Corporation M1533/M1535 PCI to ISA Bridge [Aladdin 
IV/V/V+]
00:08.0 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
00:0a.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] 
(rev 08)
00:10.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller 
(rev 01)
00:11.0 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus 
Bridge with ZV Support (rev 32)
00:11.1 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus 
Bridge with ZV Support (rev 32)
00:12.0 System peripheral: Toshiba America Info Systems SD TypA Controller 
(rev 03)
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade XPAi1 (rev 
82)


Software Environment:
swsusp

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. Problem history:

Initial submission: http://marc.info/?t=115064417300001&r=1&w=2
Later regression: http://marc.info/?t=116353774800002&r=1&w=2
Patch for the regression: http://marc.info/?t=116353970700001&r=1&w=2

Steps to reproduce:
Enable USB_DEBUG and check dmesg/syslog: 
hub 1-0:1.0: hub_suspend
ohci_hcd 0000:00:02.0: suspend root hub
usb usb1: usb auto-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
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: auto-stop root hub
ohci_hcd 0000:00:02.0: auto-wakeup root hub
ohci_hcd 0000:00:02.0: auto-stop root hub
ohci_hcd 0000:00:02.0: auto-wakeup root hub

every second

dmesg and .config attached
Comment 1 Andrey Borzenkov 2007-05-19 10:12:54 UTC
Created attachment 11543 [details]
dmesg with USB_DEBUG showing constant attepmts to suspend root hub
Comment 2 Andrey Borzenkov 2007-05-19 10:15:13 UTC
Created attachment 11544 [details]
kernel config
Comment 3 Anonymous Emailer 2007-05-19 13:45:00 UTC
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.



Comment 4 Anonymous Emailer 2007-05-19 13:46:36 UTC
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.
> 
> 
> 


Comment 5 Andrey Borzenkov 2007-05-19 14:07:11 UTC
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,
 	},

Comment 6 Alan Stern 2007-05-19 14:26:48 UTC
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

Comment 7 Andrey Borzenkov 2007-05-19 14:31:38 UTC
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

Comment 8 Rafael J. Wysocki 2007-06-05 11:08:34 UTC
Has the $subject bug been fixed?
Comment 9 Andrey Borzenkov 2007-06-05 11:23:49 UTC
yes, in 2.6.22-rc3
Comment 10 Rafael J. Wysocki 2007-06-06 07:59:12 UTC
OK, so I'm closing the bug.

Please reopen if necessary.

Note You need to log in before you can comment on or make changes to this bug.