Kernel Panic: "ufs_dirrem: Bad link count 2 on parent"

G

Gereon

I regularly encounter kernel panics on my laptop. When not interrupting wlan0 (a bcm wireless adapter working through an ndisgen(8) made kernel module) waiting for a link, I nearly always get a kernel panic, with the info.N containing the following:
Code: 
Dump header from device /dev/ada0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 289755136B (276 MB)
  Blocksize: 512
  Dumptime: Sun Feb  3 16:18:30 2013
  Hostname: veredus
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 9.1-STABLE #4 r246115: Sat Feb  2 14:29:28 GMT 2013
    root@:/usr/obj/usr/src/sys/GENERIC
  Panic String: page fault
  Dump Parity: 2576771399
  Bounds: 3
  Dump Status: good

It used to run fine when I interrupted the process at that point, even with running # /etc/rc.d/dhclient start wlan0 later to obtain an IP address from my network. Having read somewhere (if I remember correctly) that this panic might be a race condition and would be fixed in a new version of the operating system, I set out to update my operating system from the original 9-RELEASE to stable/9 from ctm-svn. Not only do I still in nearly all cases get the kernel panic described above, now I also encounter a different one which I cannot recall having seen before. If I let the machine run for some time (usually maybe four hours), the kernel panics telling me
Code: 
Dump header from device /dev/ada0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 642379776B (612 MB)
  Blocksize: 512
  Dumptime: Sun Feb  3 15:42:54 2013
  Hostname: veredus
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 9.1-STABLE #4 r246115: Sat Feb  2 14:29:28 GMT 2013
    root@:/usr/obj/usr/src/sys/GENERIC
  Panic String: ufs_dirrem: Bad link count 2 on parent
  Dump Parity: 1700401510
  Bounds: 2
  Dump Status: good

Is there an obvious solution to this double problem, or how should I continue to find help getting this fixed?
 
To get a clean start, I would disable background fsck(8) in /etc/rc.conf. Then boot into single user mode and manually make sure fsck(8) completes:
# fsck -tufs -y

A longer-term solution would be to replace the Broadcom card with an Atheros card. Admittedly a hassle, but short-term pain to eliminate long-term pain.
 
I have run fsck on my ufs systems, which did not find any problems.
Unfortunately, I don't think changing the network card is possible, because the machine is owned by my university, and even getting them to remove the BIOS password in order to install FreeBSD was a hassle.
On the other hand, it turns out the second kernel panic does not occur randomly:
While that does not mean it has nothing to do with the Broadcom card, it always occurs when I rebuild devel/dbus, something I did quite frequently in the last few days, because my system upgrades were always interrupted by a kernel panic before dbus was updated...
The danger of the first panic occurs more often (as that happens during every reboot), but the second panic is much more annoying because it means I cannot update my system properly.
(In particular, I foolishly did not backup my packages before rebuilding, X depends on dbus, so now I'm stuck in terminal mode with a text browser.)

How do I deal with a kernel panic during reinstallation of dbus? (I still need to check in which part of the installation process the panic occurs, but I'll post this first before it gets lost.)
 
You must log in or register to reply here.
Back
Top