Resume broken in 8.3-PRERELEASE
Hans Petter Selasky
hselasky at c2i.net
Thu Mar 1 19:05:36 UTC 2012
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. 18.104.22.168 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?
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
What is output from usbconfig as root, before and after suspend/resume ?
More information about the freebsd-stable