It's probing the hardware and reporting on what it finds. What specific parts of dmesg are causing the mystery?dmesg shows loads of info before it mounts root. How does it do that?
It's probing the hardware and reporting on what it finds. What specific parts of dmesg are causing the mystery?dmesg shows loads of info before it mounts root. How does it do that?
Loader uses bios calls to read the disk. Once the kernel gets control it uses the driver. The FreeBSD drivers are more aggressive, using DMA and interrupts. The bios uses device polling for I/O. Though more reliable it's slow.This is something I always wondered about but never asked.
dmesg shows loads of info before it mounts root. How does it do that? You need to mount root to read /etc/fstab... obviously not, but it sounds logical...
This continues to be a great mystery to me.
It's a ring buffer. When syslogd starts it fetches the contents of the ring buffer and writes it to wherever syslog.conf says it should.dmesg
Boot messages are stored by the kernel even before syslog service is started.
& by configuring syslog you can also log console messages of the boot process.
This is something I always wondered about but never asked.
dmesg shows loads of info before it mounts root. How does it do that? You need to mount root to read /etc/fstab... obviously not, but it sounds logical...
This continues to be a great mystery to me.
Eventually decided on:-
kern.cam.boot_delay="5000"
kern.cam.scsi_delay="1000"
Not sure if this is optimal for the hardware but I can live with that.
I just checked that I hadn't made a typo, and that is what I do have.Given that 5000 was original kern.cam.boot_delay, it must be kern.cam.scsi_delay that fixed things by setting it to 1000 (1 second), right?
So what was the original value of kern.cam.scsi_delay?
Looks like you're right, it seems to have access to the root of a system FS. Makes me wonder why it stops instead of falling back to single user mode. I'm lost on this one, an xhci versus USB3 issue perhaps?No, as cy@ and others pointed out, we're in the loader already, from the disks' bootcode, now looking for which kernel to load.
After quite a bit of experimenting today, I settled on:-Given that 5000 was original kern.cam.boot_delay, it must be kern.cam.scsi_delay that fixed things by setting it to 1000 (1 second), right?
So what was the original value of kern.cam.scsi_delay?
The default is 0, not 10000.So, just as an experiment, I set it to 10000, the supposed default, and it booted, then I commented out the value, and it stopped at the mountroot prompt. Weird!
grep -A1 SYSCTL_INT /usr/src/sys/cam/cam_xpt.c | grep boot_delay
SYSCTL_INT(_kern_cam, OID_AUTO, boot_delay, CTLFLAG_RDTUN,
&xsoftc.boot_delay, 0, "Bus registration wait time");
grep -A1 kern.cam.boot_delay /boot/defaults/loader.conf
#kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM bus
# registration, useful for USB sticks as root