Getting kernel trap 12 During Boot Of 8.1-PRERELEASE
Lowell Gilbert
freebsd-questions-local at be-well.ilk.org
Sun Jul 4 17:06:04 UTC 2010
Tim Daneliuk <tundra at tundraware.com> writes:
> On 7/4/2010 10:32 AM, Lowell Gilbert wrote:
>> Tim Daneliuk <tundra at tundraware.com> writes:
>>
>>> I've seen this twice now - once last Sunday, and once again today
>>> when I tried to do a build/installworld/kernel with daily sources
>>> from the master tree:
>>>
>>> http://www.mediafire.com/imageview.php?quickkey=qmhizdtnhyo&thumb=4
>>
>> That asked me to jump through too many hoops over multiple domains, so I
>> didn't actually see it. I'll assume it's just more information on the
>> error in your subject line.
>
> I'm not sure what you mean. It should take you to a screenshot of
> the problem. What does "too many hoops" mean in this context?
I had clicked through a couple of "click here to download picture"
screens (each trying to push a pop-up) before I decided it looked too
much like malware.
>>> The system boots fine single-user, so I don't suspect the base
>>> kernel functionality.
>>
>> Maybe.
>>
>> What you should do is install the kernel *before* the userland. If you
>> already did that, then make sure youtry with a GENERIC kernel.
>
> I did exactly that, though I did not try the GENERIC kernel. My conf
> looks like this:
>
>
> include GENERIC
>
> ident MACHINENAME
>
> options IPFIREWALL
> options IPDIVERT
>
> options VESA
>
> # System console options
>
> options SC_DISABLE_REBOOT # disable reboot key sequence
> options SC_HISTORY_SIZE=200 # number of history buffer lines
> options SC_PIXEL_MODE # add support for the raster text mode
>
> # The following options will change the default colors of syscons.
>
> options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)"
> options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)"
> options SC_KERNEL_CONS_ATTR="(FG_RED|BG_BLACK)"
> options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)"
None of those look interesting (by which I mean "dangerous"), but it's
still worth trying a GENERIC kernel. Also, minimize the software
started at bootup in order to reduce the number of variables.
If it's still crashing at that point, go to the Handbook (or maybe it's
the Developers' Handbook?) for instructions on diagnosing crashes. If
not, then re-enable the userland stuff gradually to find the culprit.
It also may be useful to look at the -STABLE mailing list, as at least
one crash problem has been solved recently.
Good luck.
More information about the freebsd-questions
mailing list