printing boot probe messages

Sun Dec 30 15:17:29 PST 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Jeremy wrote:
> On Sat, Dec 29, 2007 at 01:58:32PM -0500, Chuck Robey wrote:
>> booting.  If I stick "-v" in /boot.config, then when the kernel probes, all
>> the probes are verbose.  Stuff like my HDaudio card print incredibly
>> verbose listings.  OK, that's what I will call here Print#1
>>
>> The other thing is what I can see if I see the ascii-graphical loader (the
>> picture, in ascii-graphics, either of a BSDaemon, or of the letters
>> "FreeBSD", and a list of about 9 options for booting.  If I select item #5,
>> then I get a listing.  The listing is quite distinct from what I identify
>> as Print#1, so I'll call this Print#2.  If I either hit return at that
> 
> There are no distinct names for what you call Print#1 and Print#2
> because these outputs should be identical.  Within the kernel, the
> verbosity is controlled by a boolean flag "bootverbose" - which is
> visible via sysctl as "debug.bootverbose".

I just went thru a long series of reboots, so I can make really certain I
have this correct.  I had some stuff wrong before, I can see that.  The
state really is, the only way I can provoke printing of boot messages
during booting is to call out a verbose boot.  If I do that, then the boot
messages DO print during booting, and examination afterwards shows a big
file (~ 60K in size).  This happens if I use /boot.config==-v, or if I
enter option #5 to the beastie menu, or even if I call out a manual loader
run, and enter boot -v at the prompt.

If I do none of those things, it will not print boot messages.  After
booting, if I do a "dmesg > dm" then the resulting file is only about 10k
in size, and things like the enormous pci probing don't show up.  At this
moment, I'm in a boot that wasn't printed, and I just got a 0 back from a
"sysctl debug.bootverbose"

> 
> What differences are you seeing between the two outputs?
> What is the content of your /boot.config and /boot/loader.conf (and
> any other files you have changed in /boot)?

Right now, I moved my /boot.config to /notboot.config.  My loader.conf is

boot_mute="NO"
verbose_loading="YES"
linux_load="YES"
#snd_hda_load="YES"
#beastie_disable="NO"
#loader_logo="beastiebw"
nvidia_load="YES"

The nvidia thing is because I brought to sources for the nvidia graphics
card I use to the point where it compiles for current, and I have that
working ok (although I haven't found any way to test it yet).  I do notice
that I have verbose_loading set to YES, but that never seemed to show any
effects.  I have experimented (not recently, but after I lost the boot
messages) and I never saw any differences from it.  The boot_mute line was
another of my efforts to get printing to start up, it didn't have any
effect either.

> 
> Can you please provide the output from  and "kenv"
> in the the above two cases as well as a default boot.

Sure.  "sysctl debug.boothowto" returns -2147418112, any idea what that
means?  The kenv stuff is long, but I'll stick it at the end, here.

> I presume you aren't seeing any of this odd behaviour when you boot
> from an install CD.

Never tried it.  I have a trash ide disk that I initially booted from,
before I got my raid up, it's still available to boot from, and yes, it
prints it's boot messages during boot, just fine.  When I switch to that,
it's the whole / including /boot and /usr, it's 80G big.

  It would really help if you reverted back to a
> stock GENERIC kernel, with no local mods in / or /boot and then
> started re-applying your changes one at a time to see what has gone wrong.

Hoping not to have to do that. but if this here doesn't seem tog et
anywhere with it, that's the only choice I will have if I want to see
things fixed.  Luckily for me, that trash ide drive is available to me
still, so I'd have to do that one.  Just didn't want to do that, I have the
audio still to work at, and then some others things fro friends, but if
there's no choice, then I guess I will have to.

> 
>> I'm beginning, right now, to wonder: I increased the dmesg-buffer to 64K, I
>> wonder if maybe that might possibly cause the bug?  I know it shouldn't,
>> but it wouldn't be the first time this week that I found weird behaviour in
>> the kernel: if you set the number of vtys from the default 16 down to 8,
>> that caused me to lose keyboard input to my X11.
> 
> None of this should happen either.
> 
Well, Des explained the x11 thing, it turns out that you must turn "off"
the highest numbered vty, so that X11 has a place to land.  That nearly
fooled me, because it's set in /etc/ttys to xdm, and I never use xdm, so I
thought I didn't need that, but it turns out that it's the fact that the
top vty is turned off which is the magic in that case, not the setting it
to xdm.  I just proved that here.

HERE'S THE KENV LISTING  I still can't provoke the non-verbose boot messges
to print during boot (I can get them via dmesg later  on, though).

TCSH-april:chuckr:~:#105-17:43>kenv
LINES="24"
acpi_load="YES"
boot_mute="NO"
bootfile="kernel"
comconsole_speed="9600"
console="vidconsole"
currdev="disk2s1a:"
hint.acpi.0.oem="Nvidia"
hint.acpi.0.revision="2"
hint.acpi.0.rsdp="0xf7bc0"
hint.acpi.0.rsdt="0xcfef3040"
hint.acpi.0.xsdt="0x00000000cfef30c0"
hint.acpi.0.xsdt_length="36"
hint.apm.0.disabled="1"
hint.apm.0.flags="0x20"
hint.ata.0.at="isa"
hint.ata.0.irq="14"
hint.ata.0.port="0x1F0"
hint.ata.1.at="isa"
hint.ata.1.irq="15"
hint.ata.1.port="0x170"
hint.atkbd.0.at="atkbdc"
hint.atkbd.0.irq="1"
hint.atkbdc.0.at="isa"
hint.atkbdc.0.port="0x060"
hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
hint.fd.1.at="fdc0"
hint.fd.1.drive="1"
hint.fdc.0.at="isa"
hint.fdc.0.drq="2"
hint.fdc.0.irq="6"
hint.fdc.0.port="0x3F0"
hint.psm.0.at="atkbdc"
hint.psm.0.irq="12"
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
hint.vga.0.at="isa"
hint.vt.0.at="isa"
hint.vt.0.disabled="1"
interpret="OK"
kernel="kernel"
kernel_options=""
kernelname="/boot/kernel/kernel"
loaddev="disk2s1a:"
mac_ifoff="NO"
module_path="/boot/kernel;/boot/modules"
smbios.bios.reldate="03/28/2007"
smbios.bios.vendor="Phoenix Technologies, LTD"
smbios.bios.version="ASUS StrikerExtreme ACPI BIOS Revision 1102"
smbios.chassis.maker="Chassis Manufacture"
smbios.chassis.serial="EVAL          "
smbios.chassis.tag="123456789000"
smbios.chassis.version="Chassis Version"
smbios.planar.maker="ASUSTeK Computer INC."
smbios.planar.product="StrikerExtreme"
smbios.planar.serial="123456789000"
smbios.planar.version="1.XX    "
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="System manufacturer"
smbios.system.product="System Product Name"
smbios.system.serial="System Serial Number"
smbios.system.uuid="6451934a-5599-db11-875b-460d620676ae"
smbios.system.version="System Version"
vfs.root.mountfrom="ufs:/dev/da0s1a"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHeCYxz62J6PPcoOkRAt8TAJwLftRbTY4Fh8tW9P9Dkg1GfPVLZwCgmY0T
NcR5r3BC5WTpuLE7A654Di8=
=MxUr
-----END PGP SIGNATURE-----