The line where I was having the trap is still within cpu_switch (line
236 of swtch.s).
I added WITNESS and INVARIANTS to my kernel and I get a new panic.
This time I see:
kernel trap 12 with interrupts disabled
panic: mutex sched lock recursed at ../../kern/kern_synch.c:918
panic()
_mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63
mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25
sched_ithd(e) at sched_ithd+0xd9
Xresume14() at Xresume14+0x8
--- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 ---
__set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0)
at __set_sysinit_set_sym_sc_mem_sys_init+0x644
Jim Bloom
[EMAIL PROTECTED]
PS: Here is the original message. It was cut and pasted from the logs
since your message is sitting in another OS on a dual boot machine.
On 06-Feb-01 Jim Bloom wrote:
> I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is
> occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create
> a
> core dump. Here is a hand transcription of what I see.
>
> Mounting root from ufs:/dev/ad0s1a
> pccard: card inserted, slot 0
> pccard: card inserted, slot 1
> kernel trap 9 with interrupts disabled
>
> Fatal trap 9: general protection fault while in kernel mode
> instruction pointer = 0x8:0xc0270ad8
> stack pointer = 0x10:0xc2fb4f50
> frame pointer = 0x10:0xc2fb4f64
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = resume, IOPL = 0
> current process = 16 (irq14:ata0)
> kernel: type 9 trap, code=0
> Stopped at sw1b+0x77: ltr %si
>
> backtrace
> sw1b(4000) at sw1b+0x77 (note this is actually swtch())
Actually, this is beyond the end of cpu_switch I think. You are
effectively
off in lala land.
> ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7
This is either in the mtx_enter of Giant or in the interrupt handler
itself.
I'm betting an interrupt handler isn't being setup properly one way or
another,
and that the code is jumping through a bogus pointer and ending up in
lala land
executing random code.
> fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d
> fork_trampoline() at fork_trampoline+0x8
>
> I don't have WITNESS or INVARIANTS at this time and don;t have a serial
> console
> so I can't capture the output.
These help to capture bugs by doing extra checks though, and especially
with
current they are highly, highly, highly recommended right now.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
