Re: panic booting off of a USB key

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Mon, 19 Apr 2004 13:52:46 -0400
On Saturday 17 April 2004 11:30 am, Craig Rodrigues wrote:
> Hi,
>
> I compiled a -current kernel from a few days ago.
> I put the kernel on a USB key.
>
> When I boot the kernel from the USB key, it starts
> up, but then panics sometime after the umass0
> reports that it is attaching to the disk:
>
>
>
>
> =========================================================================
> umass0: at uhub0 port 1 (addr 2) disconnected
> umass0: detached
> [0] f:80 typ:7 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:117194112
> [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0
> [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0
> [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0
> GEOM: Configure ad0s1, start 32256 length 60003385344 end 60003417599
> umass0: USB Solid state disk, rev 1.10/1.00, addr 2
> umass0:1:0:-1: Attached to scbus1
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address	= 0x0
> fault code		= supervisor read, page not present
> instruction pointer	= 0x8:0xc0639e74
> stack pointer	        = 0x10:0xdf4baaec
> frame pointer	        = 0x10:0xdf4baaf8
> 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		= 28 (swi8: tty:sio clock)
> kernel: type 12 trap, code=0
> Stopped at      _mtx_lock_flags+0x34:   cmpl    $0xc08a47bc,0(%ebx)
> db> t
> _mtx_lock_flags(0,0,c083d456,125,c08e5420,0,c083d456,124) at
> _mtx_lock_flags+0x34 vm_fault(c103b000,deadc000,1,0,c2279150) at
> vm_fault+0x20a
> trap_pfault(df4bac64,0,deadc0fe) at trap_pfault+0x104
> trap(c08e0018,10,c0450010,c0452a18,0) at trap+0x2d9
> calltrap() at calltrap+0x5
> --- trap 0xc, eip = 0xc0451a02, esp = 0xdf4baca4, ebp = 0xdf4baca8 ---
> xpt_schedule_dev(deadc0f2,c64a5c18,1) at xpt_schedule_dev+0x36

Something accessed a free'd region of memory (see the references to 0xdeadc0de 
or small offsets thereof).  This function might be the place to start looking 
to see which pointer is stale.

> xpt_release_devq_device(c64a5c00,1,1,df4bad04,c064ea3e) at
> xpt_release_devq_device+0x99 xpt_release_devq_timeout(c64a5c00) at
> xpt_release_devq_timeout+0xf softclock(0) at softclock+0x176
> ithread_loop(c615f300,df4bad48,c615f300,c0631c94,0) at ithread_loop+0x11c
> fork_exit(c0631c94,c615f300,df4bad48) at fork_exit+0xa8
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xdf4bad7c, ebp = 0 ---
> db>

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
Received on Mon Apr 19 2004 - 09:15:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:51 UTC