Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Nov 2006 12:10:44 -0800 (PST)
From:      Charlie & <root@feral.com>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   kern/106030: panic while rebooting with a dead disk
Message-ID:  <200611292010.kATKAipM001120@colfax.in1.lcl>
Resent-Message-ID: <200611292020.kATKKCPg066696@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         106030
>Category:       kern
>Synopsis:       panic while rebooting with a dead disk
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Nov 29 20:20:12 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Matthew Jacob
>Release:        FreeBSD 7.0-CURRENT i386
>Organization:
Feral Software
>Environment:
System: FreeBSD colfax.in1.lcl 7.0-CURRENT FreeBSD 7.0-CURRENT #33: Tue Nov 28 22:28:44 PST 2006 mjacob@colfax.in1.lcl:/home/FreeBSD/p4/newisp/i386/compile/GENERIC i386


>Description:

I had a mounted ufs disk that went away. I rebooted so as to avoid a panic. Too bad. Geom paniced
on me anyway:

Syncing disks, vnodes remaining...2 (da8:isp1:0:6:2): Invalidating pack
g_vfs_done():da8a[WRITE(offset=81920, length=4096)]error = 6
panic: bundirty: buffer 0xc6d76f70 still on queue 1
cpuid = 0
KDB: enter: panic
[thread pid 3 tid 100000 ]
Stopped at      kdb_enter+0x2b: nop
db> bt
Tracing pid 3 tid 100000 td 0xc1e98000
kdb_enter(c0936604) at kdb_enter+0x2b
panic(c093f33c,c6d76f70,1,c6d76f70,cba0ec48,...) at panic+0x127
bundirty(c6d76f70) at bundirty+0x35
brelse(c6d76f70) at brelse+0x82f
bufdone_finish(c6d76f70) at bufdone_finish+0x34c
bufdone(c6d76f70) at bufdone+0xaa
ffs_backgroundwritedone(c6d76f70) at ffs_backgroundwritedone+0xca
bufdone(c6d76f70) at bufdone+0x8f
g_vfs_done(c21475ac) at g_vfs_done+0x8a
biodone(c21475ac) at biodone+0x58
g_io_schedule_up(c1e98000) at g_io_schedule_up+0xe6
g_up_procbody(0,cba0ed38) at g_up_procbody+0x5a
fork_exit(c067d58c,0,cba0ed38) at fork_exit+0xac
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xcba0ed6c, ebp = 0 ---


It's unclear to me where this should be fixed. Since device invalidation is an inherently asynchronous process that
could happen at any time, it seems to me that GEOM should be a bit more tolerant here.

>How-To-Repeat:

Turn a disk off that has a mounted filesystem and just do a reboot.

>Fix:



>Release-Note:
>Audit-Trail:
>Unformatted:



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