On Fri, 2004-06-11 at 17:28, Benjamin Herrenschmidt wrote:
> I fwd your message to linux-usb and David replied there, can you
> follow up ?
> 
> Ben.

ok.

> 
> -----Forwarded Message-----
> From: David Brownell <[EMAIL PROTECTED]>
> To: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Cc: Linux-USB <[EMAIL PROTECTED]>
> Subject: Re: [linux-usb-devel] [Fwd: oops on wake up using usb-keyb/mouse on 
> powerbook]
> Date: Fri, 11 Jun 2004 08:15:08 -0700
> 
> Benjamin Herrenschmidt wrote:
> > From: Soeren Sonnenburg <[EMAIL PROTECTED]>
> > To: Linux Kernel <[EMAIL PROTECTED]>
> > Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > Subject: oops on wake up using usb-keyb/mouse on powerbook
> > Date: Thu, 10 Jun 2004 08:06:20 +0200
> > 
> > Hi!
> > 
> > I get this oops when I use a usb keyboard to wakeup the powerbook.
> > Kernel is 2.6.7-rc2, usb keyboard is infect a ps2 keyboard attached via
> > a usb->ps2 adapter.
> > 
> > Any ideas ?
> > Soeren.
> 
> The most interesting parts precede this message.  Why did
> the HC die?  Stop that, and the rest should be fine.

I don't know. I am now on *-rc3 and this oops still happened to me. Once
I woke up the computer using left mouse buttons once using the enter
key... What I've found in the logs preceding what I've send is:

Jun  8 07:04:20 kernel: ohci_hcd 0001:01:18.0: remote wakeup
Jun  8 07:04:20 kernel: radeonfb: suspending to state: 2...
Jun  8 07:04:20 kernel: agpgart: Putting AGP V2 device at 0000:00:0b.0 into 0x mode
Jun  8 07:04:20 kernel: agpgart: Putting AGP V2 device at 0000:00:10.0 into 0x mode
Jun  8 07:04:20 kernel: radeonfb: switching to D2 state...
Jun  8 07:04:20 kernel: cpufreq: resume failed to assert current frequency is what 
timing core thinks it is.
Jun  8 07:04:20 kernel: radeonfb: switching to D0 state...
Jun  8 07:04:20 kernel: radeonfb: resumed !
Jun  8 07:04:20 kernel: enable_irq(27) unbalanced
Jun  8 07:04:20 kernel: ohci_hcd 0001:01:18.0: HC died; cleaning up
Jun  8 07:04:20 kernel: drivers/usb/input/hid-core.c: can't resubmit intr, 
0001:01:18.0-1/input1, status -108
Jun  8 07:04:20 kernel: usb 1-1: USB disconnect, address 3
Jun  8 07:04:20 kernel: Badness in hcd_endpoint_disable at drivers/usb/core/hcd.c:1359
Jun  8 07:04:20 kernel: Call trace:

and that is really everything (machine was asleep for 1 day (I could
reason that from the date in the log)...

there is nothing else in the log... well in syslog I've found some udev
stuff but it is 1-3 seconds after the first oopses:

Jun  8 07:04:21 hal.hotplug[11256]: waiting for vc info at /class/vc/vcs63
Jun  8 07:04:21 hal.hotplug[11256]: Dont know how to wait for vc at /class/vc/vcs63; 
sleeping 1000 ms
Jun  8 07:04:23 kernel: adb: starting probe task...
Jun  8 07:04:23 kernel: adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f
Jun  8 07:04:23 kernel: ADB keyboard at 2, handler 1
Jun  8 07:04:23 kernel: ADB mouse at 3, handler set to 4 (trackpad)
Jun  8 07:04:23 kernel: adb: finished probe task...
Jun  8 07:04:21 hal.hotplug[11262]: waiting for vc info at /class/vc/vcsa63
Jun  8 07:04:21 hal.hotplug[11262]: Dont know how to wait for vc at /class/vc/vcsa63; 
sleeping 1000 ms
Jun  8 07:04:21 hal.hotplug[11279]: waiting for vc info at /class/vc/vcs63
Jun  8 07:04:21 hal.hotplug[11279]: Dont know how to wait for vc at /class/vc/vcs63; 
sleeping 1000 ms
Jun  8 07:04:21 hal.hotplug[11290]: waiting for vc info at /class/vc/vcsa63
Jun  8 07:04:21 hal.hotplug[11290]: Dont know how to wait for vc at /class/vc/vcsa63; 
sleeping 1000 ms
Jun  8 07:04:22 pbbuttonsd.hotplug[11168]: reloading pbbuttonsd

well reloading pbbuttonsd (rescanning for which input devices are
connected) was causing oopses in -rc2 but that seems fixed in -rc3

> > kernel: ohci_hcd 0001:01:18.0: HC died; cleaning up
> > kernel: drivers/usb/input/hid-core.c: can't resubmit intr, 0001:01:18.0-1/input1, 
> > status -108
> > kernel: usb 1-1: USB disconnect, address 3
> > kernel: Badness in hcd_endpoint_disable at drivers/usb/core/hcd.c:1359
> 
> That's just a WARN_ON(strange):
> 
>          WARN_ON (!HCD_IS_RUNNING (hcd->state) && hcd->state != USB_STATE_HALT);
> 
> If the HC died, then it sure ought to be flagged as in HALT state.

I hope that helps...

This is 100% reproducable here however I would rather not want to crash
this machine too often but will happily test patches/ put debug output
etc whereever you think it would help.

Please CC me I am not subscribed to the usb-devel list.

Regards,
Soeren.



-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to