Re: panic: bdwrite: buffer is not busy
After rebuilding world/kernel/debug today I get some better info (I fear
my debug kernel was out of synch with my running kernel before, but
because of my inexperience with debugging I didn't figure that out right
away):
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: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc227e6f4
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01db660
stack pointer = 0x10:0xd1f9ba7c
frame pointer = 0x10:0xd1f9ba94
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 = 55992 (smtpd)
trap number = 12
panic: page fault
syncing disks... panic: bdwrite: buffer is not busy
Uptime: 3h49m4s
Dumping 256 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01bb513 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01bb71b in panic () at ../../../kern/kern_shutdown.c:491
#3 0xc01f8bdd in bdwrite (bp=0x104) at ../../../kern/vfs_bio.c:947
#4 0xc026b28d in ffs_update (vp=0xc1de5b58, waitfor=0) at
../../../ufs/ffs/ffs_inode.c:125
#5 0xc027df77 in ffs_fsync (ap=0xd1f9b8f4) at ../../../ufs/ffs/ffs_vnops.c:272
#6 0xc027c308 in ffs_sync (mp=0xc1c1ce00, waitfor=2, cred=0xc0ef6f00, td=0xc032e080)
at vnode_if.h:463
#7 0xc0209e43 in sync (td=0xc032e080, uap=0x0) at ../../../kern/vfs_syscalls.c:127
#8 0xc01bb19c in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#9 0xc01bb71b in panic () at ../../../kern/kern_shutdown.c:491
#10 0xc02c596e in trap_fatal (frame=0x100, eva=0) at ../../../i386/i386/trap.c:845
#11 0xc02c565c in trap_pfault (frame=0xd1f9ba3c, usermode=0, eva=3257394932)
at ../../../i386/i386/trap.c:759
#12 0xc02c50b7 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1042227796, tf_ebp =
-772162924, tf_isp = -772162968, tf_ebx = -1037572416, tf_edx = 180, tf_ecx =
-1040183148, tf_eax = -1037572368, tf_trapno = 12, tf_err = 2, tf_eip = -1071794592,
tf_cs = 8, tf_eflags = 66118, tf_esp = -1070377308, tf_ss = -772162904})
at ../../../i386/i386/trap.c:445
#13 0xc02b73a8 in calltrap () at {standard input}:98
#14 0xc01f1269 in sowakeup (so=0xc1e0ddac, sb=0xc227e6c0) at
../../../kern/uipc_socket2.c:300
#15 0xc01f0e51 in soisconnected (so=0xc2096640) at ../../../kern/uipc_socket2.c:132
#16 0xc01f6c1d in unp_connect2 (so=0x0, so2=0xc1e0dd48) at
../../../kern/uipc_usrreq.c:769
#17 0xc01f6b7b in unp_connect (so=0xc24a6578, nam=0xc25bb300, td=0x0) at
../../../kern/uipc_usrreq.c:737
#18 0xc01f5c7e in uipc_connect (so=0x0, nam=0x0, td=0xc204d9c0) at
../../../kern/uipc_usrreq.c:161
#19 0xc01eee21 in soconnect (so=0xc2096640, nam=0x0, td=0x0) at
../../../kern/uipc_socket.c:429
#20 0xc01f2bcb in connect (td=0x0, uap=0xc1e0dd48) at ../../../kern/uipc_syscalls.c:441
#21 0xc02c5c70 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 11, tf_esi = 0, tf_ebp =
-1077938120, tf_isp = -772162188, tf_ebx = 134704296, tf_edx = 2, tf_ecx = 0, tf_eax =
98, tf_trapno = 22, tf_err = 2, tf_eip = 671913163, tf_cs = 31, tf_eflags = 582,
tf_esp = -1077938276, tf_ss = 47}) at ../../../i386/i386/trap.c:1049
#22 0xc02b73dd in syscall_with_err_pushed () at {standard input}:128
---Can't read userspace from dump, or kernel process---
If there's anything else than this I can provide, pleas let me know.
--
Munish Chopra
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: bdwrite: buffer is not busy
And another one comes along: 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: bdwrite: buffer is not busy panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc2601cf4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01d9b60 stack pointer = 0x10:0xd1efba7c frame pointer = 0x10:0xd1efba94 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 = 53252 (smtpd) trap number = 12 panic: page fault syncing disks... panic: bdwrite: buffer is not busy Uptime: 18h49m23s Dumping 256 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 0x in ?? () -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bdwrite: buffer is not busy
Third one: 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: bdwrite: buffer is not busy panic messages: --- panic: bad pte syncing disks... panic: bdwrite: buffer is not busy Uptime: 3h37m11s Dumping 256 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 0x in ?? () Does anyone know what is going on or how I can get some more information out of this dump to track this down? I'd really like to resolve this... -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: bdwrite: buffer is not busy
I've been having inexplicable crashes for a while and finally got around to getting a debug kernel and checking out what's going on, so here goes (apologies for the ^M's and all, I scripted a gdb session and that's what I got...): panic: bdwrite: buffer is not busy panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc1ca20f4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01d9b60 stack pointer = 0x10:0xd1e20a7c frame pointer = 0x10:0xd1e20a94 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 = 828 (smtpd) trap number = 12 panic: page fault syncing disks... panic: bdwrite: buffer is not busy Uptime: 43m45s Dumping 256 MB ata0: resetting devices .. done 16 32[CTRL-C to abort] 48[CTRL-C to abort] 64 80 96 112 128 144[CTRL-C to abort] 160[CTRL-C to abort] 176 192 208 224 240 --- #0 0x in ?? () (kgdb) hw where #0 0x in ?? () (kgdb) quit I've caught a few of these by hand while working in the console before, but thought they'd been resolved until now. FreeBSD CPE0030ab0ef2bb.cpe.net.cable.rogers.com 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Sun Jul 14 20:26:50 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARCADIA i386 The sources are from about 1800 EST, July 14. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bdwrite: buffer is not busy
On Sun, 10 Feb 2002, Mikhail Teterin wrote: On 10 Feb, Bruce Evans wrote: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Fdisk I don't really need, but attempting to newfs the floppy caused the same panic :-\ And mounting the already formatted floppy leads to invalid argument. Could we have this fixed soon, please? The inability to access a floppy is a great setback for my local FreeBSD advocacy efforts :-) Newfs'ing /dev/fd0 (instead of /dev/fd0[a-c]) should work better. Not using devfs might work too. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bdwrite: buffer is not busy
On 10 Feb, Bruce Evans wrote: On Sat, 9 Feb 2002, John Baldwin wrote: On 09-Feb-02 Mikhail Teterin wrote: While attempting to ``fdisk fd0.1440''. Or ``fdisk fd0''. Or ``newfs_msdos fd0.1440'' with or without the floppy inside :-\ With todays or Jan 3rd kernel (my previous upgrade). Only use fdisk on hard disks. Still it shouldn't panic. The bdwrite is just extra garbage, the real panic is due to a NULL pointer dereference: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Fdisk I don't really need, but attempting to newfs the floppy caused the same panic :-\ And mounting the already formatted floppy leads to invalid argument. Could we have this fixed soon, please? The inability to access a floppy is a great setback for my local FreeBSD advocacy efforts :-) -mi I'm guessing that devsw() is returning NULL here. You could add a KASSERT() to this macro just before the call to d_strategy() along the lines of KASSERT(devsw((bp)-bio_dev) != NULL, (no devsw for bio));\ Right. From my original bug report: ! fdisk /dev/fd0 now causes a null pointer panic in readdisklabel(). ! This is because fdioctl() attempts to construct a (slightly ! wrong) device using dkmodpart(), but dkmodpart() only constructs a ! half-baked device since it only calls makedev(). The device is ! missing a devsw so DEV_STRATEGY() in readdisklabel() panics on it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bdwrite: buffer is not busy
On Sun, 10 Feb 2002, Mikhail Teterin wrote: On 10 Feb, Bruce Evans wrote: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Fdisk I don't really need, but attempting to newfs the floppy caused the same panic :-\ And mounting the already formatted floppy leads to invalid argument. Could we have this fixed soon, please? The inability to access a floppy is a great setback for my local FreeBSD advocacy efforts :-) Newfs'ing /dev/fd0 (instead of /dev/fd0[a-c]) should work better. Not using devfs might work too. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bdwrite: buffer is not busy
On 10 Feb, Bruce Evans wrote: On Sat, 9 Feb 2002, John Baldwin wrote: On 09-Feb-02 Mikhail Teterin wrote: While attempting to ``fdisk fd0.1440''. Or ``fdisk fd0''. Or ``newfs_msdos fd0.1440'' with or without the floppy inside :-\ With todays or Jan 3rd kernel (my previous upgrade). Only use fdisk on hard disks. Still it shouldn't panic. The bdwrite is just extra garbage, the real panic is due to a NULL pointer dereference: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Fdisk I don't really need, but attempting to newfs the floppy caused the same panic :-\ And mounting the already formatted floppy leads to invalid argument. Could we have this fixed soon, please? The inability to access a floppy is a great setback for my local FreeBSD advocacy efforts :-) -mi I'm guessing that devsw() is returning NULL here. You could add a KASSERT() to this macro just before the call to d_strategy() along the lines of KASSERT(devsw((bp)-bio_dev) != NULL, (no devsw for bio));\ Right. From my original bug report: ! fdisk /dev/fd0 now causes a null pointer panic in readdisklabel(). ! This is because fdioctl() attempts to construct a (slightly ! wrong) device using dkmodpart(), but dkmodpart() only constructs a ! half-baked device since it only calls makedev(). The device is ! missing a devsw so DEV_STRATEGY() in readdisklabel() panics on it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bdwrite: buffer is not busy
On Sun, 10 Feb 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Sat, 9 Feb 2002, Julian Elischer wrote: On Sun, 10 Feb 2002, Bruce Evans wrote: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Can you commit the fix? The maintainer should be able to it better. I rarely test the devfs parts, but the bulk of the patch is to help devfs. My patch needs some cleanups (mainly non-hacked interfaces) anyway. The maintainer is busy rewriting that entire area of the code which will help immensely :-) Do you mean geom? No thanks. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: bdwrite: buffer is not busy
While attempting to ``fdisk fd0.1440''. Or ``fdisk fd0''. Or
``newfs_msdos fd0.1440'' with or without the floppy inside :-\
With todays or Jan 3rd kernel (my previous upgrade).
IdlePTD at phsyical address 0x004ed000
initial pcb at physical address 0x00411560
panicstr: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc022d923
stack pointer = 0x10:0xce9c0b10
frame pointer = 0x10:0xce9c0b24
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 = 405 (fdisk)
trap number = 12
panic: page fault
cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... panic: bdwrite: buffer is not busy
cpuid = 1; lapic.id =
boot() called on cpu#1
Uptime: 1m40s
pfs_vncache_unload(): 1 entries remaining
(kgdb) where
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:504
#1 0xc021cee8 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:336
#2 0xc021d3d9 in panic (fmt=0xc03728c1 bdwrite: buffer is not busy)
at /ccd/src/sys/kern/kern_shutdown.c:646
#3 0xc0253583 in bdwrite (bp=0xc7cb7af4) at /ccd/src/sys/kern/vfs_bio.c:856
#4 0xc02d28ee in ffs_update (vp=0xce8657a0, waitfor=0)
at /ccd/src/sys/ufs/ffs/ffs_inode.c:120
#5 0xc02dff6e in ffs_fsync (ap=0xce9c09cc)
at /ccd/src/sys/ufs/ffs/ffs_vnops.c:292
#6 0xc02de386 in ffs_sync (mp=0xc16cbe00, waitfor=2, cred=0xc1026b00,
td=0xc03cf2c0) at vnode_if.h:441
#7 0xc026034a in sync (td=0xc03cf2c0, uap=0x0)
at /ccd/src/sys/kern/vfs_syscalls.c:669
#8 0xc021cb14 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:245
#9 0xc021d3d9 in panic (fmt=0xc03914de %s)
at /ccd/src/sys/kern/kern_shutdown.c:646
#10 0xc03299e2 in trap_fatal (frame=0xce9c0ad0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:842
#11 0xc0329709 in trap_pfault (frame=0xce9c0ad0, usermode=0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:756
#12 0xc0329147 in trap (frame={tf_fs = 24, tf_es = -828637168,
tf_ds = -1071513584, tf_edi = -1049875456, tf_esi = 0,
tf_ebp = -828634332, tf_isp = -828634372, tf_ebx = -942596204,
(kgdb) where
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:504
#1 0xc021cee8 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:336
#2 0xc021d3d9 in panic (fmt=0xc03728c1 bdwrite: buffer is not busy)
at /ccd/src/sys/kern/kern_shutdown.c:646
#3 0xc0253583 in bdwrite (bp=0xc7cb7af4) at /ccd/src/sys/kern/vfs_bio.c:856
#4 0xc02d28ee in ffs_update (vp=0xce8657a0, waitfor=0)
at /ccd/src/sys/ufs/ffs/ffs_inode.c:120
#5 0xc02dff6e in ffs_fsync (ap=0xce9c09cc)
at /ccd/src/sys/ufs/ffs/ffs_vnops.c:292
#6 0xc02de386 in ffs_sync (mp=0xc16cbe00, waitfor=2, cred=0xc1026b00,
td=0xc03cf2c0) at vnode_if.h:441
#7 0xc026034a in sync (td=0xc03cf2c0, uap=0x0)
at /ccd/src/sys/kern/vfs_syscalls.c:669
#8 0xc021cb14 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:245
#9 0xc021d3d9 in panic (fmt=0xc03914de %s)
at /ccd/src/sys/kern/kern_shutdown.c:646
#10 0xc03299e2 in trap_fatal (frame=0xce9c0ad0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:842
#11 0xc0329709 in trap_pfault (frame=0xce9c0ad0, usermode=0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:756
#12 0xc0329147 in trap (frame={tf_fs = 24, tf_es = -828637168,
tf_ds = -1071513584, tf_edi = -1049875456, tf_esi = 0,
tf_ebp = -828634332, tf_isp = -828634372, tf_ebx = -942596204,
tf_esp = -942596204, tf_ss = -1049268480})
at /ccd/src/sys/i386/i386/trap.c:426
#13 0xc022d923 in readdisklabel (dev=0xc1756f00, lp=0xc16c2c00)
at /ccd/src/sys/kern/subr_disklabel.c:220
#14 0xc0338c61 in fdioctl (dev=0xc1756e00, cmd=1091855461, addr=0xc16bb200 ,
flag=1, td=0xce8daf04) at /ccd/src/sys/isa/fd.c:2707
#15 0xc01f4d1c in spec_ioctl (ap=0xce9c0ba4)
at /ccd/src/sys/fs/specfs/spec_vnops.c:320
#16 0xc01f499d in spec_vnoperate (ap=0xce9c0ba4)
at /ccd/src/sys/fs/specfs/spec_vnops.c:119
#17 0xc0266fb3 in vn_ioctl (fp=0xc1854bc0, com=1091855461, data=0xc16bb200 ,
td=0xce8daf04) at vnode_if.h:357
#18 0xc0237eeb in ioctl (td=0xce8daf04, uap=0xce9c0d20)
at /ccd/src/sys/sys/file.h:200
#19 0xc0329e98 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077936865, tf_esi = -1077937104, tf_ebp = -1077937112,
tf_isp = -828633740, tf_ebx = -1077937100, tf_edx = -1077936866,
tf_ecx = 134627389, tf_eax = 54, tf_trapno = 12, tf_err = 2,
tf_eip = 134546567, tf_cs = 31, tf_eflags = 659, tf_esp = -1077937504,
tf_ss = 47}) at /ccd/src/sys/i386/i386/trap.c:1034
#20 0xc031945d in syscall_with_err_pushed ()
(kgdb) up 3
#3 0xc0253583 in bdwrite (bp=0xc7cb7af4) at /ccd/src/sys/kern/vfs_bio.c:856
856 panic
RE: panic: bdwrite: buffer is not busy
On 09-Feb-02 Mikhail Teterin wrote:
While attempting to ``fdisk fd0.1440''. Or ``fdisk fd0''. Or
``newfs_msdos fd0.1440'' with or without the floppy inside :-\
With todays or Jan 3rd kernel (my previous upgrade).
Only use fdisk on hard disks. Still it shouldn't panic. The bdwrite is just
extra garbage, the real panic is due to a NULL pointer dereference:
IdlePTD at phsyical address 0x004ed000
initial pcb at physical address 0x00411560
panicstr: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc022d923
stack pointer = 0x10:0xce9c0b10
frame pointer = 0x10:0xce9c0b24
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 = 405 (fdisk)
trap number = 12
panic: page fault
cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... panic: bdwrite: buffer is not busy
cpuid = 1; lapic.id =
boot() called on cpu#1
Uptime: 1m40s
pfs_vncache_unload(): 1 entries remaining
(kgdb) where
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:504
#1 0xc021cee8 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:336
#2 0xc021d3d9 in panic (fmt=0xc03728c1 bdwrite: buffer is not busy)
at /ccd/src/sys/kern/kern_shutdown.c:646
#3 0xc0253583 in bdwrite (bp=0xc7cb7af4) at /ccd/src/sys/kern/vfs_bio.c:856
#4 0xc02d28ee in ffs_update (vp=0xce8657a0, waitfor=0)
at /ccd/src/sys/ufs/ffs/ffs_inode.c:120
#5 0xc02dff6e in ffs_fsync (ap=0xce9c09cc)
at /ccd/src/sys/ufs/ffs/ffs_vnops.c:292
#6 0xc02de386 in ffs_sync (mp=0xc16cbe00, waitfor=2, cred=0xc1026b00,
td=0xc03cf2c0) at vnode_if.h:441
#7 0xc026034a in sync (td=0xc03cf2c0, uap=0x0)
at /ccd/src/sys/kern/vfs_syscalls.c:669
#8 0xc021cb14 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:245
#9 0xc021d3d9 in panic (fmt=0xc03914de %s)
at /ccd/src/sys/kern/kern_shutdown.c:646
#10 0xc03299e2 in trap_fatal (frame=0xce9c0ad0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:842
#11 0xc0329709 in trap_pfault (frame=0xce9c0ad0, usermode=0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:756
#12 0xc0329147 in trap (frame={tf_fs = 24, tf_es = -828637168,
tf_ds = -1071513584, tf_edi = -1049875456, tf_esi = 0,
tf_ebp = -828634332, tf_isp = -828634372, tf_ebx = -942596204,
tf_esp = -942596204, tf_ss = -1049268480})
at /ccd/src/sys/i386/i386/trap.c:426
^^ Here's the page fault for the NULL deref, so the next frame is where it
happened:
#13 0xc022d923 in readdisklabel (dev=0xc1756f00, lp=0xc16c2c00)
at /ccd/src/sys/kern/subr_disklabel.c:220
In my subr_disklabel.c, line 220 is the DEV_STRATEGY:
bp = geteblk((int)lp-d_secsize);
bp-b_dev = dev;
bp-b_blkno = LABELSECTOR * ((int)lp-d_secsize/DEV_BSIZE);
bp-b_bcount = lp-d_secsize;
bp-b_flags = ~B_INVAL;
bp-b_iocmd = BIO_READ;
DEV_STRATEGY(bp, 1);
Hmm, DEV_STRATEGY is:
#define DEV_STRATEGY(bp, dummy) \
do {\
if ((bp)-b_flags B_PHYS) \
(bp)-b_io.bio_offset = (bp)-b_offset; \
else\
(bp)-b_io.bio_offset = dbtob((bp)-b_blkno); \
(bp)-b_io.bio_done = bufdonebio; \
(bp)-b_io.bio_caller2 = (bp); \
BIO_STRATEGY((bp)-b_io, dummy); \
} while (0)
I think we can assume the buf is not null as we would have panic'd earlier, so
that leaves BIO_STRATEGY maybe:
#define BIO_STRATEGY(bp, dummy) \
do {\
if ((!(bp)-bio_cmd) || ((bp)-bio_cmd ((bp)-bio_cmd - 1))) \
Debugger(bio_cmd botch); \
(*devsw((bp)-bio_dev)-d_strategy)(bp);\
} while (0)
I'm guessing that devsw() is returning NULL here. You could add a KASSERT() to
this macro just before the call to d_strategy() along the lines of
KASSERT(devsw((bp)-bio_dev) != NULL, (no devsw for bio));\
To see if this is indeed the case.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: panic: bdwrite: buffer is not busy
On Sat, 9 Feb 2002, John Baldwin wrote: On 09-Feb-02 Mikhail Teterin wrote: While attempting to ``fdisk fd0.1440''. Or ``fdisk fd0''. Or ``newfs_msdos fd0.1440'' with or without the floppy inside :-\ With todays or Jan 3rd kernel (my previous upgrade). Only use fdisk on hard disks. Still it shouldn't panic. The bdwrite is just extra garbage, the real panic is due to a NULL pointer dereference: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. I'm guessing that devsw() is returning NULL here. You could add a KASSERT() to this macro just before the call to d_strategy() along the lines of KASSERT(devsw((bp)-bio_dev) != NULL, (no devsw for bio));\ Right. From my original bug report: ! fdisk /dev/fd0 now causes a null pointer panic in readdisklabel(). ! This is because fdioctl() attempts to construct a (slightly wrong) ! device using dkmodpart(), but dkmodpart() only constructs a half-baked ! device since it only calls makedev(). The device is missing a devsw ! so DEV_STRATEGY() in readdisklabel() panics on it. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic: bdwrite: buffer is not busy
On Sun, 10 Feb 2002, Bruce Evans wrote: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Can you commit the fix? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic: bdwrite: buffer is not busy
On Sat, 9 Feb 2002, Julian Elischer wrote: On Sun, 10 Feb 2002, Bruce Evans wrote: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Can you commit the fix? The maintainer should be able to it better. I rarely test the devfs parts, but the bulk of the patch is to help devfs. My patch needs some cleanups (mainly non-hacked interfaces) anyway. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bdwrite: buffer is not busy
In message [EMAIL PROTECTED], Bruce Evans writes: On Sat, 9 Feb 2002, Julian Elischer wrote: On Sun, 10 Feb 2002, Bruce Evans wrote: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Can you commit the fix? The maintainer should be able to it better. I rarely test the devfs parts, but the bulk of the patch is to help devfs. My patch needs some cleanups (mainly non-hacked interfaces) anyway. The maintainer is busy rewriting that entire area of the code which will help immensely :-) -- 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
