Re: [uml-devel] actually useful backtrace from a CPU-chewing hang

[Nix <nix@esperi.org.uk>]

On 2 May 2008, Jeff Dike verbalised:
> With your config, I'm seeing a hang until the system time catches up
> to what UML thought it should have been in the first place.  But it's
> only a few seconds, not forever.

This is true sometimes, but not always: I just tried twice and got
a rapid recovery the first time, but not the second. Trace the second
time:

0x08084b89 in update_wall_time () at kernel/time/timekeeping.c:475
475                     clock->error -= clock->xtime_interval << (TICK_LENGTH_SHIFT - clock->shift);
(gdb) bt
#0  0x08084b89 in update_wall_time () at kernel/time/timekeeping.c:475
#1  0x08077bd1 in do_timer (ticks=1) at kernel/timer.c:929
#2  0x08086314 in tick_periodic (cpu=0) at kernel/time/tick-common.c:66
#3  0x08086346 in tick_handle_periodic (dev=0x821d384) at kernel/time/tick-common.c:82
#4  0x080590ed in um_timer (irq=0, dev=0x0) at arch/um/kernel/time.c:70
#5  0x0808d3f3 in handle_IRQ_event (irq=0, action=0xdc49480) at kernel/irq/handle.c:140
#6  0x0808d471 in __do_IRQ (irq=0) at kernel/irq/handle.c:236
#7  0x080576f8 in do_IRQ (irq=0, regs=0x821bc80) at arch/um/kernel/irq.c:335
#8  0x080590a0 in timer_handler (sig=26, regs=0x821bc80) at arch/um/kernel/time.c:28
#9  0x08064c84 in real_alarm_handler (sc=0x821bd24) at arch/um/os-Linux/signal.c:93
#10 0x08064cac in alarm_handler (sig=26, sc=0x821bd24) at arch/um/os-Linux/signal.c:108
#11 0x08064d67 in handle_signal (sig=32, sc=0x821bd24) at arch/um/os-Linux/signal.c:157
#12 0x08066263 in hard_handler (sig=26) at arch/um/os-Linux/sys-i386/signal.c:12
#13 <signal handler called>
#14 getnstimeofday (ts=0xde3beec) at include/linux/time.h:182
#15 0x08084306 in do_gettimeofday (tv=0xde3bf04) at kernel/time/timekeeping.c:118
#16 0x0807396c in sys_gettimeofday (tv=0xbf8a4ad8, tz=0x0) at kernel/time.c:103
#17 0x0805a55c in handle_syscall (r=0xde66e28) at arch/um/kernel/skas/syscall.c:35
#18 0x08066cdf in handle_trap (pid=13310, regs=0xde66e28, local_using_sysemu=2) at arch/um/os-Linux/skas/process.c:202
#19 0x0806716b in userspace (regs=0xde66e28) at arch/um/os-Linux/skas/process.c:418
#20 0x08057f5a in fork_handler () at arch/um/kernel/process.c:179
#21 0x00000000 in ?? ()
(gdb) quit

> However, stracing it did reveal a bogus interval trying to be set,
> which the patch below fixes.  It doesn't cause any behavior change
> here, so YMMV.
>
> This includes the previous patch, which I think is a good idea anyway,
> so back that out and drop this in its place.

No behavioural change :(

I'm trying something else now, arranging for os_nsecs() itself to do the
never-backwards stuff on the assumption that something depends on
monotonic timers not skipping backwards which presently they might
(there are callers of os_nsecs() outside of os-Linux/time.c, notably in
kernel/time.c, and currently they see an unadjusted time, jumping
backwards and forwards and whatever).

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
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