Date: Fri, 2 Mar 2012 00:11:25 +0700 From: Alexey Dokuchaev <danfe@nsu.ru> To: stable@freebsd.org Cc: hselasky@freebsd.org Subject: Re: Resume broken in 8.3-PRERELEASE Message-ID: <20120301171125.GA61435@regency.nsu.ru> In-Reply-To: <20120227152238.GA2940@regency.nsu.ru> References: <20120223025713.GA65874@regency.nsu.ru> <20120227142815.GA86253@regency.nsu.ru> <20120227152238.GA2940@regency.nsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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? ./danfe [1] http://lists.freebsd.org/pipermail/freebsd-current/2004-May/027732.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120301171125.GA61435>