Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Jun 2011 17:49:13 +0200
From:      Damien Fleuriot <ml@my.gd>
To:        Espartano <espartano.mail@gmail.com>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: Reboot after start pf on ALIX board
Message-ID:  <4E09F7F9.3080608@my.gd>
In-Reply-To: <BANLkTimD-77ZcnUjPr-pJPmKodhpRfCr%2Bg@mail.gmail.com>
References:  <BANLkTinafJPRMWiUyyNdiiYhqiT2V7ovmg@mail.gmail.com>	<4E099A36.7000104@my.gd> <BANLkTimD-77ZcnUjPr-pJPmKodhpRfCr%2Bg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 6/28/11 4:25 PM, Espartano wrote:
> On Tue, Jun 28, 2011 at 4:09 AM, Damien Fleuriot <ml@my.gd> wrote:
>>
>> You need to define a dump device then, so that you may extract the
>> kernel's crash dump for analysis.
> 
> 
> I don't know if there is enought free space to allocate a kernel dump
> file into the Alix board's cf card, I will see if it is possible.
> 
> 
>>
>>
>>
>> [SNIP]
>>
>>
>>>
>>> Before I updated my Nanobsd image from FreeBSD 8.1 to 8.2 RELEASE my
>>> alix board worked very well, the big diference between my old nanobsd
>>> image and my new nanobsd image is that the new one have "option
>>> VIMAGE" active.
>>>
>>
>> Well, the next logical step would be to comment out the VIMAGE option
>> and rebuild a kernel don't you think ?
>>
> 
> Of course, however I wanted to know if this scenario is useful to the
> freebsd pf developers.
> 
>>
>>>
>>> Could someone help me ?
>>>
>>> If there is some another thing that you need to figure out what was
>>> happen please let me know.
>>>
>>
>> Describe the procedure you followed to update your machine.
>>
>> It is possible that you did not update correctly, who knows...
>>
>>
> 
> I don't think so, when I said "update" I really have installed Nanobsd
> using FreeBSD 8.2 from scratch.
> 
> 
> Well at this point I don't know what to do, it is useful for you that
> I try to get a kernel dump file ? or simply recompile nanobsd without
> vimage option ?
> 
> 
> Thanks a lot.



Well, you want to try things in this order:


1/ rebuild a kernel without VIMAGE and try again, while you're at it
enable debug options like the KDTRACE hooks and such.

makeoptions     DEBUG=-g                # Build kernel with gdb(1) debug
symbols
options         KDB                     # Kernel debugger related code
options         KDTRACE_FRAME           # Ensure frames are compiled in
options         KDTRACE_HOOKS           # Kernel DTrace hooks



2/ enable kernel crash dumps, reproduce problem, obtain a dump for analysis.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E09F7F9.3080608>