Re: panic at sched_add_internal

On Fri, 16 Jul 2004 07:23:27 +0900 (JST)
Norikatsu Shigemura <nork_at_freebsd.org> wrote:
> [thread 100334]
> Stopped at      sched_add_internal+0x36:        movzbl  0x68(%edx),%esi
> db> trace
> sched_add_internal(c4c50dc0,1,e3eefb4c,c05b68c5,c4c50dc0) at sched_add_internal+0x36
> sched_add(c4c50dc0,e3eefb70,c05c3488,c27c79c0,c27c79c0) at sched_add+0x19
> kse_reassign(c27c79c0,c27c79c0,1a573,c080e640,ecaed0fb) at kse_reassign+0x45
> sched_switch(c2b90580,0,c08850f0,c088bbc0,2534a5e5) at sched_switch+0xd8
> mi_switch(1,0,c07bf36b,20b,c08838f8) at mi_switch+0x1c2
> turnstile_wait(c406d2c0,c0877f40,c2da7dc0,c0877f40,4e) at turnstile_wait+0x23d
> _mtx_lock_sleep(c0877f40,0,c07bfe2e,4e,c33a062c) at _mtx_lock_sleep+0x125
> _mtx_lock_flags(c0877f40,0,c07bfe2e,4e,c26e4c04) at _mtx_lock_flags+0x64
> soo_read(c2d9bd48,e3eefc80,c47d2900,0,c2b90580) at soo_read+0x3c
> dofileread(c2b90580,c2d9bd48,3,bfbfaa60,20) at dofileread+0xac
> read(c2b90580,e3eefd14,c,c2b90580,3) at read+0x6b
> syscall(bfab002f,2f,6885002f,8149000,ffffffff) at syscall+0x2a0
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (3, FreeBSD ELF32, read), eip = 0x684c361f, esp = 0xbfbfa96c, ebp = 0xbfbfa988 ---

	Wow.  Until I read a kris's mail, I didn't know about
	addr2line(1).  According to addr2line(1),

	$ nm /boot/kernel/kernel.debug | grep sched_add_internal      
	c05c3d70 t sched_add_internal
	$ addr2line -e /boot/kernel/kernel.debug 0xc05c3da6
	/usr/src/sys/kern/sched_ule.c:1574

# 0xc05c3da6 = sched_add_internal(0xc05c3d70) + 0x36

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
static void
sched_add_internal(struct thread *td, int preemptive)
{
[...]
	KASSERT(ke->ke_runq == NULL,
		("sched_add: KSE %p is still assigned to a run queue", ke));

-->	class = PRI_BASE(kg->kg_pri_class);
	switch (class) {
	case PRI_ITHD:
[...]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -