conf/145311: loader.conf can cause boot hang
Henry Grebler
henrygrebler at optusnet.com.au
Sun Apr 4 08:28:03 UTC 2010
Hi Garrett,
--> Try the following steps exhibit the same problem:
-->
-->- Remove sem_load="YES". Execute `load sem' in the bootloader.
-->- Empty out loader.conf. Then boot up with the bootloader once again and do:
-->
-->load ukbd
-->load snd_ich
-->
-->Please try all of the steps with boot -v to see what happens.
All of the following were performed with an empty loader.conf.
1. First try:
load ukbd
/boot/kernel/ukbd.ko text=...
OK
That seems a bit odd to me. I was given to understand that ukbd is
already in the kernel.
load sem
OK load snd_ich
/boot/kernel/snd_ic.ko text=...
loading required module 'sound'
/boot/kernel/snd_ic.ko text=...
OK boot -v
As far as I can tell, hangs in the same way (and the same as 3.2 of my
last email).
2. Second try (different order):
load sem
load ukbd
load snd_ich
boot -v
As far as I can tell, hangs as in 1 above.
3. Third try (omit sem):
load ukbd
load snd_ich
boot -v
Hangs.
4.
load sem
load snd_ich
boot -v
Boots ok.
5.
load ukbd
load sem
boot -v
Boots ok.
6. Different order from 3 above.
load snd_ich
load ukbd
boot -v
Hangs.
It doesn't look like module sem is relevant.
So, both modules snd_ich and ukbd must be loaded to cause the hang.
Is it possible there is some sort of interaction between them?
7. I don't know how these things work. When there is no reponse after
"load sem", does that mean it did not do anything?
I tested this hypothesis: I did:
load ukbd
load ukbd
After the first command, I got the usual response
("/boot/kernel/ukbd.ko text=..."); but when I repeated it, nothing:
OK load ukbd
/boot/kernel/ukbd.ko text=...
OK load ukbd
OK
So, why is the first command loading a file when
/usr/src/sys/i386/conf/GENERIC has a line to load the driver?
Here it is:
device ukbd # Keyboard
The man page ukbd(1) says:
To compile this driver into the kernel, place the following line
in your
kernel configuration file:
device ukbd
-->play OS'. If it's currently disabled, try enabling it. Also, try
-->disabling SMP to see if that has any affect:
-->
-->set machdep.hlt_cpus=1
Is this relevant for a machine with a single CPU?
Cheers,
Henry
More information about the freebsd-bugs
mailing list