From owner-freebsd-stable@FreeBSD.ORG Tue Apr 17 14:44:16 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65671106574C; Tue, 17 Apr 2012 14:44:16 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id 04D4B8FC0A; Tue, 17 Apr 2012 14:44:16 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1SK9dN-0007Ba-4Q; Tue, 17 Apr 2012 21:43:57 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q3HEkmOJ077047; Tue, 17 Apr 2012 21:46:48 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q3HEkhKi077046; Tue, 17 Apr 2012 21:46:43 +0700 (NOVT) (envelope-from danfe) Date: Tue, 17 Apr 2012 21:46:43 +0700 From: Alexey Dokuchaev To: John Baldwin Message-ID: <20120417144643.GB70796@regency.nsu.ru> References: <20120416042645.GA53074@regency.nsu.ru> <20120416070646.GA78414@regency.nsu.ru> <4F8BD14D.8050206@rdtc.ru> <201204170840.37631.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204170840.37631.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, Eugene Grosbein Subject: Re: RELENG_8 kernel as of Apr 14 does not boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:44:16 -0000 On Tue, Apr 17, 2012 at 08:40:37AM -0400, John Baldwin wrote: > Hmm, this has been broken for a long time on HEAD and 9 it seems. However, > there you get compile breakage (as acpi is no longer supported as a module > in 9+) if you try to build a kernel with 'nodevice mem'. Yes, I am aware. Unfortunately, I am frightened to upgrade to 9.x as I have no confidence that it behaves well on my laptop. I still do not know how to fix 8.x after January which broke suspend/resume for me (EDIT: see below!). > Hmm, mp_machdep.c also breaks. That is probably true on i386 as well, and > has been true even on 7.x. (That is, you can't use 'nodevice mem' and 'SMP' > in the same kernel.) Right, I have appropriate comment about it in my kernel config file. :-) > OTOH, what are you trying to gain by putting mem.ko into a module rather > than part of the base kernel? Do you just want no /dev/mem file or are you > trying to disable all of the MTRR support as well? No, no, nothing other than checking how far can I go in putting everything possible into modules and loading them from /boot/loader.conf. I was not aware it affects MTRR support... > It may be that we need to rethink what goes into mem.ko and have it only > exclude /dev/mem but always leave MTRR support enabled. Hmm, this is interesting. I've been waiting for you to MFC r232742 to RELENG_8 as jkim@ mentioned that these are features that could be responsible for broken suspend/resume on i386. Are you saying that having loading mem.ko as module could affect certain registers restoration, and thus preventing correct resume? I've just tried to zzz/resume several times in a row with latest 8.x kernel with io/mem compiled in. Maybe I am speaking too fast, but guess what: keyboard works now, network service are accessible, bluetooth mouse works, etc. Unbelievable. My stupid "nodevice" gimmick prevented me from having working resume, LOL. I think that if we continue to install mem.ko as module, it should be clearly documented that results of such setup might be quite different from defaults. Thanks for pieces of valuable wisdom John. ./danfe