Panic after "in_cksum_skip: out of data by 260"
EirikØverby
ltning at anduin.net
Wed Apr 13 03:41:04 PDT 2005
On 13-04-05 12:37, "Jeremie Le Hen" <jeremie at le-hen.org> wrote:
>>> I have no idea about what could have caused this, but in this case, it
>>> would be useful to have a crashdump and its associated kernel.debug file,
>>> or at least a backtrace (but you must have enabled the break to debugger
>>> on panic). I guess you could also use addr2line(1) to determine which
>>> function caused the panic from the instruction pointer, but it's likely
>>> not enough to help understanding the problem.
>>
>> I understand that, but this is a production server that has otherwise been
>> stable for a long time. I suspect that this won't happen again for a while.
>>
>> I'll reconfigure it as you suggest at the next opportunity ;)
>
> In case of a production server, you should be sure that you want to
> drop to debugger on panic since the machine won't reboot itself and
> thus will be down until human intervention. What I would advise you
> for now is to configure your rc.conf(5) in order to allow rc.d/savecore
> to save a coredump (see my previous mail).
On it. Besides, the server fails to reboot at this stage anyway, so it
doesn't matter. The server is surveilled 24/7 and all personnel at the
monitoring centre knows how to reboot it via power sockets (remote
controlled).. Whoever invented those should receive a nobel prize or
something ;)
> Since you must have rebooted your server now without having dumpdev and
> dumpdir set in rc.conf(5) at boot time, you should manually run
>
> dumpon -v $your_swap_device
>
> With this, upon next panic, FreeBSD will try to dump the whole memory
> into you swap device and then rc.d/savecore will save it in a file
> when booting.
>
> Finally, be sure that you will have enough space on the filesystem
> where $dumpdir points to.
Thanks for your advice!
/Eirik
> Regards,
More information about the freebsd-current
mailing list