Re: [uml-user] hang after VFS: Mounted root (ext3 filesystem) readonly.

[Jeff D. <jd...@ad...>]

On Fri, Sep 07, 2007 at 08:49:49AM -0400, Godmar Back wrote:
> For completeness, and to help people googling for this particular
> error, I'd like to briefly report the outcome of my investigation. I'm
> happy to report (if a bit embarrassed) that operator error was to
> blame. That piece of code I had added was in fact executed, and it led
> to a deadlock when UML loaded the init process. Therefore, at least as
> of now, it appears that a host FC6 can run UML 2.6.22.5 without
> suffering from the hang described on the UML website, both statically
> linked and dynamically linked.

Good :-)  Glad to see that I don't have to fix anything here.

> As a bit of background (and I'm wondering if this should be mentioned
> on the UML website where this error is described) - hanging after VFS:
> Mount root... simply means that the init process doesn't start, for
> whatever reason.

init does start, but for whatever reason, it fails to make progress.

The usual reason is something causing a segfault, which can't be fixed
by mapping in a page.  So, init just takes an infinite series of
segfaults, and the UML just appears to hang.

> Normally, it would take all but a second to debug,
> however, it appears that deadlocked tasks - in my case, waiting to
> down a semaphore already downed - are in a stopped state in which you
> cannot attach gdb to them. (I'm wondering if there's any way to get
> UML to provide a dump of processes, 

uml_mconsole <umid> sysrq t

> or even to force a thread into
> context, have it dump its stacktrace, and exit. It should be
> relatively easy to implement.)

Attach gdb to the UML, put a breakpoint on show_regs, and in another
shell, uml_mconsole <umid> stack <pid>.  gdb will hit the breakpoint
in the context of the desired process and you can examine the stack.

				Jeff

-- 
Work email - jdike at linux dot intel dot com