Date: Thu, 1 Mar 2012 19:53:52 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Alexey Dokuchaev <danfe@nsu.ru> Cc: "stable@freebsd.org" <stable@freebsd.org> Subject: Re: Resume broken in 8.3-PRERELEASE Message-ID: <201203011953.52600.hselasky@c2i.net> In-Reply-To: <20120301171125.GA61435@regency.nsu.ru> References: <20120227152238.GA2940@regency.nsu.ru> <20120301171125.GA61435@regency.nsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203011953.52600.hselasky>