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

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

I suspect this can go wrong anywhere, but it happens to have been a
CBQ-triggered gettimeofday() while sending an arp that did it. (My ADSL
router pretty much bombs the poor damn machine with ARP packets all the
time.)

#0  getnstimeofday (ts=0x8217d10) at include/linux/time.h:182
#1  0x080824b4 in ktime_get_ts (ts=0x8217d10) at kernel/hrtimer.c:122
#2  0x0808244b in ktime_get () at kernel/hrtimer.c:58
#3  0x08148d93 in cbq_dequeue (sch=0xdde3800) at include/net/pkt_sched.h:53
#4  0x08143355 in __qdisc_run (dev=0xded1800) at net/sched/sch_generic.c:85
#5  0x08137991 in dev_queue_xmit (skb=0xdc89380) at include/net/pkt_sched.h:89
#6  0x08185537 in arp_xmit (skb=0xdc89380) at net/ipv4/arp.c:668
#7  0x08185574 in arp_send (type=1, ptype=2054, dest_ip=3457507285, dev=0xded1800, src_ip=2668538048, dest_hw=0xdd65244 "", src_hw=0xded192c "\002`\227yâÁ", target_hw=0x0) at net/ipv4/arp.c:694
#8  0x08184fb2 in arp_solicit (neigh=0xdd65220, skb=0x0) at net/ipv4/arp.c:379
#9  0x0813c898 in neigh_timer_handler (arg=232149536) at net/core/neighbour.c:866
#10 0x08077afd in run_timer_softirq (h=0x823a3ec) at kernel/timer.c:664
#11 0x080740a4 in __do_softirq () at kernel/softirq.c:234
#12 0x0807412e in do_softirq () at kernel/softirq.c:271
#13 0x08074186 in irq_exit () at kernel/softirq.c:310
#14 0x080576fd in do_IRQ (irq=0, regs=0x8217ec4) at arch/um/kernel/irq.c:336
#15 0x080590a0 in timer_handler (sig=26, regs=0x8217ec4) at arch/um/kernel/time.c:28
#16 0x08064c84 in real_alarm_handler (sc=0x0) at arch/um/os-Linux/signal.c:93
#17 0x08064cac in alarm_handler (sig=26, sc=0x0) at arch/um/os-Linux/signal.c:108
#18 0x080654a0 in deliver_alarm () at arch/um/os-Linux/time.c:117
#19 0x08065640 in idle_sleep (nsecs=<value optimized out>) at arch/um/os-Linux/time.c:181
#20 0x080580d4 in default_idle () at arch/um/kernel/process.c:248
#21 0x080580fe in cpu_idle () at arch/um/kernel/process.c:256
#22 0x081afdee in rest_init () at init/main.c:453
#23 0x0804953b in start_kernel () at init/main.c:650
#24 0x0804a7e1 in start_kernel_proc (unused=0x0) at arch/um/kernel/skas/process.c:46
#25 0x08064261 in run_kernel_thread (fn=0x804a7b5 <start_kernel_proc>, arg=0x0, jmp_ptr=0x821d184) at arch/um/os-Linux/process.c:267
#26 0x08057ee0 in new_thread_handler () at arch/um/kernel/process.c:151
#27 0x00000000 in ?? ()

(gdb) frame 1
#1  0x080824b4 in ktime_get_ts (ts=0x8217d10) at kernel/hrtimer.c:122
122                     getnstimeofday(ts);
(gdb) print *ts
$3 = {tv_sec = -1963377075, tv_nsec = 320917000}

It's stuck inside timespec_add_ns(), never leaving: this has been
inlined, so spying on its locals or parameters with GDB is pretty much a
no-hoper :/

Still, it's obvious enough to me that __get_nsec_offset() is returning a
negative value in getnstimeofday(), so timespec_add_ns() is looping,
well, not *forever*, but near enough, trying to push that u64 back down
to zero in units of NSEC_PER_SEC...

I hope this gives you a bit more of a clue.


-------------------------------------------------------------------------
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