From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 13:29:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852E11065741 for ; Thu, 25 Sep 2008 13:29:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 079138FC1B for ; Thu, 25 Sep 2008 13:29:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8PDTWLX095309; Thu, 25 Sep 2008 09:29:49 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Navdeep Parhar Date: Thu, 25 Sep 2008 08:35:35 -0400 User-Agent: KMail/1.9.7 References: <1d6d20bc0809170846g69311401j7f93f97969756e43@mail.gmail.com> <1d6d20bc0809242142ge545896u332cc8e23212383a@mail.gmail.com> <20080925071118.GA8984@insightsol.com> In-Reply-To: <20080925071118.GA8984@insightsol.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809250835.36444.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 25 Sep 2008 09:29:50 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8329/Thu Sep 25 04:47:46 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org, Jia-Shiun Li Subject: Re: Unable to boot Asus P5QL-EM w/ acpi enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 13:29:56 -0000 On Thursday 25 September 2008 03:11:18 am Navdeep Parhar wrote: > On Thu, Sep 25, 2008 at 12:42:38PM +0800, Jia-Shiun Li wrote: > > On Thu, Sep 25, 2008 at 1:35 AM, John Baldwin wrote: > > > On Wednesday 24 September 2008 01:11:31 pm jiashiun li wrote: > > >> > > >> I did a binary search and found the problem lies between 2008-08-22 > > >> and 2008-08-23. Here is my note: > > >> > > > If you grab the latest bits from HEAD you can use 'hw.pci.mcfg=0' to disable > > > memcfg. > > > > > > > Thanks, quick search the mailing list revealed some cases and your > > solution just a few days ago. I should have followed the mailing list > > more carefully. ;) > > > > Just curious, any idea why the memory mapped configuration prevents > > kernel from booting? Maybe buggy hardware, acpi code, or combination > > of both that users can help testing to find the cause? > > I would like to put in a me-too here. I've been using hw.pci.mcfg=0 > since it was introduced but I still don't know where exactly the problem > is, or how to pinpoint it (bad bios/bad hardware/bad phase of the > moon/etc). The bleeding versions of other OS'es seem to work out of the > box, though that doesn't mean much - I'm not sure what they do inside. I'm not sure. Probably other OS's aren't using this a lot yet so it is just buggy BIOS. Linux has a rather silly SMAP-related check (requires an explicit SMAP region that covers the memcfg area) that effectively disables memcfg on most boxes, so Linux probably isn't using it on your hardware either. -- John Baldwin