Dear Mr. Piggin,
thanks for your response in the first place :-)
This is interesting. I can't run any classic system command. Any
command hangs or coredumps. Any command except kill :-) Perhaps
"kill" is an internal bash command, so that it needn't fork+exec
(clone) to execute?
Anyway if I kill -9 the loopy bash process, the loopy console
respawns, I get several segfaults from udevd and dircolors (called
from .bashrc), and the new bash process on that console is no longer
loopy. But I continue to get segfaults from any commands that I try
I've compiled 2.6.23-rc6, enabled serial console and captured
the output of sysrq+P (on the affected virtual VGA console)
and sysrq+T.
http://www.fccps.cz/download/adv/frr/bonnie/2.6.23-rc6.txt
The interesting bit of information, related to the erratic "bash"
processes, is always a single line, such as:
bash R running 0 2358 1
I've also taken a photo of `top` running
on another virtual console. I can't get any data out of the
affected box, as I can't run any shell commands...
http://www.fccps.cz/download/adv/frr/bonnie/top.jpg
Note that there are rather few processes running in the user space.
Can't say if that makes any difference from a full-blown distro.
Maybe I could set up the bootable CD for download somewhere
(gzipped ISO of maybe 50 Megs).
In this scenario, Linux 2.6.16.18 once reported a soft lockup.
http://www.fccps.cz/download/adv/frr/bonnie/soft-lockup1.txt
Never again.
I also managed to catch the misbehavior in strace once, didn't
get a capture, but essentially it was stuck at a single open
syscall, I believe it was "waitpid(1, " . (Never managed that again,
always got segfaults instead of the loopy bash when trying to watch
bash by strace -p).
Exactly where does the context switch from user to kernel take place?
I know that I can call ioctl() from user space, and I can write
ioctl() handlers in kernel space as part of device drivers (the
handlers take place entirely in...
