From a cursory look, only two threads stand out:
ffffff003d30bc80 fffffffffbc238f0 0 0 100 0
PC: panic_idle+0x23 THREAD: unix`thread_create_intr()
stack pointer for thread ffffff003d30bc80: ffffff003d30b7a0
ntv_rdmsr_xc+0x81()
call_func_ntv+0xb6()
1()
tsc_read+3()
gethrtime+0xd()
drv_usecwait+0x98()
nge_check_copper+0x10a()
nge_factotum_link_check+0x23()
nge_chip_factotum+0x7a()
av_dispatch_softvect+0x5f()
dispatch_softint+0x34()
switch_sp_and_call+0x13()
dosoftint+0x59()
do_interrupt+0x108()
_interrupt+0xba()
fakesoftint_return()
disp_lock_exit_nopreempt+0x44()
cv_wait+0x54()
taskq_thread+0x157()
thread_start+8()
ffffff003d5d5c80 fffffffffbc238f0 0 0 105 0
PC: panic_idle+0x23 THREAD: unix`thread_create_intr()
stack pointer for thread ffffff003d5d5c80: ffffff003d5d5900
6()
bcopy+0xa()
nge_receive+0x1a()
nge_intr_handle+0x119()
nge_chip_intr+0x7e()
av_dispatch_autovect+0x78()
dispatch_hardint+0x2f()
switch_sp_and_call+0x13()
do_interrupt+0xa0()
_interrupt+0xba()
dispatch_softint+0x27()
switch_sp_and_call+0x13()
dosoftint+0x59()
do_interrupt+0xfe()
_interrupt+0xba()
mach_cpu_idle+0x17()
cpu_idle+0xc8()
idle+0x10e()
thread_start+8()
Both are handling nxge interrupts. Neither seems to be blocked:
- the first one is in the busy wait loop, probably in nge_mii_access()
(not shown due to tail call optimization), 30 attempts max 10 usec each;
- the second one is bcopying some data;
Are you sure the boot process really hangs or is just very slow? There's
a bunch of nxge instances (12?) which might take a while to complete
net-physical. On a live system under kmdb, it would make sense to
capture threadlist several times and see if it changes over time.
-Artem
_______________________________________________
networking-discuss mailing list
[email protected]
