On Mon, Apr 7, 2014 at 9:49 AM, sangdrax8 <sangdr...@gmail.com> wrote:
> I have had a kernel panic that took down my system, and I was wondering if
> someone
> can provide some insight into where I can begin with this. I had to reboot
> the machine
> to get it back up, but I did run a trace and grabbed the output from dmesg
> before I
> rebooted.
>
> If this isn't enough information, can someone help me out with what I should
> capture
> before rebooting to get the machine back up and running? Unfortunately, I
> can't
> consistently cause this crash so testing is a bit difficult.
...
> mode = 0100644, inum = 415786, fs = /var
> panic: ffs_valloc: dup alloc
> Stopped at Debugger+0x5: leave
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
> IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
> ddb{0}> ddb{0}> Debugger() at Debugger+0x5
> panic() at panic+0xe4
> ffs1_reallocblks() at ffs1_reallocblks
This means that a free inode was not correctly zeroed out previously.
This indicates that serious filesystem damage occurred previously; did
this machine crash in the middle of writes in the past and not get
fsck'ed?
At this point, I think the way to make this machine reliable again is
to newfs all the partitions. I would back up the config files and
reinstall, or rather, install a newer version.
Philip Guenther
