Just as a verifier, I'm seeing this too. I haven't traced it, but
I will try to trace as far as Gordon has.
On Mon, Jan 22, 2001 at 04:38:12PM -0700, Gordon McNutt wrote:
> I've been seeing this consistently and am trying to track down the
> cause. The symptoms are all the xterms and the gdb session are locked
> I've been able to use gdb to trace the symptom down to the point where
> the lockd kernel daemon terminates. The process is dead (ps -ef on the
> real host shows it's gone). But it remains the current uml task.
> Once I'm in the locked stated I've managed to attach gdb yet again to
> the tracing deamon via 'gdb linux <pid>'. If I then ^C the first
> ('locked up') gdb session the signal does make the tracing thread return
> from waitpid and process it. It goes into proxy.c:debugger_syscall and
> tries to pass the signal on to the nonexisting lockd process.
> In general, it looks like no more rescheduling occurs once lockd
> terminates. I think the umount process should be ready to run, but this
> does no good if nobody ever invokes the scheduler. But this never seems
> to happen. If I can trust gdb, the idle loop is no longer running. And
> shouldn't the idle_timer at least be firing? Seems like we must be stuck
> with SIGVTALRM and SIGALRM blocked out, which suggests we're constantly
> handling some other signal like SIGSEGV or SIGTRAP. I think someone
> mentioned seeing a situation where UML was getting a constant stream of
> SIGSEGV's. I tried using gdb's 'handle SIGSEGV print ...' command but
> nothing took the bait.
> Any ideas?
> User-mode-linux-devel mailing list
James R. Leu