From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 24 12:35:37 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5858E1065695; Thu, 24 Sep 2009 12:35:37 +0000 (UTC) (envelope-from kama@pvp.se) Received: from ms1.as.pvp.se (dns.pvp.se [213.64.187.226]) by mx1.freebsd.org (Postfix) with ESMTP id D55618FC41; Thu, 24 Sep 2009 12:35:36 +0000 (UTC) Received: by ms1.as.pvp.se (Postfix, from userid 1001) id 84DAEB8; Thu, 24 Sep 2009 14:35:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ms1.as.pvp.se (Postfix) with ESMTP id 804C3B4; Thu, 24 Sep 2009 14:35:34 +0200 (CEST) Date: Thu, 24 Sep 2009 14:35:34 +0200 (CEST) From: kama X-X-Sender: kama@ns1.as.pvp.se To: Andriy Gapon In-Reply-To: <4ABA457E.3060800@freebsd.org> Message-ID: <20090924141927.Y37424@ns1.as.pvp.se> References: <20090921140345.H37424@ns1.as.pvp.se> <20090922103150.V37424@ns1.as.pvp.se> <4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se> <4AB8E082.8050100@icyb.net.ua> <20090922215700.V37424@ns1.as.pvp.se> <4ABA1D1F.3080704@icyb.net.ua> <20090923171004.Q37424@ns1.as.pvp.se> <4ABA457E.3060800@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.2-STABLE boot freeze (was: when calibrating clock.) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 12:35:37 -0000 On Wed, 23 Sep 2009, Andriy Gapon wrote: > on 23/09/2009 18:19 kama said the following: > > On Wed, 23 Sep 2009, Andriy Gapon wrote: > > > >> on 23/09/2009 15:47 kama said the following: > >>> g24# nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo > >>> /boot/kernel/acpi.ko: U AcpiDmDumpMethodInfo > >>> /boot/kernel/acpi.ko.symbols: U AcpiDmDumpMethodInfo > >> So this is what I was talking about - this symbol should not be undefined after > >> normal build. This symbol should not be present and referenced at all unless > >> ACPI_DISASSEMBLER is defined. > >> This is clearly a build problem of some sort. > > > > Even though they dont exists on a acpi_debug kernel. It does not really > > matter since the real problem is that freebsd freezes on a normal generic > > config. > > What is acpi_debug kernel? The one with option ACPI_DEBUG in it. > And FreeBSD does not freeze on "a normal generic config". > It freezes because of a mysterious build bug that only you seem to have (so far). > > >>> Just adding 'device acpi' into the generic kernel made it boot > >>> successfully. (without KDB DDB ACPI_DEBUG) > >> I am glad that this worked :) > > > > Me too. As a work around. But I would prefer a GENERIC kernel to boot. > > True GENERIC kernel is the one that you get from FreeBSD.Org :-) > The one that you built yourself even using GENERIC config can always get tainted > by unspecified problems with your build environment. > Can you reproduce this problem if you build world, install it somewhere, chroot to > it and then build a GENERIC kernel? (with no tweaking between the steps) Actually I spoke to fast. After an reboot it hanged again. > >From practical point of view, I don't see why moving acpi from module to kernel > could be an issue. > > >>> Here are the outputfiles suggested from the webpage: > >>> > >>> http://fbsd-err.pvp.se/acpidump_acpi_compiled.asl > >>> http://fbsd-err.pvp.se/dmesg_acpi_compiled.txt > >>> http://fbsd-err.pvp.se/sysctl_acpi_compiled.txt > >> This doesn't make it nay clearer why you get that build problem. > > > > I dunno. I dont have any insight into kernel programming. Hence trying to > > get information how to help the people to fix the actual problem. That the > > server freezes at boot. Im kind of lucky to have HP ILO on my side, to > > test things. =) > > > > But I will upgrade the BIOS. If that does not work, I'll try a clean > > 7.2-REL install. > > BIOS upgrade may improve some things for you, but I'd be very surprised if it > fixes the build problem in question. Well, it did not improve anything. Apperently the output from ILO is not the correct one. Probably it freezes the output to ILO before it can update the screen. (I run ILO through SSH) I took a photo of the actual output presented on a CRT. http://fbsd-err.pvp.se/fbsd-freeze-dl385.jpg (sorry for the blury image, but I cant get it any better from my cellphone) I did not have time to reinstall the system from scratch. But that can be done remotely if needed. I am currently building the source on another machine. Lets see if it will build it any better. (Remember that this happens on two different servers that are specified the exact same way) /Bjorn