Date: Thu, 22 May 2003 12:33:13 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Jun Kuriyama <kuriyama@imgsrc.co.jp> Cc: Current <freebsd-current@FreeBSD.org> Subject: RE: Panic in _mtx_lock_flags+0x40 Message-ID: <XFMail.20030522123313.jhb@FreeBSD.org> In-Reply-To: <7mllwzlu0u.wl@black.imgsrc.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-May-2003 Jun Kuriyama wrote:
>
> This kernel is yesterday's. I'll update the kernel and try again...
>
>
> ad0: READ command timeout tag=0 serv=0 - resetting
> ata0: resetting devices ..
> done
> ad0: READ command timeout tag=0 serv=0 - resetting
> ata0: resetting devices ..
> done
> ad0: READ command timeout tag=0 serv=0 - resetting
> ata0: resetting devices ..
> done
> ad0: READ command timeout tag=0 serv=0 - resetting
> ata0: resetting devices ..
> ad0: removed from configuration
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; lapic.id = 00000000
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc02259c0
> stack pointer = 0x10:0xe11eda54
> frame pointer = 0x10:0xe11eda70
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 13 (swi7: tty:sio clock)
> kernel: type 12 trap, code=0
> Stopped at _mtx_lock_flags+0x40: cmpl $0xc043c18c,0(%ecx)
> db> trace
> _mtx_lock_flags(0,0,c0401b81,11d,e11edb18) at _mtx_lock_flags+0x40
Trying to lock a NULL pointer is definitely going to panic, yes.
I'm curious what vm_fault() line you are at.
> vm_fault(c082f000,deadc000,1,0,c3affab0) at vm_fault+0x2cc
> trap_pfault(e11edc10,0,deadc0de,cf74d400,deadc0de) at trap_pfault+0x161
> trap(c0410018,10,c03e0010,c7a73c9c,c7e8f600) at trap+0x3ad
> calltrap() at calltrap+0x5
> --- trap 0xc, eip = 0xc015c580, esp = 0xe11edc50, ebp = 0xe11edc68 ---
> ad_detach(c7a73c9c,ffffffff,c03d5de3,0,1) at ad_detach+0x40
The real bug is probably here, probably a NULL pointer dereference.
I would use gdb to figure out what this file:line is and send the
report to Søren.
> ata_reinit(c7a73c00,cacf5100,c03d1747,0,0) at ata_reinit+0x9b
> ad_timeout(cacf5100,0,c03ec2fe,bf,4feaef) at ad_timeout+0x136
> softclock(0,0,c03e9271,233,c3afe780) at softclock+0x19c
> ithread_loop(c3afd200,e11edd48,c03e9122,2f8,0) at ithread_loop+0x182
> fork_exit(c021bab0,c3afd200,e11edd48) at fork_exit+0xc0
> fork_trampoline() at fork_trampoline+0x1a
> --- trap 0x1, eip = 0, esp = 0xe11edd7c, ebp = 0 ---
> db> panic
> panic: from debugger
> cpuid = 0; lapic.id = 00000000
> Debugger("panic")
>
>
> Fatal trap 3: breakpoint instruction fault while in kernel mode
> cpuid = 0; lapic.id = 00000000
> instruction pointer = 0x8:0xc038ef75
> stack pointer = 0x10:0xe11ed7c4
> frame pointer = 0x10:0xe11ed7d0
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = IOPL = 0
> current process = 13 (swi7: tty:sio clock)
> Stopped at _mtx_lock_flags+0x40: cmpl $0xc043c18c,0(%ecx)
> db> panic
> panic: from debugger
> cpuid = 0; lapic.id = 00000000
> boot() called on cpu#0
> Uptime: 14h33m40s
> Dumping 2047 MB
> ata2: resetting devices ..
> done
> ad4: timeout waiting for DRQata2: resetting devices ..
>
>
> --
> Jun Kuriyama <kuriyama@imgsrc.co.jp> // IMG SRC, Inc.
> <kuriyama@FreeBSD.org> // FreeBSD Project
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030522123313.jhb>