Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Apr 2004 22:33:42 +0200
From:      Bernd Walter <ticso@cicely12.cicely.de>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: panic booting off of a USB key
Message-ID:  <20040419203341.GV5279@cicely12.cicely.de>
In-Reply-To: <200404191352.46793.jhb@FreeBSD.org>
References:  <20040417153007.GA1885@crodrigues.org> <200404191352.46793.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 19, 2004 at 01:52:46PM -0400, John Baldwin wrote:
> 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.

It's the detaching of an scbus before cam has probed it what triggers
this panic.
I guess the detaching is triggered by ehci reprobe, but a detach can
happen anytime with USB.
Maybe some cam enlighted could tell something more about what we could
do with this case.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd@bwct.de                                  info@bwct.de



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