Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Jun 2001 08:55:21 -0700 (PDT)
From:      Matthew Jacob <mjacob@feral.com>
To:        John Baldwin <jhb@FreeBSD.ORG>, Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        <alpha@FreeBSD.ORG>
Subject:   more panics, with some traceback info....
Message-ID:  <20010621081950.Q18589-100000@wonky.feral.com>

next in thread | raw e-mail | index | archive | help


panic: blockable sleep lock (sleep mutex) Giant @ ../../vm/vm_fault.c:213
cpuid = 0; panic
db> t
Debugger() at Debugger+0x34
panic() at panic+0x178
witness_lock() at witness_lock+0x240
vm_fault() at vm_fault+0x108
trap() at trap+0xf78
XentMM() at XentMM+0x2c
--- memory management fault (from ipl 7) ---
hardclock() at hardclock+0x308
handleclock() at handleclock+0x22c
alpha_clock_interrupt() at alpha_clock_interrupt+0x68
interrupt() at interrupt+0xb8
XentInt() at XentInt+0x28
--- interrupt (from ipl 0) ---
witness_unlock() at witness_unlock+0x50
zalloc() at zalloc+0x28c
get_pv_entry() at get_pv_entry+0x70
pmap_insert_entry() at pmap_insert_entry+0x34
pmap_enter_quick() at pmap_enter_quick+0x214
pmap_object_init_pt() at pmap_object_init_pt+0x1b8
vm_map_insert() at vm_map_insert+0x37c
elf_load_section() at elf_load_section+0x33c
exec_elf_imgact() at exec_elf_imgact+0x528
execve() at execve+0x274
syscall() at syscall+0x708
XentSys() at XentSys+0x64
--- syscall (59, FreeBSD ELF, execve) ---
--- user mode ---

db> show locks
exclusive (sleep mutex) zone (0xfffffc000083d5c0) locked @
../../vm/vm_zone.c:373
exclusive (sleep mutex) vm (0xfffffc000084b180) locked @
../../kern/imgact_elf.c:236
exclusive (sleep mutex) Giant (0xfffffc000084be18) locked @
../../vm/vm_fault.c:213
exclusive (spin mutex) callout (0xfffffc0000845238) locked @
../../kern/kern_clock.c:213


A minor amount of sleuthing yields:

	if (TAILQ_FIRST(&callwheel[ticks & callwheelmask]) != NULL) {

as nearest the likely faulting line. A little sleuthing around about the value
of ticks && callwheelmask led me to believe that I should check the contents
of callwheel... so, callwheelmask was 4095, and masking that with ticks, I
went to check into that offset via DDB, and the system froze- I probably got
the offset wrong.

The assembler lines are:
hardclock+0x2e0:        addq    t0,#0x1,t0
hardclock+0x2e4:        stl     t0,0(t1)

		ticks++;	/* leaving ticks in t0 */

hardclock+0x2e8:        ldq     t1,0xffffffffffffbe68(gp)
hardclock+0x2ec:        ldl     t1,0(t1)
hardclock+0x2f0:        and     t0,t1,t0

		Fetch callwheelmask, mask against ticks

hardclock+0x2f4:        addl    t0,zero,t0
hardclock+0x2f8:        ldq     t1,0xffffffffffff89e8(gp)
hardclock+0x2fc:        ldq     t1,0(t1)

		Fetch callwheel (?)

hardclock+0x300:        sll     t0,#0x4,t0

		Turn masked ticks into an index

hardclock+0x304:        addq    t0,t1,t0

		Form address to fetch

hardclock+0x308:        ldq     t0,0(t0)


		Fetch callwheel[ticks & callwheelmask]


-matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010621081950.Q18589-100000>