Fajar A. Nugraha wrote:
On Wed, Feb 18, 2009 at 2:45 AM, Mark Johnson <[email protected]> wrote:
The [0]> prompt stilll appear on VGA console (not serial), which is
hard to capture even with ILO GUI console.
really? You had -B console=ttya?
Ah, sorry. My bad. I use
module$ /platform/i86xpv/kernel/$ISADIR/unix
/platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS,disable-qlc=true
console=ttya
when it should be
module$ /platform/i86xpv/kernel/$ISADIR/unix
/platform/i86xpv/kernel/$ISADIR/unix -B
$ZFS-BOOTFS,disable-qlc=true,console=ttya
Anyway, here's threadlist output
http://pastebin.com/f6c5f5918
Hmm, that's odd.. if you continue a while longer
([0]> ,10:c ) do you still see these two threads
stuck at the same point?
fffffffffbc601a0 fffffffffbc5f530 fffffffffbc61d90 0 96 0
PC: _resume_from_idle+0xfa CMD:
stack pointer for thread fffffffffbc601a0: fffffffffbc92850
[ fffffffffbc92850 _resume_from_idle+0xfa() ]
mutex_enter+0x10()
kmem_cache_alloc+0x13a()
vmem_alloc+0x1bc()
segkmem_xalloc+0x94()
segkmem_alloc_vn+0xcd()
segkmem_alloc+0x24()
vmem_xalloc+0x547()
vmem_alloc+0x161()
kmem_slab_create+0x81()
kmem_slab_alloc+0x5b()
kmem_cache_alloc+0x13a()
kmem_zalloc+0x6a()
callout_hash_init+0x32()
callout_cpu_online+0x157()
callout_mp_init+0x25()
main+0x2c3()
_locore_start+0x80()
ffffff0012ccbc60 fffffffffbc5f530 fffffffffbc61d90 0 109 0
PC: thread_start THREAD: thread_create_intr()
stack pointer for thread ffffff0012ccbc60: ffffff0012ccb840
dtrace_xpv_gethrtime+0x51()
hilevel_intr_prolog+0x35()
do_interrupt+0xd4()
xen_callback_handler+0x36e()
xen_callback+0xcd()
cyclic_timer+0x168()
cyclic_softint+0xdc()
cbe_softclock+0x1a()
av_dispatch_softvect+0x5f()
dispatch_softint+0x38()
switch_sp_and_call+0x13()
dosoftint+0x59()
do_interrupt+0xf7()
xen_callback_handler+0x36e()
xen_callback+0xcd()
mutex_enter+0x10()
kmem_cache_alloc+0x13a()
vmem_alloc+0x1bc()
segkmem_xalloc+0x94()
segkmem_alloc_vn+0xcd()
segkmem_alloc+0x24()
vmem_xalloc+0x547()
vmem_alloc+0x161()
kmem_slab_create+0x81()
kmem_slab_alloc+0x5b()
kmem_cache_alloc+0x13a()
kmem_zalloc+0x6a()
callout_hash_init+0x32()
callout_cpu_online+0x157()
callout_mp_init+0x25()
main+0x2c3()
_locore_start+0x80()
Also, if you see the THREAD: attach_drivers()
stuck too...
ffffff001300dc60 fffffffffbc5f530 0 0 60 ffffff001300da40
PC: _resume_from_idle+0xfa THREAD: attach_drivers()
stack pointer for thread ffffff001300dc60: ffffff001300d9c0
[ ffffff001300d9c0 _resume_from_idle+0xfa() ]
swtch+0x160()
sema_p+0x1cf()
mod_load+0xe6()
mod_hold_installed_mod+0x75()
modrload+0xcd()
modload+0x18()
mod_hold_dev_by_major+0x8e()
ddi_hold_driver+0x15()
ddi_hold_installed_driver+0x1c()
attach_drivers+0x37()
thread_start+8()
Take the upper left address and dump the stack with
params.. e.g.
ffffff001300dc60::findstack -v
Then dump the two strings passed to modload().
e.g.
modload+0x10(fffffffffbb8ef38, ffffff014667f1e8)
mod_hold_dev_by_major+0x8e(94)
[0]> fffffffffbb8ef38/s
0xfffffffffbb8ef38: drv
[0]> ffffff014667f1e8/s
0xffffff014667f1e8: rsm
What driver is trying to attach?
You can try adding a nmi=ignore to the xen.gz line.
This doesn't have any effect
You could also try adding a noapic to see if that help
narrow down the problem.
This one cause panic
http://pastebin.com/f53a20e6d
Let me know if you need more info.
Assuming it hangs at the above, adding nosmp should allow
the machine to boot.. Assuming it does, we'll have to start
looking at why...
if it stuck at a driver trying to attach, you can add
a disable-<drivername> to the -B line to skip over that
driver to see if the system will boot without that driver
(like you did with qlc).
MRJ
Regards,
Fajar
_______________________________________________
xen-discuss mailing list
[email protected]
