RELENG_8 kernel as of Apr 14 does not boot

Eugene Grosbein egrosbein at rdtc.ru
Tue Apr 17 13:08:44 UTC 2012


> On Monday, April 16, 2012 3:59:09 am Eugene Grosbein wrote:
>>>>> Just update my 8.x kernel sources last weekend, and newly built kernel did
>>>>> not boot for me:
>>>>>
>>>>> link_elf: symbol mem_range_softc undefined
>>>>> KLD file acpi.ko - could not finalize loading
>>>>> kernel trap 12 with interrupts disabled
>>>>
>>>> Try to add 'device mem' to your kernel configuration.
>>>
>>> :-)
>>>
>>> I explicitly have "nodevice mem" and "nodevice io" in my config.  They are
>>> being loaded from /boot/loader.conf.  This worked fine for quite a while.
>>>
>>> I will try to have it compiled-in, but would still prefer it fixed, or in
>>> case it cannot be fixed and mem.ko cannot be loaded separately from now on,
>>> appropriate entry in UPDATING.
>>
>> It seems John Baldwin brought dependency of acpi.ko on device mem
>> 4 days ago to RELENG_8 with MFC:
>>
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/acpica/acpi_wakeup.c#rev1.50.2.3
> 
> Hmm, this has been broken for a long time on HEAD and 9 it seems.  However, there
> you get compile breakage (as acpi is no longer supported as a module in 9+) if you
> try to build a kernel with 'nodevice mem'.
> 
> Hmm, mp_machdep.c also breaks.  That is probably true on i386 as well, and has
> been true even on 7.x.  (That is, you can't use 'nodevice mem' and 'SMP' in the
> same kernel.)
> 
> The simplest fix is to just move mem_range_softc out of mem.ko into the base kernel.
> 
> OTOH, what are you trying to gain by putting mem.ko into a module rather than part of
> the base kernel?  Do you just want no /dev/mem file or are you trying to disable all
> of the MTRR support as well?  It may be that we need to rethink what goes into mem.ko
> and have it only exclude /dev/mem but always leave MTRR support enabled.

I guess, Alexey just tries to make smallest possible kernel just for fun :-)
Or, for PicoBSD case where kernel should be booted from very small media and modules from another one.

Eugene Grosbein


More information about the freebsd-stable mailing list