Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 May 2003 06:03:31 +1000
From:      Peter Jeremy <peterjeremy@optushome.com.au>
To:        Jonas Bulow <jonas@bulow.mine.nu>
Cc:        freebsd-stable <freebsd-stable@freebsd.org>
Subject:   Re: Kernel panic on FreeBSD 4.8-STABLE
Message-ID:  <20030514200331.GD4366@cirb503493.alcatel.com.au>
In-Reply-To: <3EC22DB4.70409@bulow.mine.nu>
References:  <3EC10790.50809@bulow.mine.nu> <20030514100716.GA4410@cirb503493.alcatel.com.au> <3EC22DB4.70409@bulow.mine.nu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 14, 2003 at 01:51:16PM +0200, Jonas Bulow wrote:
>Peter Jeremy wrote:
>>On Tue, May 13, 2003 at 04:56:16PM +0200, Jonas Bulow wrote:
>>
>>>I need some help to understand a backtrace.
>>
>>
>>>Fatal trap 9: general protection fault while in kernel mode
>>>instruction pointer     = 0x8:0xc023ceeb
>>>stack pointer           = 0x10:0xcf7d9ea4
>>>frame pointer           = 0x10:0xcf7d9ec0
>>>code segment            = base 0x0, limit 0xfffff, type 0x1b
>>>                      = DPL 0, pres 1, def32 1, gran 1
>>>processor eflags        = resume, IOPL = 0
>>>current process         = Idle
>>>interrupt mask          = net tty bio cam
>>>trap number             = 9
>>>panic: general protection fault
>>
>>...
>>
>>>#17 0xc023d6fb in trap (frame={tf_fs = 16, tf_es = 134938640, tf_ds = 
>>>-982253552, tf_edi = -971835344, tf_esi = 32,
>>>    tf_ebp = -813850944, tf_isp = -813850992, tf_ebx = -1070885216, 
>>>tf_edx = -812732416, tf_ecx = -831483840,
>>>    tf_eax = 336283586, tf_trapno = 9, tf_err = 32, tf_eip = 
>>>-1071395093, tf_cs = 8, tf_eflags = 65670, tf_esp = -1072211888,
>>>    tf_ss = -831471360}) at /usr/src/sys/i386/i386/trap.c:636
>>>#18 0xc023ceeb in sw1a ()
>>>#19 0xc0174ff1 in tsleep (ident=0xce70c100, priority=288, 
>>>wmesg=0xc02530a5 "wait", timo=0) at /usr/src/sys/kern/kern_synch.c:479
>>
>>
>>#18 is the underlying problem.  sw1a() is in /sys/i386/i386/swtch.s
>>and you might like to disassemble the code around 0xc023ceeb to see
>>exactly where it is dying.  GPF is a catch-all category so it's
>>difficult to know exactly why you're getting it without knowing the
>>actual instruction it dies on.
>
>This is beyond my skills. :-) Does the disassemble say anything usefull?
>
>(kgdb) disassemble 0xc023ceeb
...
>0xc023cecf <sw1a+93>:   mov    $0xc0298550,%edi
>0xc023ced4 <sw1a+98>:   mov    0xc0298558,%ebx
>0xc023ceda <sw1a+104>:  mov    0x0(%edi),%eax
>0xc023cedd <sw1a+107>:  mov    %eax,0x0(%ebx)
>0xc023cee0 <sw1a+110>:  mov    0x4(%edi),%eax
>0xc023cee3 <sw1a+113>:  mov    %eax,0x4(%ebx)
>0xc023cee6 <sw1a+116>:  mov    $0x20,%esi
>0xc023ceeb <sw1a+121>:  ltr    %si

It's dying trying to switch tasks.  %edi isn't _common_tssd so it's a
private TSS.  This is a bit beyond my skills to debug remotely - I
don't suppose you have a iA32 system programming manual handy?  You
could try printing the 8 bytes following %edi in frame #18
(0xc612f830) and the TSS they point to (if you can - I can't
quickly/easily describe how to convert the TSS descriptor to the TSS
address).

Whilst you're at it, can you print all the registers at frame #18.

Peter



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