The fixed timer patch you posted a few weeks back has indeed fixed my
select()-based timeout woes.
Unfortunately, both with the old kludgy approach and with the new
remain-versus-max estimator code, I see intermittent tight lockups of
the UML kernel-space ptrace thread, with that thread chewing all
available CPU time and the virtual machine, unsurprisingly, going
unresponsive. sysprof seems unwilling to extract anything out of this,
even though it has debugging info; gdb-attachment is somewhat more
informative. A few snapshots a few seconds apart in an instance that had
been looping for some time:
0x080836c2 in update_wall_time ()
0x080836b3 in update_wall_time ()
0x08083b32 in current_tick_length ()
0x08083644 in update_wall_time ()
0x0808368e in update_wall_time ()
I'm willing to bet that, in the loop in update_wall_time(), `offset' is
somehow going negative: and as it's an unsigned value that's a bit
problematic. Unfortunately I can't see any way that could happen, unless
something is smashing it or changing clock->cycle_interval and racing
with the loop conditional test.
I'll instrument that loop and try to figure it out.
--
`The rest is a tale of post and counter-post.' --- Ian Rawlings
describes USENET
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
