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.
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. 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, or even to force a thread into context, have it dump its stacktrace, and exit. It should be relatively easy to implement.) - Godmar On 9/6/07, Godmar Back <[EMAIL PROTECTED]> wrote: > Still on the subject of UML hanging after VFS: mount, related to my > earlier email (*), I've been trying to dig deeper into what causes the > hang. When UML hangs, I observe the main thread idling, and 3 threads > being blocked in either io_getevents, read, or poll. The thread stuck > in read, in particular, is the device driver thread for the ubd > driver, which waits on a socketpair type for requests. Initially, I > suspected a bug or race condition in the code that manages the > synchronization between these threads, resulting in a lost wakeup - > specifically, a SIGIO that may not be delivered or ignored, preventing > the corresponding ubd_interrupt() from not being called. However, I'm > now beginning to have doubt whether this is in fact the reason. I > added printk's to verify that all sent requests are received and > processed. > > Upon closer examination, I observed a fifth thread that is stopped > while being ptraced (status reported as "T+" in ps.) I am surmising > that this fifth may be the init process or another thread that > performs some delayed initialization tasks. Unfortunately, since it's > being ptraced, I cannot attach gdb to it. > > Does anybody knowledgeable with UML happen to know which thread that > is so I could figure out where this thread is stuck? I assume that it > may be related to UML's ptrace-based system call emulation, but I have > not yet looked deeper into the implementation details. > > On a possibly related note, I would also like to know about where the > belief that the hang issue is related to "confusion about VDSO" is > coming from. > > - Godmar > > > > > > (*) > http://sourceforge.net/mailarchive/message.php?msg_name=719dced30709050613y73887e87x22e032332c9bb38d%40mail.gmail.com > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
