Re: Resume broken in 8.3-PRERELEASE

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
> 
> wrote:
> > > > > 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. 1.9.2.5 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[1] 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)
> 
>  	USB_BUS_UNLOCK(bus);
> 
> -	bus_generic_shutdown(bus->bdev);
> +	bus_generic_suspend(bus->bdev);
> 
>  	usbd_enum_lock(udev);
> 
> Jung-uk Kim

Hi,

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.

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