SMP deadlock during multi-user mode transition after r204866
David Wolfskill
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 da...@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.
David Wolfskill
> 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 appears to be resolved as of r205078 -- thanks!
> ...