Resume broken in 8.3-PRERELEASE

[Hans Petter Selasky]

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 ?

--HPS