Peter Jeremy <peterjeremy@optushome.com.au> wrote:
> I was trying to play a VCD (using mplayer) on my 6-STABLE system and
> it runs for a while and then crashes. This is reproducable with the
> same traceback.
>
> kgdb reports:
> acd0: FAILURE - device detached
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x3c8
> fault code = supervisor read data, page not present
> instruction pointer = 0x8:0xffffffff801b6489
> stack pointer = 0x10:0xffffffffa3561ba0
> frame pointer = 0x10:0xffffffffa3561bc0
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 2 (g_event)
> trap number = 12
> panic: page fault
> KDB: stack backtrace:
> panic() at panic+0x1c1
> trap_fatal() at trap_fatal+0x298
> trap_pfault() at trap_pfault+0x243
> trap() at trap+0x298
> calltrap() at calltrap+0x5
> --- trap 0xc, rip = 0xffffffff801b6489, rsp = 0xffffffffa3561ba0, rbp =
0xffffffffa3561bc0 ---
> acd_geom_detach() at acd_geom_detach+0x19
> g_run_events() at g_run_events+0x1b7
> g_event_procbody() at g_event_procbody+0x5a
> fork_exit() at fork_exit+0x87
> fork_trampoline() at fork_trampoline+0xe
>
> A gdb backtrace shows:
> #6 0xffffffff803787bb in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
> #7 0xffffffff801b6489 in acd_geom_detach (arg=0xffffff00007e1100,
flag=0x0) at /usr/src/sys/dev/ata/atapi-cd.c:194
> #8 0xffffffff8022f267 in g_run_events () at
/usr/src/sys/geom/geom_event.c:209
> #9 0xffffffff802305ca in g_event_procbody () at
/usr/src/sys/geom/geom_kern.c:141
> #10 0xffffffff80254f77 in fork_exit (callout=0xffffffff80230570
<g_event_procbody>, arg=0x0, frame=0xffffff0039dc4770)
> at /usr/src/sys/kern/kern_fork.c:821
> #11 0xffffffff80378b1e in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:394
>
> The argument to acd_geom_detach() does include a NULL ivars:
> (kgdb) p *(device_t)0xffffff00007e1100
> $2 = {
> ops = 0xffffff0000825000,
> link = {
> tqe_next = 0xffffff00007c1c00,
> tqe_prev = 0xffffff00008ea130
> },
> devlink = {
> tqe_next = 0xffffff00007c1c00,
> tqe_prev = 0xffffff00009f1518
> },
> parent = 0xffffff00008ea100,
> children = {
> tqh_first = 0x0,
> tqh_last = 0xffffff00007e1130
> },
> driver = 0xffffffff80532220,
> devclass = 0xffffff00007ebe00,
> unit = 0x0,
> nameunit = 0xffffff00009d19d0 "acd0",
> desc = 0xffffff0039bd72a0 "TSSTcorpCD/DVDW TS-L532M/HR08",
> busy = 0x0,
> state = DS_ATTACHED,
> devflags = 0x0,
> flags = 0x5d,
> order = 0x0,
> pad = 0x0,
> ivars = 0x0,
> softc = 0xffffff0000acac00,
> sysctl_ctx = {
> tqh_first = 0xffffff0039bd7120,
> tqh_last = 0xffffff0039bd7228
> },
> sysctl_tree = 0xffffff0000b30600
> }
> (kgdb)
>
> Is this behaviour expected?
I think you're running into the same problem I reported in
"kern/99017: [ata] [patch] FreeBSD versions above 5.3
panic if atapi drives become unresponsive":
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/99017
You could try the work-around, but your drive will
probably still be lost until the next reboot.
Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070911/fbda1f4b/signature.pgp