FreeBSD 7.2-STABLE boot freeze (was: when calibrating clock.)
kama at pvp.se
Thu Sep 24 12:35:37 UTC 2009
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.
(sorry for the blury image, but I cant get it any better from my
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)
More information about the freebsd-stable