My build machine (dmesg attached) is a dual CPU, single-core box; my laptop is a single CPU, single-core box. I track head on each daily; while the build machine has been locking up during the transition to multi-user mode since Tuesday (when I had built CURRENT at r204909; previous was r204866, on Monday) -- and it boots to single-user mode OK -- the laptop has not exhibited the problem. This build machine was deployed fairly recently, and since a GENERIC kernel had been working OK, I had left it that way (so that's the kernel config). I have a more customized config I had used on its predecessor; I'm pretty sure I had that set up with DDB & assorted other "goodies" to try to get something useful out of a misbehaviing system, and am willing to set that up (but probably won't have time for several hours, at least, as I need to give a presentation at a work meeting). One of the more peculiar symptoms is that after such a lock-up, I power-cycle the machine, then boot to single-user mode, at which point I typically start with fsck -p However, since Tuesday, that attempt yields: Enter full pathname of shell or RETURN for /bin/sh: # fsck -p /dev/aacd0s4a: LINK COUNT DIR I=2 OWNER=root MODE=40755 /dev/aacd0s4a: SIZE=1024 MTIME=Mar 11 08:30 2010 COUNT 26 SHOULD BE 27 /dev/aacd0s4a: LINK COUNT INCREASING /dev/aacd0s4a: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. # My circumvention of choice at the moment is: # fsck -y / && fsck -p as it appears that the root file system is the only one thus affected. Is this sufficently well understood already that I should stop disturbing folks who are trying to fix it? Would it be usful for me to configure a kernel that supports DDB & provide a backtrace (and maybe additional stuff)? To clarify, it appears that something after r204866 but no later than r204909 has caused the observed problem. Thanks. Peace, david -- David H. Wolfskill david_at_catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:01 UTC