Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Aug 2012 17:34:54 +0200
From:      Hans Petter Selasky <hselasky@c2i.net>
To:        Alexey Dokuchaev <danfe@nsu.ru>
Cc:        freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jung-uk Kim <jkim@freebsd.org>
Subject:   Re: Resume broken in 8.3-PRERELEASE
Message-ID:  <201208271734.54814.hselasky@c2i.net>
In-Reply-To: <20120827125943.GA68575@regency.nsu.ru>
References:  <20120227152238.GA2940@regency.nsu.ru> <201203050710.22871.hselasky@c2i.net> <20120827125943.GA68575@regency.nsu.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201208271734.54814.hselasky>