Resume broken in 8.3-PRERELEASE
Hans Petter Selasky
hselasky at c2i.net
Fri Mar 2 07:50:03 UTC 2012
On Thursday 01 March 2012 22:55:03 Jung-uk Kim wrote:
> On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote:
> > On Thursday 01 March 2012 18:11:25 Alexey Dokuchaev wrote:
> > > On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote:
> > > > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev
> > > > > I was mistaken, the latest kernel with working resume is from
> > > > > Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow
> > > > > my laptop to come back from zzz(8) successfully. It seems
> > > > > that offending change is rev. 188.8.131.52 of
> > > > > sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450).
> > >
> > > I've redone my bisecting, now suspending/resuming around at least
> > > ten times in console with zzz(8). I must apologize to rmacklem@,
> > > his commit has nothing to do with it. Apparently, the culprit is
> > > SVN rev 229370 on 2012-01-03 09:15:54Z by hselasky@, which
> > > (ironically enough) supposed to bring better support for USB
> > > controller suspend and resume. Kernel csuped and built before
> > > this date resumes just fine for me. However, the problem might
> > > lay deeper: disabling all USB modules (I traditionally run slim
> > > kernels with everything down to io/mem offloaded into modules)
> > > does not fix the hang, see below. Selectively disabling UHCI or
> > > EHCI does not make any difference either.
> > >
> > > Debugging of this issue is, however, complicated by the fact that
> > > doing "call doadump" results in "Dumping 68M:" message (similar
> > > problem was reported by glebius@ back in 2004), and then
> > > nothing happens except for IDE led light-up and frozen debugger,
> > > which makes post-mortem analysis with kgdb(1) impossible.
> > > Setting up serial console (since it's a laptop, the only
> > > possibility for me right now is to use some noname USB adapter
> > > via uftdi(4)) works, but kernel GDB does not like it. Perhaps
> > > I'm just not passing 0x80 flag correctly, but
> > > hint.uftdi.0.flags="0x80" does not work. Is GDB backend
> > > impossible with USB serial adapters, or I am just doing it wrong?
> > >
> > > What strikes me most is that even with plain kbdmux(4) or
> > > atkdb(4) I still cannot resume, even on previous (before r229370)
> > > kernels (the earliest I've tried is from Jan 1 00:00 UTC). Any
> > > debugging hints or patches to try are highly appreciated.
> > >
> > > Thus far, the latest kernel where resume works (with USB stuff
> > > enabled) is from Jan 3 19:15 UTC. Hans Petter, do you have any
> > > ideas about it?
> > Hi,
> > The USB controllers should be reset after resume.
> > Suspend is currently ASYNC. This might be one problem.
> > Resume is also ASYNC, because we cannot block in the
> > device_resume() callback.
> > Make sure no serial port adapters have open devices and are
> > blocking suspend and resume.
> > What is output from usbconfig as root, before and after
> > suspend/resume ?
> It does not make a difference for me (i.e., usb suspend/resume still
> broken) but I think I found a typo:
> Index: sys/dev/usb/controller/usb_controller.c
> --- sys/dev/usb/controller/usb_controller.c (revision 232365)
> +++ sys/dev/usb/controller/usb_controller.c (working copy)
> @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm)
> - bus_generic_shutdown(bus->bdev);
> + bus_generic_suspend(bus->bdev);
> Jung-uk Kim
It should be shutdown, because suspend in this case is something else.
USB suspend resume works like this:
At suspend we reset and stop all controllers.
At resume we reset and start all controllers again.
If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and see
what port change events are coming.
If cfg=255 in usbconfig, then something is wrong.
Currently suspend and resume is ASYNC, so that means we are not waiting for
the actual HC reset to complete.
More information about the freebsd-stable