On Monday 27 August 2012 14:59:43 Alexey Dokuchaev wrote:
> On Mon, Mar 05, 2012 at 07:10:22AM +0100, Hans Petter Selasky wrote:
> > On Monday 05 March 2012 05:17:59 Alexey Dokuchaev wrote:
> > > On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote:
> > > > On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote:
> > > > > Try the attached patch.  At least, it fixed my problem.
> > > > 
> > > > I've committed your patch with some minor modifications.
> > > > 
> > > > http://svn.freebsd.org/changeset/base/232448
> > > 
> > > Unfortunately, it does not fix resume for me; and
> > > hw.usb.no_shutdown_wait flipping did not make any difference either. 
> > > Any other ideas? Particularly, I'm curious why disabling all USB
> > > modules still does not allow this laptop to resume.  What are USB
> > > debugging techniques?
> > 
> > USB debugging:
> > 
> > Have "options USB_DEBUG" in kernel config. Then set xxx.debug = 15 under
> > hw.usb, typically hw.usb.uhub.debug=15
> 
> Today I've csupped to latest RELENG_8 (hoping that maybe the problem was
> fixed during last few months), rebuilt the kernel with USB_DEBUG option.
> 
> After fresh reboot, the following snippet releately pop up on the console
> (hand-copied):
> 
>   usb_needs_explore:
>   usb_bus_powerd: bus=0xc55cccf0              <-- bus= number changes
>   usb_bus_powerd: Recomputing power masks
>   uhub_explore: udev=0xc5647400 addr=1                <-- udev= number changes
>   uhub_read_port_status: port 1, wPortStatus=0x0100, wPortChange=0x0000,
> err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2,
> wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
> 
> (USB<->CRC32 has plugged in, no other USB devices)
> 
> Aroung zzz(8) time (keyboard die upon wake-up as described earlier with
> 100% CPU load -- fans are at full burst) debug mode yielded these:
> 
>   uhub_child_pnpinfo_string: device not on bub
>   uhub_child_location_string: device not on bub
>   uhub_child_pnpinfo_string: device not on bub
>   usb_bus_powerd: bus=0xc55e2c78
>   usb_bus_powerd: Recomputing power masks
>   uhub_read_port_status: port 1, wPortStatus=0x0500, wPortChange=0x0000,
> err=USB uhub_read_port_status: port 2, wPortStatus=0x0500,
> wPortChange=0x0000, err=USB ... up to port 8 ...
>   uhub_read_port_status: port 8, wPortStatus=0x0500, wPortChange=0x0000,
> err=USB << usual "(disconnected)" messages >>
>   usb_buf_port_set_device: bus 0xc55cccf0 devices[2] = 0
>   usb_needs_explore:
>   usb_needs_explore:
>   usb_needs_explore:
>   usb_needs_explore:
>   usb_needs_explore:
>   uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus4
>   uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
>       ... UHCI also found on usbus 2, 3, 0 (in that order)
>   uhub_attach: depth=0 selfpowered=1, parent=0, parent->selfpowered=0
>   uhub_attach: Getting HUB descriptior
>   uhub_attach: turn on port 1 power
>   uhub_attach: turn on port 1 power
>   uhub_attach: turn on port 1 power
>   uhub_attach: turn on port 1 power
>   uhub_attach: turn on port 1 power
>   uhub_attach: turn on port 2 power
>   uhub_attach: turn on port 2 power
>   uhub_attach: turn on port 2 power
>   uhub_attach: turn on port 2 power
>   uhub1: 2 ports with 2 removable, self powered
>       ... usb_needs_explore: loop quoted above repeats; system unusable
> 
> Any ideas?
> 
> ./danfe

If the USB HC is feeding too many such IRQ's it will be stuck. However, if you 
see that "uhub_read_port_status()" is called, the kernel is at least running, 
though it might be that some IRQ is stuck, hence the 100% CPU usage. Could you 
try to get some IRQ stats?

--HPS
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to