Re: kern/49079: panic: bwrite: buffer is not busy
Based on this output from your gdb session it looks like the code in boot() did run and potentially alter this buffer. panic: bwrite: buffer is not busy??? panic messages: --- panic: bwrite: buffer is not busy??? cpuid = 1; lapic.id = Stack backtrace: boot() called on cpu#1 Can you disable sync on panic? The buf must have been modified. That section of code is never entered with b_xflags == 0. The contents of the buf just dont make sense with the panic.. Cheers, Jeff On Sun, 16 Mar 2003, Morten Rodal wrote: > On Sun, Mar 16, 2003 at 02:46:13AM -0500, Jeff Roberson wrote: > > On Sat, 15 Mar 2003, Morten Rodal wrote: > > > > > On Fri, Mar 14, 2003 at 06:47:27PM +0100, Morten Rodal wrote: > > > [snip the parent post] > > > > > > I just got another one of these. This time it didn't double panic > > > while syncing the disks. I've been getting this quite often now, > > > almost daily. If there is anything else I can help you with to get to > > > the bottom of this problem don't hesitate to ask. > > > > > > Attached is a the gdb output and the backtrace from DDB. > > > > Excelent, can you open up the kernel in gdb again. Then do the following: > > > > frame 3 > > print bp > > > > With this information I should be able to find the problem. > > > > -- > Morten Rodal > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern/49079: panic: bwrite: buffer is not busy
On Sun, Mar 16, 2003 at 02:46:13AM -0500, Jeff Roberson wrote:
> On Sat, 15 Mar 2003, Morten Rodal wrote:
>
> > On Fri, Mar 14, 2003 at 06:47:27PM +0100, Morten Rodal wrote:
> > [snip the parent post]
> >
> > I just got another one of these. This time it didn't double panic
> > while syncing the disks. I've been getting this quite often now,
> > almost daily. If there is anything else I can help you with to get to
> > the bottom of this problem don't hesitate to ask.
> >
> > Attached is a the gdb output and the backtrace from DDB.
>
> Excelent, can you open up the kernel in gdb again. Then do the following:
>
> frame 3
> print bp
>
> With this information I should be able to find the problem.
>
--
Morten Rodal
Script started on Sun Mar 16 08:57:26 2003
slurp# gdb -k kernel.3 vmcore.3
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... 3452 3452 3451 3451 3449 3448 3448 3448 3448 3448
3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448
giving up on 110 buffers
Uptime: 48m16s
Dumping 447 MB
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16[CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48 64
80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416
432
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) frame 3
#3 0xc02194e2 in bwrite (bp=0xcc9a5fe8) at /usr/src/sys/kern/vfs_bio.c:802
802 panic("bwrite: need chained iodone");
(kgdb) print bp
$1 = (struct buf *) 0xcc9a5fe8
(kgdb) print *bp
$2 = {b_io = {bio_cmd = 2, bio_dev = 0x, bio_disk = 0x0,
bio_blkno = 4188480, bio_offset = 2145681408, bio_bcount = 16384,
bio_data = 0xd219e000 "", bio_flags = 0, bio_error = 0, bio_resid = 0,
bio_done = 0xc021d1f0 , bio_driver1 = 0x0, bio_driver2 = 0x0,
bio_caller1 = 0xc39c9400, bio_caller2 = 0xcc9a5fe8, bio_queue = {
tqe_next = 0x0, tqe_prev = 0xc39c940c}, bio_attribute = 0x0,
bio_from = 0x0, bio_to = 0x0, bio_length = 0, bio_completed = 0,
bio_children = 1398, bio_inbed = 0, bio_parent = 0x0, bio_t0 = {sec = 0,
frac = 0}, bio_task = 0, bio_task_arg = 0x0, bio_pblkno = 518876},
b_op = 0xc036e018, b_magic = 280038160,
b_iodone = 0xc0221300 , b_offset = 262144, b_vnbufs = {
tqe_next = 0x0, tqe_prev = 0x0}, b_left = 0x0, b_right = 0x0,
b_vflags = 0, b_freelist = {tqe_next = 0xcc9a5908, tqe_prev = 0xc03a145c},
b_qindex = 0, b_flags = 1677721604, b_xflags = 0 '\0', b_lock = {
lk_interlock = 0xc039b7a4, lk_flags = 0, lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80,
lk_wmesg = 0xc034482b "bufwait", lk_timo = 0, lk_lockholder = 0x,
lk_newlock = 0x0}, b_bufsize = 16384, b_runningbufspace = 0,
b_kvabase = 0xd219e000 "", b_kvasize = 16384, b_lblkno = 16,
b_vp = 0xc41b1a44, b_object = 0x0, b_dirtyoff = 0, b_dirtyend = 16384,
b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xd219e000, b_pager = {
pg_spc = 0x0, pg_reqpage = 0}, b_cluster = {cluster_head = {
tqh_first = 0xccab02f8, tqh_last = 0xccab0420}, cluster_entry = {
tqe_next = 0xccab02f8, tqe_prev = 0xccab0420}}, b_pages = {0xc0f97d08,
0xc0f80c50, 0xc0f92398, 0xc0e9cfe0, 0xc0eefc48, 0xc0efd490, 0xc0a8a3d8,
0xc0f04120, 0xc0a85c68, 0xc0a853b0, 0xc0a3c1f8, 0xc0f1a140, 0xc0de4288,
0xc0f468d0, 0xc0ac3c18, 0xc0a61e60, 0xc0a4fea8, 0xc0f175f0, 0xc0de5638,
0xc0dee680, 0xc0ddeac8, 0xc0f07210, 0xc0a9fe58, 0xc0f462a0, 0xc0dd40e8,
0xc0f3a630,
Re: kern/49079: panic: bwrite: buffer is not busy
On Sat, 15 Mar 2003, Morten Rodal wrote: > On Fri, Mar 14, 2003 at 06:47:27PM +0100, Morten Rodal wrote: > [snip the parent post] > > I just got another one of these. This time it didn't double panic > while syncing the disks. I've been getting this quite often now, > almost daily. If there is anything else I can help you with to get to > the bottom of this problem don't hesitate to ask. > > Attached is a the gdb output and the backtrace from DDB. Excelent, can you open up the kernel in gdb again. Then do the following: frame 3 print bp With this information I should be able to find the problem. Thanks! Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern/49079: panic: bwrite: buffer is not busy
On Fri, Mar 14, 2003 at 06:47:27PM +0100, Morten Rodal wrote:
[snip the parent post]
I just got another one of these. This time it didn't double panic
while syncing the disks. I've been getting this quite often now,
almost daily. If there is anything else I can help you with to get to
the bottom of this problem don't hesitate to ask.
Attached is a the gdb output and the backtrace from DDB.
--
Morten Rodal
panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
Stack backtrace:
backtrace(c0341972,0,c03448b1,d533f988,1) at backtrace+0x17
panic(c03448b1,d533f99c,c0304cd9,d533f99c,c01da2c4) at panic+0x10a
bwrite(cc9a5fe8,d533fa34,c02220e2,cc9a5fe8,cc9a6118) at bwrite+0x152
bawrite(cc9a5fe8,cc9a6118,4,d533fd48,2002) at bawrite+0x1c
cluster_wbuild(c41b1a44,4000,e,0,6) at cluster_wbuild+0x732
cluster_write(cc9afa98,58000,0,2,c3fdc300) at cluster_write+0x571
ffs_write(d533fbc4,20002,c38d5c30,0,d533fc70) at ffs_write+0x5cf
vn_write(c3ec26cc,d533fc70,c3fdc300,0,c38d5c30) at vn_write+0x20d
dofilewrite(c38d5c30,c3ec26cc,1d,859e800,200) at dofilewrite+0xe8
write(c38d5c30,d533fd10,c,d533fd20,3) at write+0x69
syscall(8e4002f,2f,bfbf002f,0,2808f100) at syscall+0x2ac
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4), eip = 0x285ba6d3, esp = 0xbfbff21c, ebp = 0xbfbff258 ---
Script started on Sat Mar 15 23:02:18 2003
slurp# gdb -k kernel.3 vmcore.3
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... 3452 3452 3451 3451 3449 3448 3448 3448 3448 3448
3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448
giving up on 110 buffers
Uptime: 48m16s
Dumping 447 MB
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16[CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48 64
80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416
432
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01d457f in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01d4907 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc02194e2 in bwrite (bp=0xcc9a5fe8) at /usr/src/sys/kern/vfs_bio.c:802
#4 0xc0219e6c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1144
#5 0xc02220e2 in cluster_wbuild (vp=0xc41b1a44, size=16384, start_lbn=17,
len=6) at /usr/src/sys/kern/vfs_cluster.c:966
#6 0xc0221931 in cluster_write (bp=0xcc9afa98, filesize=360448, seqcount=2)
at /usr/src/sys/kern/vfs_cluster.c:566
#7 0xc02aa1ef in ffs_write (ap=0xd533fbc4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:726
#8 0xc023885d in vn_write (fp=0xc3ec26cc, uio=0xd533fc70,
active_cred=0xc3fdc300, flags=0, td=0xc38d5c30) at vnode_if.h:417
#9 0xc01f7fb8 in dofilewrite (td=0xc38d5c30, fp=0xc3ec26cc, fd=0,
buf=0x859e800, nbyte=0, offset=0, flags=0) at file.h:239
#10 0xc01f7df9 in write (td=0xc38d5c30, uap=0xd533fd10)
at /usr/src/sys/kern/sys_generic.c:329
#11 0xc030d09c in syscall (frame=
{tf_fs = 149159983, tf_es = 47, tf_ds = -1078001617, tf_edi = 0, tf_esi =
671674624, tf_ebp = -1077939624, tf_isp = -718013068, tf_ebx = 671686852, tf_edx = 29,
tf_ecx = 0, tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 677095123, tf_cs = 31,
tf_eflags = 518, tf_esp = -1077939684, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1030
#12 0xc02f52cd in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
(kgdb) slurp# ^Dexit
Script done on Sat Mar 15 23:02:30 2003
pgp0.pgp
Description: PGP signature
Re: kern/49079: panic: bwrite: buffer is not busy
On Thu, Mar 13, 2003 at 03:05:03AM -0500, Jeff Roberson wrote: > On Tue, 11 Mar 2003, Doug Barton wrote: > > It won't. I have 1.376 of vfs_bio.c, and -current as of the 7th, and I > > just got another one of these last night. The panic message is the same as > > I've been getting, but the bremfree message is slightly different, if that > > helps any. > I have 1.378 of vfs_bio.c and I just got one of these panics. Kernel built on 13th of March. (Thu Mar 13 16:25:15 CET 2003) > > Can anyone tell me when this started? Or perhaps backup your sources > until this goes away? I am not able to reproduce this. Can you give me > the following information. > I am not sure, but my computer fist panic with this on March 6th. > Type of machine, cpu, memory, etc. Dual Pentium II 300MHz 447MB SDRAM > Mounted filesystems and their block size. /dev/da0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/da0s1e on /tmp (ufs, local, soft-updates) /dev/da0s1f on /usr (ufs, local, soft-updates) /dev/ad0s1e on /usr/home (ufs, local, nosuid, soft-updates) /dev/ad0s1d on /usr/local (ufs, local, soft-updates) /dev/ad2s1e on /mnt/media (ufs, local, nosuid, soft-updates) /dev/da0s1d on /var (ufs, local, nosuid, soft-updates) I have attached the output of the disklabel command. Hopefully that will tell you the block size (I am unsure about where to find it). I am not sure if this is related but the disklabel command issued a warning on all three hardisks that partition c didn't cover the whole unit. > Type of workload. > I was web browsing and listening to music with xmms. Not very heavy load or much disk activity. -- Morten Rodal # /dev/ad0s1c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 33483 sectors/unit: 33750864 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 337508010unused0 0 # (Cyl.0 - 33482*) d: 1048576004.2BSD 2048 16384 28512 # (Cyl.0 - 10402*) e: 23265041 104857604.2BSD 2048 16384 28512 # (Cyl. 10402*- 33482*) # /dev/ad2s1c: type: ESDI disk: ad2s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 5605 sectors/unit: 90060327 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 900603270unused0 0 # (Cyl.0 - 5605*) e: 9006032704.2BSD 2048 1638489 # (Cyl.0 - 5605*) # /dev/da0s1c: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1044 sectors/unit: 16777215 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 209715204.2BSD 2048 16384 28512 # (Cyl.0 - 130*) b: 1793168 2097152 swap# (Cyl. 130*- 242*) c: 167717970unused0 0 # (Cyl.0 - 1043*) d: 524288 38903204.2BSD 2048 16384 32776 # (Cyl. 242*- 274*) e: 524288 44146084.2BSD 2048 16384 32776 # (Cyl. 274*- 307*) f: 11832901 49388964.2BSD 2048 16384 28512 # (Cyl. 307*- 1043*) pgp0.pgp Description: PGP signature
Re: kern/49079: panic: bwrite: buffer is not busy
On Tue, 11 Mar 2003, Doug Barton wrote: > FYI, -bugs is not a discussion list. > > On Tue, 11 Mar 2003, Attila Nagy wrote: > > > The following reply was made to PR kern/49079; it has been noted by GNATS. > > > > From: Attila Nagy <[EMAIL PROTECTED]> > > To: Martin Machacek <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > Subject: Re: kern/49079: panic: bwrite: buffer is not busy > > Date: Tue, 11 Mar 2003 10:30:17 +0100 (CET) > > > > Hello, > > > > > The system panics with "panic: bwrite: buffer is not busy" after random > > > time after boot if X server is running (although this is not verified to > > > >Fix: > > > Would love to have one :-). > > CURRENT already has a fix, in rev. 1.373 of vfs_bio.c > > > > Could you please try to update to -CURRENT to see if this problem > > disappears? > > It won't. I have 1.376 of vfs_bio.c, and -current as of the 7th, and I > just got another one of these last night. The panic message is the same as > I've been getting, but the bremfree message is slightly different, if that > helps any. Can anyone tell me when this started? Or perhaps backup your sources until this goes away? I am not able to reproduce this. Can you give me the following information. Type of machine, cpu, memory, etc. Mounted filesystems and their block size. Type of workload. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern/49079: panic: bwrite: buffer is not busy
FYI, -bugs is not a discussion list.
On Tue, 11 Mar 2003, Attila Nagy wrote:
> The following reply was made to PR kern/49079; it has been noted by GNATS.
>
> From: Attila Nagy <[EMAIL PROTECTED]>
> To: Martin Machacek <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: kern/49079: panic: bwrite: buffer is not busy
> Date: Tue, 11 Mar 2003 10:30:17 +0100 (CET)
>
> Hello,
>
> > The system panics with "panic: bwrite: buffer is not busy" after random
> > time after boot if X server is running (although this is not verified to
> > >Fix:
> > Would love to have one :-).
> CURRENT already has a fix, in rev. 1.373 of vfs_bio.c
>
> Could you please try to update to -CURRENT to see if this problem
> disappears?
It won't. I have 1.376 of vfs_bio.c, and -current as of the 7th, and I
just got another one of these last night. The panic message is the same as
I've been getting, but the bremfree message is slightly different, if that
helps any.
Doug
panic: bwrite: buffer is not busy???
syncing disks, buffers remaining... panic: bremfree: removing a buffer not
on a queue
Uptime: 3d8h21m50s
(kgdb) bt
#0 doadump () at /usr/Local/src-current/sys/kern/kern_shutdown.c:240
#1 0xc021673e in boot (howto=260) at
/usr/Local/src-current/sys/kern/kern_shutdown.c:371
#2 0xc0216cb0 in panic (fmt=0x0) at
/usr/Local/src-current/sys/kern/kern_shutdown.c:542
#3 0xc02562a0 in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0)
at /usr/Local/src-current/sys/kern/vfs_bio.c:630
#4 0xc02561c5 in bremfree (bp=0x0) at
/usr/Local/src-current/sys/kern/vfs_bio.c:612
#5 0xc02582ed in vfs_bio_awrite (bp=0x0)
at /usr/Local/src-current/sys/kern/vfs_bio.c:1682
#6 0xc02b9974 in ffs_fsync (ap=0xcdd2b8e4)
at /usr/Local/src-current/sys/ufs/ffs/ffs_vnops.c:257
#7 0xc02b8c20 in ffs_sync (mp=0xc26c1e00, waitfor=2, cred=0xc0eb6e80,
td=0xc0388bc0)
at vnode_if.h:612
#8 0xc026b00d in sync (td=0xc0388bc0, uap=0x0)
at /usr/Local/src-current/sys/kern/vfs_syscalls.c:138
#9 0xc021676a in boot (howto=256) at
/usr/Local/src-current/sys/kern/kern_shutdown.c:280
#10 0xc0216cb0 in panic (fmt=---Can't read userspace from dump, or kernel
process---
) at /usr/Local/src-current/sys/kern/kern_shutdown.c:542
#11 0xc0256a22 in bwrite (bp=0xc77310f8) at
/usr/Local/src-current/sys/kern/vfs_bio.c:795
#12 0xc025715c in bawrite (bp=0x0) at
/usr/Local/src-current/sys/kern/vfs_bio.c:1138
#13 0xc025e817 in cluster_wbuild (vp=0xc339a124, size=8192, start_lbn=16,
len=2)
at /usr/Local/src-current/sys/kern/vfs_cluster.c:996
#14 0xc025e156 in cluster_write (bp=0xc7733f60, filesize=155648,
seqcount=13)
at /usr/Local/src-current/sys/kern/vfs_cluster.c:596
#15 0xc02ba6d3 in ffs_write (ap=0xcdd2bbdc)
at /usr/Local/src-current/sys/ufs/ffs/ffs_vnops.c:728
#16 0xc0272d42 in vn_write (fp=0xc2964258, uio=0xcdd2bc78,
active_cred=0xc2d5f500,
flags=0, td=0xc2641b40) at vnode_if.h:417
#17 0xc0238359 in dofilewrite (td=0xc2641b40, fp=0xc2964258, fd=0,
buf=0x0, nbyte=512,
offset=0, flags=0) at file.h:239
#18 0xc02381bd in write (td=0xc2641b40, uap=0x200)
at /usr/Local/src-current/sys/kern/sys_generic.c:329
#19 0xc030fca3 in syscall (frame=
{tf_fs = 136577071, tf_es = 137691183, tf_ds = -1078001617, tf_edi =
151975312, tf_esi = 512, tf_ebp = -1077939400, tf_isp = -841826956, tf_ebx
= 26, tf_edx = 512, tf_ecx = 151975312, tf_eax = 4, tf_trapno = 22, tf_err
= 2, tf_eip = 677562292, tf_cs = 31, tf_eflags = 642, tf_esp =
-1077939448, tf_ss = 47})
at /usr/Local/src-current/sys/i386/i386/trap.c:1030
#20 0xc02ffe7d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
--
This .signature sanitized for your protection
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 5.0R panic: bwrite: buffer is not busy???
Hello, > Here the messages that appears in console: The panic appears randomly > after the boot , it can be an hour as can be 3 or more hours . Could you please try to upgrade to -CURRENT? --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD 5.0R panic: bwrite: buffer is not busy???
Hi, I get this error afrer few time of working always during this the listening of the music contained in my EXT3 partition here the operation that I do: >> Starting Xserver >> Kldloading snd_cmi >> mounting my EXT3 partition in read-only mode >> starting listening music with XMMS I don't have the dump, because the DEBUGGING options are disabled, it happened to me 3 time , with 5.0-RELEASE and -CURRENT kernel , now I've turned on the debug in the kernel , and I'll wait that the system freeze up again in order to give some more infos. What happen is this: The system freeze up, then after few sec the system reboots. Here the messages that appears in console: syslogd: kernel boot file is /boot/kernel/kernel kernel: TPTE at 0xbfc21bb0 IS ZERO @VA 086ec000 kernel: panic: bad pte kernel: kernel: syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? kernel: Uptime: 1h26m42s kernel: Terminate ACPI kernel: Automatic reboot in 15 seconds - press a key on the console to abort kernel: --> Press a key on the console to reboot, kernel: --> or switch off the system now. kernel: Rebooting... The panic appears randomly after the boot , it can be an hour as can be 3 or more hours . Thank you very much for your time Marcello __ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
On Thu, 6 Mar 2003, Morten Rodal wrote: > On Thu, Mar 06, 2003 at 08:50:41PM +0100, Attila Nagy wrote: > > Hello, > > > > > I briefly searched my mailbox for other panics with this panic string, > > > but all the others seem to be due to tcp_input and not the filesystem > > > (as I suspect mine is). The machine is running a SMP kernel built > > > yesterday (Wed Mar 5 22:50:35 CET 2003). > > Is it like this one? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46861 > > > > No, these seem to be caused by a bug in the tcp code (may be fixed in > -current?) > Unfortunately, it doesn't - just got another one for this morning's -CURRENT. Once again with CVS. Regards, Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
On Thu, 6 Mar 2003, Attila Nagy wrote: > Hello, > > > I briefly searched my mailbox for other panics with this panic string, > > but all the others seem to be due to tcp_input and not the filesystem > > (as I suspect mine is). The machine is running a SMP kernel built > > yesterday (Wed Mar 5 22:50:35 CET 2003). > Is it like this one? > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46861 > > I get these every day, don't matter if the machine is an SMP one, or just > a UP. (I tried and can reproduce this panic on at least 3 different > machines) > BTW, kernel compiled on Feb 26 morning works with no panics (although I have to disble hw.ata.ata_dma for it) Regards, Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
On Thu, Mar 06, 2003 at 08:50:41PM +0100, Attila Nagy wrote: > Hello, > > > I briefly searched my mailbox for other panics with this panic string, > > but all the others seem to be due to tcp_input and not the filesystem > > (as I suspect mine is). The machine is running a SMP kernel built > > yesterday (Wed Mar 5 22:50:35 CET 2003). > Is it like this one? > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46861 > No, these seem to be caused by a bug in the tcp code (may be fixed in -current?) -- Morten Rodal pgp0.pgp Description: PGP signature
Re: panic: bwrite: buffer is not busy???
Hello, > I briefly searched my mailbox for other panics with this panic string, > but all the others seem to be due to tcp_input and not the filesystem > (as I suspect mine is). The machine is running a SMP kernel built > yesterday (Wed Mar 5 22:50:35 CET 2003). Is it like this one? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46861 I get these every day, don't matter if the machine is an SMP one, or just a UP. (I tried and can reproduce this panic on at least 3 different machines) --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: bwrite: buffer is not busy???
I briefly searched my mailbox for other panics with this panic string,
but all the others seem to be due to tcp_input and not the filesystem
(as I suspect mine is). The machine is running a SMP kernel built
yesterday (Wed Mar 5 22:50:35 CET 2003).
Unfortunatly I was not able to save the stack backtrace from DDB, but
I hope the gdb backtrace will help someone figure out what may have
caused this.
--
Morten Rodal
Script started on Thu Mar 6 19:30:12 2003
slurp# gdb -k kernel.1 vmcore.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
Stack backtrace:
boot() called on cpu#0
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 18h38m45s
Dumping 447 MB
16[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] 32 48 64 80 96 112 128 144 160 176 192
208 224 240 256 272 288 304 320 336 352 368 384 400 416 432
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01d43ca in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01d46a7 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0218dc2 in bwrite (bp=0xccb1ec98) at /usr/src/sys/kern/vfs_bio.c:795
#4 0xc021a909 in vfs_bio_awrite (bp=0xccb1ec98)
at /usr/src/sys/kern/vfs_bio.c:1692
#5 0xc02a881a in ffs_fsync (ap=0xe35928a4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:257
#6 0xc02a78f9 in ffs_sync (mp=0xc3a73200, waitfor=2, cred=0xc1376e80,
td=0xc0363180) at vnode_if.h:612
#7 0xc022f8bb in sync (td=0xc0363180, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#8 0xc01d3fab in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
#9 0xc01d46a7 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#10 0xc0218dc2 in bwrite (bp=0xcca077d8) at /usr/src/sys/kern/vfs_bio.c:795
#11 0xc021974c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1138
#12 0xc022178a in cluster_wbuild (vp=0xc3cf85b4, size=16384, start_lbn=50,
len=2) at /usr/src/sys/kern/vfs_cluster.c:996
#13 0xc0220d7f in cluster_write (bp=0xcca47310, filesize=847872, seqcount=1)
at /usr/src/sys/kern/vfs_cluster.c:596
#14 0xc02a949f in ffs_write (ap=0xe3592bc4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:836
#15 0xc0237c7d in vn_write (fp=0xc41b2ca8, uio=0xe3592c70,
active_cred=0xc3aa7380, flags=0, td=0xc4152780) at vnode_if.h:417
#16 0xc01f7928 in dofilewrite (td=0xc4152780, fp=0xc41b2ca8, fd=0,
buf=0x8e12e00, nbyte=0, offset=0, flags=0) at file.h:239
#17 0xc01f7769 in write (td=0xc4152780, uap=0xe3592d10)
at /usr/src/sys/kern/sys_generic.c:329
#18 0xc030be8c in syscall (frame=
{tf_fs = 262191, tf_es = 47, tf_ds = -1079246801, tf_edi = 0, tf_esi =
671674624, tf_ebp = -1077939880, tf_isp = -480694924, tf_ebx = 671686852, tf_edx = 29,
tf_ecx = 0, tf_eax = 4, tf_trapno = 22, tf_err = 2, tf_eip = 677083971, tf_cs = 31,
tf_eflags = 518, tf_esp = -1077939940, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1030
#19 0xc02f404d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
(kgdb) slurp# ^Dexit
Script done on Thu Mar 6 19:30:29 2003
pgp0.pgp
Description: PGP signature
Panic bwrite: buffer is not busy on fresh -CURRENT
ot properly dismounted
cd0 at ata0 bus 0 target 0 lun 0
cd0: <_NEC CD-RW NR-9100A 2.12> Removable CD-ROM SCSI-0 device
cd0: 33.000MB/s transfers
cd0: cd present [270253 x 2048 byte records]
kushnir1# gdb -k /usr/obj/usr/src/sys/KUSHNIR/kernel.debug /usr/crash/vmcore.0
GNU gdb 5.2.1 (FreeBSD)
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x20
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0194106
stack pointer = 0x10:0xcad27a90
frame pointer = 0x10:0xcad27ab4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 14 (swi1: net)
trap number = 12
panic: page fault
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 14h56m24s
Dumping 191 MB
ata2: resetting devices ..
done
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc019e5c2 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc019e823 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc01e2b72 in bwrite (bp=0xc5c06b38) at /usr/src/sys/kern/vfs_bio.c:853
#4 0xc01e45e9 in vfs_bio_awrite (bp=0xc5c06b38)
at /usr/src/sys/kern/vfs_bio.c:1781
#5 0xc01ebfff in vop_stdfsync (ap=0xcad27888)
at /usr/src/sys/kern/vfs_default.c:755
#6 0xc0167590 in spec_fsync (ap=0xcad27888)
at /usr/src/sys/fs/specfs/spec_vnops.c:422
#7 0xc0166a68 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:123
#8 0xc026cd21 in ffs_sync (mp=0xc1f7, waitfor=2, cred=0xc0d38e80,
td=0xc0315360) at vnode_if.h:612
#9 0xc01f94cb in sync (td=0xc0315360, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#10 0xc019e1ac in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
#11 0xc019e823 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#12 0xc02cc742 in trap_fatal (frame=0xcad27a50, eva=0)
at /usr/src/sys/i386/i386/trap.c:843
#13 0xc02cc422 in trap_pfault (frame=0xcad27a50, usermode=0, eva=32)
at /usr/src/sys/i386/i386/trap.c:757
#14 0xc02cbf10 in trap (frame=
{tf_fs = -1033764840, tf_es = 16, tf_ds = 16, tf_edi = -1059808208,
tf_esi---Type to continue, or q to quit---
= 0, tf_ebp = -892175692, tf_isp = -892175748, tf_ebx = -1070450964, tf_edx =
-1059808208, tf_ecx = -1037471508, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip =
-1072086778, tf_cs = 8, tf_eflags = 66050, tf_esp = 16, tf_ss = -1071488976}) at
/usr/src/sys/i386/i386/trap.c:444
#15 0xc02bc1c8 in calltrap () at {standard input}:96
#16 0xc021fd79 in tcp_input (m=0xc0d49c30, off0=20)
at /usr/src/sys/netinet/tcp_input.c:2324
#17 0xc0218c56 in ip_input (m=0xc0d56100)
at /usr/src/sys/netinet/ip_input.c:947
#18 0xc0218d42 in ipintr () at /usr/src/sys/netinet/ip_input.c:965
#19 0xc020c25f in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:97
#20 0xc018a471 in ithread_loop (arg=0xc0d47100)
at /usr/src/sys/kern/kern_intr.c:536
#21 0xc0189373 in fork_exit (callout=0xc018a2a0 , arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:871
(kgdb) q
#
# KUSHNIR - my customized kernel configuration
#
machine i386
cpu I686_CPU
ident KUSHNIR
maxusers0
options CPU_ENABLE_SSE
options PQ_CACHESIZE=512
#To statically compile in device wiring instead of /boot/device.hints
#hints "KUSHNIR.hints" #Default places to look for devices.
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
options INET#InterNETworking
options INET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options SOFTUPDATES #Enable FFS soft updates support
options UFS_ACL #Support for access control lists
options UFS_DIRHASH #Improve performance on big directories
options UFS_EXTATTR
options UFS_EXTATTR_AUTOSTART
#optionsMD_ROOT #MD is a potential root device
#optionsPSEUDOFS#Pseudo-filesystem framework
options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 #Compatible with FreeBSD4
options KTRACE #ktrace(1) support
options SCHED_4BSD
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions
#optionsP1003_1B_SEMAPHORES
#optionsHZ=1000
# Debugging f
panic: bwrite: buffer is not busy
FYI,
Panic with sources from Feb. 20th 02:00 CET.
FreeBSD talisker 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Thu Feb 20 22:42:15 CET 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/TALISKER i386
[EMAIL PROTECTED]:/home/patric$ gdb -k /sys/i386/compile/TALISKER/kernel.debug
/var/crash/vmcore.3
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1d82099
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02dd53c
stack pointer = 0x10:0xd68edc68
frame pointer = 0x10:0xd68edc90
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13 (swi6: tty:sio clock)
trap number = 12
panic: page fault
Stack backtrace:
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 8h36m41s
Dumping 511 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc0257439 in boot (howto=260) at ../../../kern/kern_shutdown.c:371
#2 0xc02576a3 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc029be52 in bwrite (bp=0xce6ccfa8) at ../../../kern/vfs_bio.c:842
#4 0xc029d611 in vfs_bio_awrite (bp=0xce6ccfa8) at ../../../kern/vfs_bio.c:1724
#5 0xc02a4fa7 in vop_stdfsync (ap=0xd68eda60) at ../../../kern/vfs_default.c:755
#6 0xc020f3d0 in spec_fsync (ap=0xd68eda60) at ../../../fs/specfs/spec_vnops.c:422
#7 0xc020e8a8 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:123
#8 0xc0323b27 in ffs_sync (mp=0xc4208600, waitfor=2, cred=0xc1543e80, td=0xc04091a0)
at vnode_if.h:612
#9 0xc02b27cb in sync (td=0xc04091a0, uap=0x0) at ../../../kern/vfs_syscalls.c:138
#10 0xc025701c in boot (howto=256) at ../../../kern/kern_shutdown.c:280
#11 0xc02576a3 in panic () at ../../../kern/kern_shutdown.c:542
#12 0xc037ed42 in trap_fatal (frame=0xd68edc28, eva=0) at ../../../i386/i386/trap.c:844
#13 0xc037ea22 in trap_pfault (frame=0xd68edc28, usermode=0, eva=30941337) at
../../../i386/i386/trap.c:758
#14 0xc037e510 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1070738224, tf_esi = -1001969344,
tf_ebp = -695280496, tf_isp = -695280556, tf_ebx = 30941133, tf_edx = -1051358400,
tf_ecx = -1001969304, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = -1070738116,
tf_cs = 8, tf_eflags = 66050, tf_esp = -1071263219, tf_ss = -1069485760}) at
../../../i386/i386/trap.c:445
#15 0xc036e818 in calltrap () at {standard input}:96
#16 0xc02670e5 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:195
#17 0xc02432a1 in ithread_loop (arg=0xc1555e80) at ../../../kern/kern_intr.c:536
#18 0xc0242193 in fork_exit (callout=0xc02430d0 , arg=0x0, frame=0x0) at
../../../kern/kern_fork.c:878
(kgdb) f 17
#17 0xc02432a1 in ithread_loop (arg=0xc1555e80) at ../../../kern/kern_intr.c:536
536 ih->ih_handler(ih->ih_argument);
(kgdb) l
531 mtx_unlock(&ithd->it_lock);
532 goto restart;
533 }
534 if ((ih->ih_flags & IH_MPSAFE) == 0)
535 mtx_lock(&Giant);
536 ih->ih_handler(ih->ih_argument);
537 if ((ih->ih_flags & IH_MPSAFE) == 0)
538 mtx_unlock(&Giant);
539 }
540 }
(kgdb) p ih->ih_argument
$1 = (void *) 0x0
HAND,
Patric
--
The problem with troubleshooting is that trouble shoots back.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 5.0R - panic: bwrite: buffer is not busy
In message <[EMAIL PROTECTED]>, Patric Mrawek writes: >I am seeing a reproducible panic with > >FreeBSD talisker 5.0-RELEASE FreeBSD 5.0-RELEASE #5: Wed Jan 29 10:49:32 CET 2003 >root@talisker:/usr/src/sys/i386/compile/TALISKER i386 > >What I've done is: >- kldload uvisor.ko >- running »/usr/sbin/usbd -d -v« >- running »jpilot-sync -d -l -p /dev/ucom0« >- hitting the sync-button from my visor several times > >After hitting the sync-button 5 to 10 times my box panics. it looks like a device disappeared while you had it open. I'll commit a workaround for this later today. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0R - panic: bwrite: buffer is not busy
I am seeing a reproducible panic with
FreeBSD talisker 5.0-RELEASE FreeBSD 5.0-RELEASE #5: Wed Jan 29 10:49:32 CET 2003
root@talisker:/usr/src/sys/i386/compile/TALISKER i386
What I've done is:
- kldload uvisor.ko
- running »/usr/sbin/usbd -d -v«
- running »jpilot-sync -d -l -p /dev/ucom0«
- hitting the sync-button from my visor several times
After hitting the sync-button 5 to 10 times my box panics.
I've some coredumps handy, so I can dig (with some help) deeper into
this.
Script started on Wed Feb 19 22:16:30 2003
patric@talisker:/home/patric$ gdb -k /sys/i386/compile/TALISKER/kernel.debug
/var/crash/vmcore.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x32
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc020c793
stack pointer = 0x10:0xd8db7ad8
frame pointer = 0x10:0xd8db7b0c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 68897 (jpilot-sync)
trap number = 12
panic: page fault
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 11h14m26s
Dumping 511 MB
ata0: resetting devices ..
done
[CTRL-C to abort] 16[CTRL-C to abort] 32 48 64 80 96 112 128 144 160 176 192 208 224
240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc024abd9 in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc024ae23 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc0290bd2 in bwrite (bp=0xce6aa2f0) at ../../../kern/vfs_bio.c:796
#4 0xc02922b5 in vfs_bio_awrite (bp=0xce6aa2f0) at ../../../kern/vfs_bio.c:1643
#5 0xc03183ba in ffs_fsync (ap=0xd8db78e0) at ../../../ufs/ffs/ffs_vnops.c:258
#6 0xc0317517 in ffs_sync (mp=0xc4206200, waitfor=2, cred=0xc1541e80, td=0xc03f6ee0)
at vnode_if.h:612
#7 0xc02a5e2b in sync (td=0xc03f6ee0, uap=0x0) at ../../../kern/vfs_syscalls.c:138
#8 0xc024a7bc in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#9 0xc024ae23 in panic () at ../../../kern/kern_shutdown.c:517
#10 0xc03717a2 in trap_fatal (frame=0xd8db7a98, eva=0) at ../../../i386/i386/trap.c:844
#11 0xc0371482 in trap_pfault (frame=0xd8db7a98, usermode=0, eva=50) at
../../../i386/i386/trap.c:758
#12 0xc0370f70 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -656704716, tf_esi = -2144570347,
tf_ebp = -656704756, tf_isp = -656704828, tf_ebx = -994069960, tf_edx = -656704716,
tf_ecx = 21, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071593581, tf_cs = 8,
tf_eflags = 66050, tf_esp = -997247744, tf_ss = -2144570347}) at
../../../i386/i386/trap.c:445
#13 0xc0361778 in calltrap () at {standard input}:98
#14 0xc020c058 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:126
#15 0xc02ae671 in vn_ioctl (fp=0xc4244bf4, com=2150396949, data=0xd8db7c48,
active_cred=0xd8db7b34, td=0xc4264b60)
at vnode_if.h:488
#16 0xc026f8b3 in ioctl (td=0xc4264b60, uap=0xd8db7d10) at file.h:227
#17 0xc0371aca in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 24, tf_esi = 134691616, tf_ebp =
-1077944152, tf_isp = -656704140, tf_ebx = 1213062036, tf_edx = 24, tf_ecx = 24,
tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 1212593395, tf_cs = 31, tf_eflags =
582, tf_esp = -1077944244, tf_ss = 47}) at ../../../i386/i386/trap.c:1033
#18 0xc03617cd in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) l *0xc020c793
0xc020c793 is in spec_ioctl (../../../fs/specfs/spec_vnops.c:346).
341 int error;
342 struct cdevsw *dsw;
343
344 dev = ap->a_vp->v_rdev;
345 dsw = devsw(dev);
346 if (dsw->d_flags & D_NOGIANT) {
347 DROP_GIANT();
348 error = dsw->d_ioctl(dev, ap->a_command,
349 ap->a_data, ap->a_fflag, ap->a_td);
350 PICKUP_GIANT();
(kgdb)
$FreeBSD: src/sys/fs/specfs/spec_vnops.c,v 1.186 2002/11/04 07:29:20 mckusick Exp $
Patric
--
The problem with troubleshooting is that trouble shoots back.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
current panic: bwrite: buffer is not busy???
Hi,
under current as of today on a IBM A30p notebook I get the above panic
under load often.
A backtrace is attached.
Anything else to analyze or inspect?
Bye!
Michael Reifenberger
^.*Plaut.*$, IT, R/3 Basis, GPS
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: vm_fault: fault on nofault entry, addr: cba17000
syncing disks... panic: bwrite: buffer is not busy???
Uptime: 6h5m50s
pfs_vncache_unload(): 1 entries remaining
Dumping 1023 MB
ata0: resetting devices ..
(cd0:ata0:0:1:0): lost device
(cd0:ata0:0:1:0): removing device entry
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
#0 doadump () at ../../../kern/kern_shutdown.c:214
214 dumpsys(&dumper);
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:214
#1 0xc01b364e in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01b3bad in panic (fmt=0xc02da37d "bwrite: buffer is not busy???")
at ../../../kern/kern_shutdown.c:493
#3 0xc01f28d8 in bwrite (bp=0x104) at ../../../kern/vfs_bio.c:797
#4 0xc01f2c89 in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1082
#5 0xc02588b3 in ffs_fsync (ap=0xe7f1d5ec) at ../../../ufs/ffs/ffs_vnops.c:215
#6 0xc0257d67 in ffs_sync (mp=0xc2c7d400, waitfor=2, cred=0xc22b7e80,
td=0xc02fd740) at vnode_if.h:597
#7 0xc020657b in sync (td=0xc02fd740, uap=0x0)
at ../../../kern/vfs_syscalls.c:129
#8 0xc01b367b in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#9 0xc01b3bad in panic (fmt=0xc03347e0 "bwrite: buffer is not busy???")
at ../../../kern/kern_shutdown.c:493
#10 0xc0268be3 in vm_fault () at ../../../vm/vm_fault.c:263
#11 0xc02a9bda in trap_pfault (frame=0xe7f1d8b0, usermode=0, eva=3416355042)
at ../../../i386/i386/trap.c:748
#12 0xc02a95e9 in trap (frame=
{tf_fs = -403636200, tf_es = -1071710192, tf_ds = -933691376, tf_edi =
-1021802240, tf_esi = -878612260, tf_ebp = -403580320, tf_isp = -403580708, tf_ebx =
220, tf_edx = -933644552, tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =
-1021848459, tf_cs = 8, tf_eflags = 66199, tf_esp = -933644552, tf_ss = -878612252})
at ../../../i386/i386/trap.c:446
#13 0xc029aba8 in calltrap () at {standard input}:98
#14 0xc01f74ed in vfs_cache_lookup (ap=0x0) at vnode_if.h:83
#15 0xc01fbc59 in lookup (ndp=0xe7f1dc18) at vnode_if.h:54
#16 0xc01fb61a in namei (ndp=0xe7f1dc18) at ../../../kern/vfs_lookup.c:181
#17 0xc020919f in stat (td=0xc3209b40, uap=0xe7f1dd10)
at ../../../kern/vfs_syscalls.c:1549
#18 0xc02aa152 in syscall (frame=
{tf_fs = 47, tf_es = 135266351, tf_ds = -1078001617, tf_edi = 135069921, tf_esi
= 135291296, tf_ebp = -1077940296, tf_isp = -403579532, tf_ebx = 3, tf_edx =
135291344, tf_ecx = 0, tf_eax = 188, tf_trapno = 12, tf_err = 2, tf_eip = 134725983,
tf_cs = 31, tf_eflags = 659, tf_esp = -1077940420, tf_ss = 47})
at ../../../i386/i386/trap.c:1050
#19 0xc029abfd in Xint0x80_syscall () at {standard input}:140
(kgdb) up
#1 0xc01b364e in boot (howto=260) at ../../../kern/kern_shutdown.c:345
345 doadump();
(kgdb)
#2 0xc01b3bad in panic (fmt=0xc02da37d "bwrite: buffer is not busy???")
at ../../../kern/kern_shutdown.c:493
493 boot(bootopt);
(kgdb)
#3 0xc01f28d8 in bwrite (bp=0x104) at ../../../kern/vfs_bio.c:797
797 panic("bwrite: need chained iodone");
(kgdb)
#4 0xc01f2c89 in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1082
1082(void) BUF_WRITE(bp);
(kgdb)
#5 0xc02588b3 in ffs_fsync (ap=0xe7f1d5ec) at ../../../ufs/ffs/ffs_vnops.c:215
215 (void) bawrite(bp);
(kgdb)
#6 0xc0257d67 in ffs_sync (mp=0xc2c7d400, waitfor=2, cred=0xc22b7e80,
td=0xc02fd740) at vnode_if.h:597
597 rc = VCALL(vp, VOFFSET(vop_fsync), &a);
(kgdb)
#7 0xc020657b in sync (td=0xc02fd740, uap=0x0)
at ../../../kern/vfs_syscalls.c:129
129 ((td != NULL) ? td->td_ucred : NOCRED), td);
(kgdb)
#8 0xc01b367b in boot (howto=256) at ../../../kern/kern_shutdown.c:254
254 sync(&thread0, NULL);
(kgdb)
#9 0xc01b3bad in panic (fmt=0xc03347e0 "bwrite: buffer is not busy???")
at ../../../kern/kern_shutdown.c:493
493
Re: panic: bwrite: buffer is not busy???
Alfred Perlstein <[EMAIL PROTECTED]> writes: > if checkdirs wins the race for proc lock it will do its magic and > fdfree will wait while it does that. > > if fdfree wins, then checkdirs will see a NULL p_fd pointer. You're right. I'm still worried about other fdfree() callers, though, but this patch is definitely better than the current state of affairs, so you might as well commit it :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
* Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020318 15:03] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > * Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020318 08:23] wrote:
> > > Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > > > I think you're right, I'm pretty sure the fix is basically moving
> > > > the p->p_fd = NULL to after the closef will fix things [...]
> > > There will still be a race...
> > Are you sure? :)
>
> Almost, though I think the window will be much smaller than it is now.
> The only way I see of avoiding it alltogether is to protect p->p_fd
> and its mutex with allproc_lock (IOW, destroy the table as the last
> thing you do before zombifying the process)
Actually...
if checkdirs wins the race for proc lock it will do its magic and
fdfree will wait while it does that.
if fdfree wins, then checkdirs will see a NULL p_fd pointer.
> > Btw, is there a way to easily reproduce this bug?
>
> No, it's a race condition, which makes it hard to trigger on purpose.
>
> The problem with your patch is that *every* place in the kernel that
> calls FILEDESC_LOCK needs to first acquire the proc lock and check if
> p->p_fd is NULL.
No, only when a sideways access occurs, like in checkdirs().
I think this ought to fix it.
Index: kern/vfs_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.231
diff -u -r1.231 vfs_syscalls.c
--- kern/vfs_syscalls.c 12 Mar 2002 04:00:10 - 1.231
+++ kern/vfs_syscalls.c 18 Mar 2002 23:18:34 -
@@ -446,29 +446,34 @@
{
struct filedesc *fdp;
struct proc *p;
+ int nrele;
if (olddp->v_usecount == 1)
return;
sx_slock(&allproc_lock);
LIST_FOREACH(p, &allproc, p_list) {
+ PROC_LOCK(p);
fdp = p->p_fd;
- if (fdp == NULL)
+ if (fdp == NULL) {
+ PROC_UNLOCK(p);
continue;
+ }
+ nrele = 0;
FILEDESC_LOCK(fdp);
if (fdp->fd_cdir == olddp) {
VREF(newdp);
fdp->fd_cdir = newdp;
- FILEDESC_UNLOCK(fdp);
- vrele(olddp);
- FILEDESC_LOCK(fdp);
+ nrele++;
}
if (fdp->fd_rdir == olddp) {
VREF(newdp);
fdp->fd_rdir = newdp;
- FILEDESC_UNLOCK(fdp);
+ nrele++;
+ }
+ FILEDESC_UNLOCK(fdp);
+ PROC_UNLOCK(p);
+ while (nrele--)
vrele(olddp);
- } else
- FILEDESC_UNLOCK(fdp);
}
sx_sunlock(&allproc_lock);
if (rootvnode == olddp) {
Index: kern/kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.128
diff -u -r1.128 kern_descrip.c
--- kern/kern_descrip.c 15 Mar 2002 08:03:46 - 1.128
+++ kern/kern_descrip.c 18 Mar 2002 19:04:24 -
@@ -1321,10 +1321,11 @@
fdfree(td)
struct thread *td;
{
- register struct filedesc *fdp = td->td_proc->p_fd;
+ register struct filedesc *fdp;
struct file **fpp;
register int i;
+ fdp = td->td_proc->p_fd;
/* Certain daemons might not have file descriptors. */
if (fdp == NULL)
return;
@@ -1344,6 +1345,11 @@
if (*fpp)
(void) closef(*fpp, td);
}
+
+ PROC_LOCK(td->td_proc);
+ td->td_proc->p_fd = NULL;
+ PROC_UNLOCK(td->td_proc);
+
if (fdp->fd_nfiles > NDFILE)
FREE(fdp->fd_ofiles, M_FILEDESC);
if (fdp->fd_cdir)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
Kris Kennaway <[EMAIL PROTECTED]> writes: > The panic in tail was triggered by using -f (i.e. kqueue), Like I said, that panic was irrelevant since it was a consequence of an incorrect patch. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
On Mon, Mar 18, 2002 at 02:36:31PM -0800, Alfred Perlstein wrote: > * Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020318 08:23] wrote: > > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > I think you're right, I'm pretty sure the fix is basically moving > > > the p->p_fd = NULL to after the closef will fix things [...] > > > > There will still be a race... > > Are you sure? :) > > Btw, is there a way to easily reproduce this bug? The panic in tail was triggered by using -f (i.e. kqueue), but it's only happened once on the cluster..err..twice now (just happened again). Without your previous patch several cluster machines were failing several times per hour, in umount. You could probably trigger it by stressing these two code paths. I'll test your latest patch a bit later on. Kris msg36321/pgp0.pgp Description: PGP signature
Re: panic: bwrite: buffer is not busy???
Alfred Perlstein <[EMAIL PROTECTED]> writes: > * Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020318 08:23] wrote: > > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > I think you're right, I'm pretty sure the fix is basically moving > > > the p->p_fd = NULL to after the closef will fix things [...] > > There will still be a race... > Are you sure? :) Almost, though I think the window will be much smaller than it is now. The only way I see of avoiding it alltogether is to protect p->p_fd and its mutex with allproc_lock (IOW, destroy the table as the last thing you do before zombifying the process) > Btw, is there a way to easily reproduce this bug? No, it's a race condition, which makes it hard to trigger on purpose. The problem with your patch is that *every* place in the kernel that calls FILEDESC_LOCK needs to first acquire the proc lock and check if p->p_fd is NULL. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
* Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020318 08:23] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > I think you're right, I'm pretty sure the fix is basically moving
> > the p->p_fd = NULL to after the closef will fix things [...]
>
> There will still be a race...
Are you sure? :)
Btw, is there a way to easily reproduce this bug?
Index: kern/kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.128
diff -u -r1.128 kern_descrip.c
--- kern/kern_descrip.c 15 Mar 2002 08:03:46 - 1.128
+++ kern/kern_descrip.c 18 Mar 2002 19:04:24 -
@@ -1321,10 +1321,11 @@
fdfree(td)
struct thread *td;
{
- register struct filedesc *fdp = td->td_proc->p_fd;
+ register struct filedesc *fdp;
struct file **fpp;
register int i;
+ fdp = td->td_proc->p_fd;
/* Certain daemons might not have file descriptors. */
if (fdp == NULL)
return;
@@ -1344,6 +1345,11 @@
if (*fpp)
(void) closef(*fpp, td);
}
+
+ PROC_LOCK(td->td_proc);
+ td->td_proc->p_fd = NULL;
+ PROC_UNLOCK(td->td_proc);
+
if (fdp->fd_nfiles > NDFILE)
FREE(fdp->fd_ofiles, M_FILEDESC);
if (fdp->fd_cdir)
Index: kern/vfs_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.231
diff -u -r1.231 vfs_syscalls.c
--- kern/vfs_syscalls.c 12 Mar 2002 04:00:10 - 1.231
+++ kern/vfs_syscalls.c 18 Mar 2002 19:05:23 -
@@ -451,9 +451,12 @@
return;
sx_slock(&allproc_lock);
LIST_FOREACH(p, &allproc, p_list) {
+ PROC_LOCK(p);
fdp = p->p_fd;
- if (fdp == NULL)
+ if (fdp == NULL) {
+ PROC_UNLOCK(p);
continue;
+ }
FILEDESC_LOCK(fdp);
if (fdp->fd_cdir == olddp) {
VREF(newdp);
@@ -469,6 +472,7 @@
vrele(olddp);
} else
FILEDESC_UNLOCK(fdp);
+ PROC_UNLOCK(p);
}
sx_sunlock(&allproc_lock);
if (rootvnode == olddp) {
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
Alfred Perlstein <[EMAIL PROTECTED]> writes: > I think you're right, I'm pretty sure the fix is basically moving > the p->p_fd = NULL to after the closef will fix things [...] There will still be a race... > Sorry for taking so long to look at this. No problem, really. It showed up less than 24 hours ago, your response time is pretty good in my book :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
BTW, I actually ran across a related bug (or possibly the exact same)
about a week ago, but didn't post a stack trace because I thought the
panic might be a consequence of some other patches I was testing. The
kernel debugging tutorial mwlucas is preparing is based on this stack
trace, though :)
(kgdb) where
#0 dumpsys () at ../../../kern/kern_shutdown.c:505
#1 0xc0143119 in db_fncall (dummy1=0, dummy2=0, dummy3=0,
dummy4=0xe0b749a4 " \0048\200%") at ../../../ddb/db_command.c:551
#2 0xc0142f33 in db_command (last_cmdp=0xc0313724, cmd_table=0xc0313544,
aux_cmd_tablep=0xc030df2c, aux_cmd_tablep_end=0xc030df30)
at ../../../ddb/db_command.c:348
#3 0xc0142fff in db_command_loop () at ../../../ddb/db_command.c:474
#4 0xc0145393 in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#5 0xc02ad0f6 in kdb_trap (type=12, code=0, regs=0xe0b74af4)
at ../../../i386/i386/db_interface.c:161
#6 0xc02ba004 in trap_fatal (frame=0xe0b74af4, eva=40)
at ../../../i386/i386/trap.c:846
#7 0xc02b9d71 in trap_pfault (frame=0xe0b74af4, usermode=0, eva=40)
at ../../../i386/i386/trap.c:765
#8 0xc02b9907 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 0, tf_ebp = -524858548, tf_isp = -524858592,
tf_ebx = -525288192, tf_edx = 0, tf_ecx = 10, tf_eax = 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1071645917, tf_cs = 8,
tf_eflags = 66182, tf_esp = -1070136512, tf_ss = 0})
at ../../../i386/i386/trap.c:433
#9 0xc01ffb23 in vcount (vp=0xe0b0bd00) at ../../../kern/vfs_subr.c:2301
#10 0xc01a5e58 in spec_close (ap=0xe0b74b94)
at ../../../fs/specfs/spec_vnops.c:591
#11 0xc01a55f1 in spec_vnoperate (ap=0xe0b74b94)
at ../../../fs/specfs/spec_vnops.c:121
#12 0xc0207454 in vn_close (vp=0xe0b0bd00, flags=3, cred=0xc32cce00,
td=0xe0a8d360) at vnode_if.h:183
#13 0xc0207fab in vn_closefile (fp=0xc3369080, td=0xe0a8d360)
at ../../../kern/vfs_vnops.c:757
#14 0xc01b1d50 in fdrop_locked (fp=0xc3369080, td=0xe0a8d360)
at ../../../sys/file.h:230
#15 0xc01b155a in fdrop (fp=0xc3369080, td=0xe0a8d360)
at ../../../kern/kern_descrip.c:1538
#16 0xc01b152d in closef (fp=0xc3369080, td=0xe0a8d360)
at ../../../kern/kern_descrip.c:1524
#17 0xc01b114e in fdfree (td=0xe0a8d360) at ../../../kern/kern_descrip.c:1345
#18 0xc01b5173 in exit1 (td=0xe0a8d360, rv=256)
at ../../../kern/kern_exit.c:199
#19 0xc01b4ec2 in sys_exit (td=0xe0a8d360, uap=0xe0b74d20)
at ../../../kern/kern_exit.c:109
#20 0xc02ba2b7 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 135227560, tf_esi = 0, tf_ebp = -1077941020,
tf_isp = -524857996, tf_ebx = -1, tf_edx = 135044144,
tf_ecx = -1077942116, tf_eax = 1, tf_trapno = 12, tf_err = 2,
tf_eip = 134865696, tf_cs = 31, tf_eflags = 663, tf_esp = -1077941064,
tf_ss = 47}) at ../../../i386/i386/trap.c:1049
#21 0xc02ae06d in syscall_with_err_pushed ()
#22 0x80503a5 in ?? ()
#23 0x807024a in ?? ()
#24 0xbfbfffb4 in ?? ()
#25 0x807daaf in ?? ()
#26 0x807d6eb in ?? ()
#27 0x80630c1 in ?? ()
#28 0x8062fed in ?? ()
#29 0x805ea4c in ?? ()
#30 0x8065949 in ?? ()
#31 0x806544d in ?? ()
#32 0x806dc17 in ?? ()
#33 0x80616b7 in ?? ()
#34 0x80613f0 in ?? ()
#35 0x8048135 in ?? ()
(kgdb) up 9
#9 0xc01ffb23 in vcount (vp=0xe0b0bd00) at ../../../kern/vfs_subr.c:2301
2301SLIST_FOREACH(vq, &vp->v_rdev->si_hlist, v_specnext)
(kgdb) p *vp
$1 = {v_flag = 8, v_usecount = 2, v_writecount = 1, v_holdcnt = 0,
v_id = 6985, v_mount = 0x0, v_op = 0xc2d52a00, v_freelist = {tqe_next = 0x0,
tqe_prev = 0xe083de1c}, v_nmntvnodes = {tqe_next = 0xe0b0b700,
tqe_prev = 0xe0b0c024}, v_cleanblkhd = {tqh_first = 0x0,
tqh_last = 0xe0b0bd2c}, v_dirtyblkhd = {tqh_first = 0x0,
tqh_last = 0xe0b0bd34}, v_synclist = {le_next = 0x0, le_prev = 0x0},
v_numoutput = 0, v_type = VBAD, v_un = {vu_mountedhere = 0x0,
vu_socket = 0x0, vu_spec = {vu_specinfo = 0x0, vu_specnext = {
sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_lastw = 0, v_cstart = 0,
v_lasta = 0, v_clen = 0, v_object = 0x0, v_interlock = {mtx_object = {
lo_class = 0xc0335c60, lo_name = 0xc02ef5c1 "vnode interlock",
lo_flags = 196608, lo_list = {stqe_next = 0x0}, lo_witness = 0x0},
mtx_lock = 4, mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0,
tqh_last = 0xe0b0bd84}, mtx_contested = {le_next = 0x0, le_prev = 0x0},
tsp = {tv_sec = 3584, tv_nsec = 101067509},
file = 0xc02ef50a "../../../kern/vfs_subr.c", line = 1726,
has_trace_time = 0}, v_lock = {lk_interlock = 0xc036e320,
lk_flags = 16777216, lk_sharecount = 0, lk_waitcount = 0,
lk_exclusivecount = 0, lk_prio = 80, lk_wmesg = 0xc02ef5d1 "vnlock",
lk_timo = 6, lk_lockholder = -1}, v_vnlock = 0x0, v_tag = VT_NON,
v_data = 0x0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {
tqh_first = 0x0, tqh_last = 0xe0b0bdd8}, v_dd = 0xe0b0bd00, v_ddid = 0,
v_pollinfo = 0x0, v_vxproc = 0x0}
(kgdb) up 8
#17 0xc01b114e in fdfree (td=0xe0a8d360) at
Re: panic: bwrite: buffer is not busy???
Kris Kennaway <[EMAIL PROTECTED]> writes: > With the corrected version of that patch (and a patch from Tor to fix > VM deadlocks in green's commit) I got this panic. ...which is completely uninteresting, actually, except as proof that the patch (and my initial analysis) is incorrect. With the patch applied, tail(1) will *always* cause this panic; it is a direct and inevitable consequence of the patch clearing p->p_fd before calling closef(). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
On Sun, Mar 17, 2002 at 11:16:23PM -0800, Alfred Perlstein wrote:
> * Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020317 22:55] wrote:
> > Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > > Please let me know if this works for you.
> > > [...]
> > > + PROC_LOCK(td);
> >
> > *cough* *cough*
> >
> > :)
>
> It was untested. :) I'm sure you can fix it, I've got to get some
> sleep, let me know if it works for you.
With the corrected version of that patch (and a patch from Tor to fix
VM deadlocks in green's commit) I got this panic. DES has been taking
a look at it, but I'm sending it here in case anyone else has insight
too.
Kris
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x48
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01f833c
stack pointer = 0x10:0xda1a8b4c
frame pointer = 0x10:0xda1a8b74
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 92729 (tail)
trap number = 12
panic: page fault
syncing disks... panic: bwrite: buffer is not busy???
Uptime: 27m34s
dumping to dev ad0b, offset 1051136
dump ata0: resetting devices .. done
510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490
489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469
468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448
447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427
426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406
405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385
384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364
363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343
342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322
321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301
300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280
279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259
258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238
237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217
216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196
195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175
174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154
153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133
132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112
111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87
86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58
57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29
28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../../kern/kern_shutdown.c:505
505 ../../../kern/kern_shutdown.c: No such file or directory.
b(kgdb) bt
#0 dumpsys () at ../../../kern/kern_shutdown.c:505
#1 0xc020d4b4 in boot (howto=260) at ../../../kern/kern_shutdown.c:337
#2 0xc020d953 in panic (fmt=0xc0376d4b "bwrite: buffer is not busy???")
at ../../../kern/kern_shutdown.c:647
#3 0xc0242c3b in bwrite (bp=0xce63eb88) at ../../../kern/vfs_bio.c:747
#4 0xc024404a in vfs_bio_awrite (bp=0xce63eb88) at ../../../kern/vfs_bio.c:1606
#5 0xc01e49e8 in spec_fsync (ap=0xda1a8a08) at ../../../fs/specfs/spec_vnops.c:403
#6 0xc01e45a5 in spec_vnoperate (ap=0xda1a8a08) at ../../../fs/specfs/spec_vnops.c:121
#7 0xc02e818c in ffs_sync (mp=0xc4061400, waitfor=2, cred=0xc145a980, td=0xc03b3000)
at vnode_if.h:441
#8 0xc02505e9 in sync (td=0xc03b3000, uap=0x0) at ../../../kern/vfs_syscalls.c:673
#9 0xc020d100 in boot (howto=256) at ../../../kern/kern_shutdown.c:246
#10 0xc020d953 in panic (fmt=0xc039501e "%s") at ../../../kern/kern_shutdown.c:647
#11 0xc03335d0 in trap_fatal (frame=0xda1a8b0c, eva=72) at
../../../i386/i386/trap.c:851
#12 0xc03332f9 in trap_pfault (frame=0xda1a8b0c, usermode=0, eva=72) at
../../../i386/i386/trap.c:765
#13 0xc0332d83 in trap (frame={tf_fs = -1001521128, tf_es = -1069678576, tf_ds =
-635830256,
tf_edi = -1001489664, tf_esi = 0, tf_ebp = -635794572, tf_isp = -635794632,
tf_ebx = -1002099200, tf_edx = 4, tf_ecx = -636822144, tf_eax = 4, tf_trapno =
12, tf_err = 2,
tf_eip = -1071676612, tf_cs = 8, tf_eflags = 66194, tf_esp = -10020
Re: panic: bwrite: buffer is not busy???
Alfred Perlstein <[EMAIL PROTECTED]> writes: > It was untested. :) I'm sure you can fix it, I've got to get some > sleep, let me know if it works for you. Sure. Turns out the patch doesn't work, because closef() needs p->p_fd to be valid. This is really tricky; you either need to protect *every* access to p->p_fd with the proc lock, or figure out some other way of handling things. fdfree() is currently used in a handful of places: - in kern_exec.c, an fdcopy() / fdfree() combo is used to unshare the file table in case it is shared (vfork()); this is a waste of time unless the table actually *is* shared, which is easy to check. This could replaced by a single call to a new function, fdunshare(), which checks the reference count and does an fdcopy() if it is greater than 1. - in kern_exit.c, fdfree() is used to close all file descriptors and destroy the table before turning the process into a zombie (this is the one that's giving us trouble). This could be handled by an fdclear() function, with the actual destruction of the filedesc and its mutex (performed by a new fddestroy() function?) left off until the last possible moment, after the process has been removed from the process table. - in kern_fork.c, one case where an fdcopy() / fdfree() combo is used to unshare the file table (see comment above about fdunshare()) and one case where fdfree() / fdinit() is used to completely clear the file table (RFCFDG case). The latter could be handled by a new fdclear() function. - in vfs_aio.c, fdfree() is called once to destroy the aio daemon's file table, and twice to dereference the client's file table after it has been temporarily "borrowed" by the aio daemon. This code gives me a headache, for several reasons (one of which is a potential race condition similar to the one we're already seeing in kern_exit.c; another is its rather cavalier treatment of curproc) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
* Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020317 22:55] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > Please let me know if this works for you. > > [...] > > + PROC_LOCK(td); > > *cough* *cough* > > :) It was untested. :) I'm sure you can fix it, I've got to get some sleep, let me know if it works for you. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
Alfred Perlstein <[EMAIL PROTECTED]> writes: > Please let me know if this works for you. > [...] > + PROC_LOCK(td); *cough* *cough* :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
On Sun, Mar 17, 2002 at 10:17:39PM -0800, Alfred Perlstein wrote: > * Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020317 19:27] wrote: > > > > ...the process has no open files at all, because... > > > > (kgdb) p p->p_pid > > $4 = 10099 > > (kgdb) p p->p_comm > > $5 = "wc\000oot", '\000' > > (kgdb) p p->p_stat > > $6 = 3 > > (kgdb) p/x p->p_flag > > $7 = 0x6000 > > > > ...it's exiting, and fdfree() has already run. > > > > Solution: p->p_fd must be protected by p's proc lock; fdfree() must > > set it to NULL immediately after freeing it; checkdirs() must lock > > each process before examining its fd list. > > > > Other problem spotted while investigating this: fdfree() can fail > > silently; fdfree() should panic if fdp->fd_refcnt is non-zero. > > Please let me know if this works for you. Thanks, will test once the current run is finished. Kris msg36280/pgp0.pgp Description: PGP signature
Re: panic: bwrite: buffer is not busy???
* Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020317 19:27] wrote:
>
> ...the process has no open files at all, because...
>
> (kgdb) p p->p_pid
> $4 = 10099
> (kgdb) p p->p_comm
> $5 = "wc\000oot", '\000'
> (kgdb) p p->p_stat
> $6 = 3
> (kgdb) p/x p->p_flag
> $7 = 0x6000
>
> ...it's exiting, and fdfree() has already run.
>
> Solution: p->p_fd must be protected by p's proc lock; fdfree() must
> set it to NULL immediately after freeing it; checkdirs() must lock
> each process before examining its fd list.
>
> Other problem spotted while investigating this: fdfree() can fail
> silently; fdfree() should panic if fdp->fd_refcnt is non-zero.
Please let me know if this works for you.
Index: vfs_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.231
diff -u -r1.231 vfs_syscalls.c
--- vfs_syscalls.c 12 Mar 2002 04:00:10 - 1.231
+++ vfs_syscalls.c 18 Mar 2002 06:23:41 -
@@ -451,10 +451,14 @@
return;
sx_slock(&allproc_lock);
LIST_FOREACH(p, &allproc, p_list) {
+ PROC_LOCK(p);
fdp = p->p_fd;
- if (fdp == NULL)
+ if (fdp == NULL) {
+ PROC_UNLOCK(p);
continue;
+ }
FILEDESC_LOCK(fdp);
+ PROC_UNLOCK(p);
if (fdp->fd_cdir == olddp) {
VREF(newdp);
fdp->fd_cdir = newdp;
Index: kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.128
diff -u -r1.128 kern_descrip.c
--- kern_descrip.c 15 Mar 2002 08:03:46 - 1.128
+++ kern_descrip.c 18 Mar 2002 06:23:39 -
@@ -1321,19 +1321,26 @@
fdfree(td)
struct thread *td;
{
- register struct filedesc *fdp = td->td_proc->p_fd;
+ register struct filedesc *fdp;
struct file **fpp;
register int i;
+ PROC_LOCK(td);
+ fdp = td->td_proc->p_fd;
/* Certain daemons might not have file descriptors. */
- if (fdp == NULL)
+ if (fdp == NULL) {
+ PROC_UNLOCK(td);
return;
+ }
FILEDESC_LOCK(fdp);
if (--fdp->fd_refcnt > 0) {
FILEDESC_UNLOCK(fdp);
+ PROC_UNLOCK(td);
return;
}
+ td->td_proc->p_fd = NULL;
+ PROC_UNLOCK(td);
/*
* we are the last reference to the structure, we can
* safely assume it will not change out from under us.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
Kris Kennaway <[EMAIL PROTECTED]> writes:
> #14 0xc0204b92 in _mtx_lock_sleep (m=0xc2f91f34, opts=0, file=0x0, line=0)
> at ../../../kern/kern_mutex.c:370
(kgdb) up 14
#14 0xc0204b92 in _mtx_lock_sleep (m=0xc2f91f34, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:370
370 td1 = mtx_owner(m);
(kgdb) p *m
$1 = {mtx_object = {lo_class = 0x0, lo_name = 0x0, lo_flags = 0, lo_list = {
stqe_next = 0x0}, lo_witness = 0x0}, mtx_lock = 2, mtx_recurse = 0,
mtx_blocked = {tqh_first = 0x0, tqh_last = 0x0}, mtx_contested = {
le_next = 0x0, le_prev = 0x0}}
The mutex is uninitialized (destroyed, actually), because...
> #15 0xc024f55c in checkdirs (olddp=0xcf1814c0, newdp=0xcf1815a0) at
>../../../kern/vfs_syscalls.c:457
(kgdb) up
#15 0xc024f55c in checkdirs (olddp=0xcf1814c0, newdp=0xcf1815a0)
at ../../../kern/vfs_syscalls.c:457
457 FILEDESC_LOCK(fdp);
(kgdb) p *fdp
$2 = {fd_ofiles = 0xc2f91200, fd_ofileflags = 0xc2f91f00 "", fd_cdir = 0x0,
fd_rdir = 0x0, fd_jdir = 0x0, fd_nfiles = 0, fd_lastfile = 0,
fd_freefile = -1024110592, fd_cmask = 0, fd_refcnt = 0, fd_knlistsize = 4,
fd_knlist = 0x11, fd_knhashmask = 0, fd_knhash = 0xdb, fd_mtx = {
mtx_object = {lo_class = 0x0, lo_name = 0x0, lo_flags = 0, lo_list = {
stqe_next = 0x0}, lo_witness = 0x0}, mtx_lock = 2, mtx_recurse = 0,
mtx_blocked = {tqh_first = 0x0, tqh_last = 0x0}, mtx_contested = {
le_next = 0x0, le_prev = 0x0}}}
...the process has no open files at all, because...
(kgdb) p p->p_pid
$4 = 10099
(kgdb) p p->p_comm
$5 = "wc\000oot", '\000'
(kgdb) p p->p_stat
$6 = 3
(kgdb) p/x p->p_flag
$7 = 0x6000
...it's exiting, and fdfree() has already run.
Solution: p->p_fd must be protected by p's proc lock; fdfree() must
set it to NULL immediately after freeing it; checkdirs() must lock
each process before examining its fd list.
Other problem spotted while investigating this: fdfree() can fail
silently; fdfree() should panic if fdp->fd_refcnt is non-zero.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
Kris Kennaway <[EMAIL PROTECTED]> writes: > [...] "up 14" followed by "p *m" would be nice; making the dump and the debugging kernel available on freefall would be even nicer. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bwrite: buffer is not busy???
On Sun, Mar 17, 2002 at 12:49:58PM -0800, Kris Kennaway wrote: > I tried upgrading the bento cluster to 5.x so I can actually get 5.0 > packages built (eaccess problems), and 5 of them blew up in about 10 > minutes with this (I think this is going to be an .. uh .. interesting > test of the stability of 5.0-CURRENT): > > IdlePTD at phsyical address 0x004a6000 > initial pcb at physical address 0x003e9040 > panicstr: bwrite: buffer is not busy??? > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x58 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0204b92 > stack pointer = 0x10:0xcf0fac2c > frame pointer = 0x10:0xcf0fac34 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= resume, IOPL = 0 > current process = 10095 (umount) > trap number = 12 > panic: page fault As Peter pointed out to me, this is the actual panic; the "bwrite: buffer is not busy???" is spurious and caused by the kernel trying to sync after the first panic. All of the problems I'm currently seeing are in umount. Kris msg36268/pgp0.pgp Description: PGP signature
Re: panic: bwrite: buffer is not busy???
On Sun, Mar 17, 2002 at 12:49:58PM -0800, Kris Kennaway wrote: > I tried upgrading the bento cluster to 5.x so I can actually get 5.0 > packages built (eaccess problems), and 5 of them blew up in about 10 > minutes with this (I think this is going to be an .. uh .. interesting > test of the stability of 5.0-CURRENT): I forgot to mention that they were running -current as of about a week ago. I upgraded to the CVS head, and 4 of the machines wedged solid in 2 minutes of load. I suspect greenvm :-) Kris msg36264/pgp0.pgp Description: PGP signature
panic: bwrite: buffer is not busy???
I tried upgrading the bento cluster to 5.x so I can actually get 5.0
packages built (eaccess problems), and 5 of them blew up in about 10
minutes with this (I think this is going to be an .. uh .. interesting
test of the stability of 5.0-CURRENT):
IdlePTD at phsyical address 0x004a6000
initial pcb at physical address 0x003e9040
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x58
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0204b92
stack pointer = 0x10:0xcf0fac2c
frame pointer = 0x10:0xcf0fac34
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 10095 (umount)
trap number = 12
panic: page fault
syncing disks... panic: bwrite: buffer is not busy???
Uptime: 5m52s
dumping to dev ad0b, offset 1575424
dump ata0: resetting devices .. done
254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234
233 232 231 230 229
228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208
207 206 205 204 20
3 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182
181 180 179 178 1
77 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156
155 154 153 152
151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131
130 129 128 127 126
125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105
104 103 102 101 10
0 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72
71 70 69 68 67 66
65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38
37 36 35 34 33 32
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../../kern/kern_shutdown.c:505
505 ../../../kern/kern_shutdown.c: No such file or directory.
(kgdb) bt
#0 dumpsys () at ../../../kern/kern_shutdown.c:505
#1 0xc020cd48 in boot (howto=260) at ../../../kern/kern_shutdown.c:337
#2 0xc020d1e7 in panic (fmt=0xc0375b4b "bwrite: buffer is not busy???")
at ../../../kern/kern_shutdown.c:647
#3 0xc02425e3 in bwrite (bp=0xc7740920) at ../../../kern/vfs_bio.c:747
#4 0xc02438da in vfs_bio_awrite (bp=0xc7740920) at ../../../kern/vfs_bio.c:1604
#5 0xc01e453c in spec_fsync (ap=0xcf0faae8) at ../../../fs/specfs/spec_vnops.c:403
#6 0xc01e40f9 in spec_vnoperate (ap=0xcf0faae8) at ../../../fs/specfs/spec_vnops.c:121
#7 0xc02e7420 in ffs_sync (mp=0xc25ca600, waitfor=2, cred=0xc0e40980, td=0xc03b1de0)
at vnode_if.h:441
#8 0xc024fb95 in sync (td=0xc03b1de0, uap=0x0) at ../../../kern/vfs_syscalls.c:669
#9 0xc020c994 in boot (howto=256) at ../../../kern/kern_shutdown.c:246
#10 0xc020d1e7 in panic (fmt=0xc0393e1e "%s") at ../../../kern/kern_shutdown.c:647
#11 0xc03324a0 in trap_fatal (frame=0xcf0fabec, eva=88) at
../../../i386/i386/trap.c:851
#12 0xc03321c9 in trap_pfault (frame=0xcf0fabec, usermode=0, eva=88) at
../../../i386/i386/trap.c:765
#13 0xc0331c53 in trap (frame={tf_fs = -822542312, tf_es = -821100528, tf_ds =
-1071382512,
tf_edi = 4, tf_esi = -1023860940, tf_ebp = -821056460, tf_isp = -821056488,
tf_ebx = -822490624, tf_edx = 0, tf_ecx = 2, tf_eax = 2, tf_trapno = 12, tf_err
= 0,
tf_eip = -1071625326, tf_cs = 8, tf_eflags = 65606, tf_esp = -1023860992, tf_ss
= -822498560})
at ../../../i386/i386/trap.c:433
#14 0xc0204b92 in _mtx_lock_sleep (m=0xc2f91f34, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:370
#15 0xc024f55c in checkdirs (olddp=0xcf1814c0, newdp=0xcf1815a0) at
../../../kern/vfs_syscalls.c:457
#16 0xc024f87b in dounmount (mp=0xc2e20c00, flags=524288, td=0xcef9ca00)
at ../../../kern/vfs_syscalls.c:583
#17 0xc024f73e in unmount (td=0xcef9ca00, uap=0xcf0fad20) at
../../../kern/vfs_syscalls.c:543
#18 0xc0332770 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi =
134809160,
tf_esi = 134914149, tf_ebp = -1077938936, tf_isp = -821056140, tf_ebx =
134914150, tf_edx = 0,
tf_ecx = -1077937306, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip =
134523171, tf_cs = 31,
tf_eflags = 643, tf_esp = -1077939044, tf_ss = 47}) at
../../../i386/i386/trap.c:1049
#19 0xc0323dad in syscall_with_err_pushed ()
Kris
P.S. Yes, I'm only swapping onto a device once this time :-)
msg36262/pgp0.pgp
Description: PGP signature
