Date: Thu, 27 May 1999 12:10:52 +0200 (CEST) From: talon@lpthe.jussieu.fr (Michel TALON) To: wilko@yedi.iaf.nl (Wilko Bulte) Cc: freebsd-stable@freebsd.org Subject: Re: Stability Message-ID: <199905271010.MAA00428@niobe.lpthe.jussieu.fr> In-Reply-To: <199905262148.XAA00507@yedi.iaf.nl> from Wilko Bulte at "May 26, 1999 11:48:24 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to the message from Wilko Bulte
> As Michel TALON wrote ...
> > In reply to the message from Wilko Bulte
> > > As Michel TALON wrote ...
> > > > May i add my own story to the instability question?
> > >
> > > > Second i made a small experiment trying to see wether the floppy
> > > > problem is still there. Namelly dd something to a write-protected
> > > > floppy. The answer is still the same, namely instant panic.
> > > > Of course it is too easy to try to mount a protected floppy and
> > > > try to write on it. This should never produce a panic. The problem
> > > > was a bug report but has not been adressed.
> I can make it panic by doing: "dd if=/kernel of=/dev/fd0". It will not panic
> when you do "dd if=/kernel of=/dev/rfd0" (note the rfd0 instead of fd0).
>
> Using "dd if=/kernel of=/dev/fd0" you get heaps of console error messages
> like:
>
> May 26 23:20:38 yedi /kernel: fd0c: hard error writing fsbn 296 of 296-299
> (ST0
> 40<abnrml> ST1 2<write_protect> ST2 0 cyl 8 hd 0 sec 9)
> May 26 23:20:38 yedi /kernel: fd0c: hard error writing fsbn 300 of 300-303
> (ST0
> 40<abnrml> ST1 2<write_protect> ST2 0 cyl 8 hd 0 sec 13)
> May 26 23:20:38 yedi /kernel: fd0c: hard error writing fsbn 304 of 304-307
> (ST0
> 40<abnrml> ST1 2<write_protect> ST2 0 cyl 8 hd 0 sec 17)
> May 26 23:20:38 yedi /kernel: fd0c: hard error writing fsbn 308 of 308-311
> (ST0
> 40<abnrml> ST1 2<write_protect> ST2 0 cyl 8 hd 1 sec 3)
>
> etc. etc.
>
> And then a panic:
>
> What I think is happening is that the buffering of the block device keeps
> 'dd' going for a while until after some point the flush fails (remember, the
> disk is hardware write protected) and the kernel gives up with a panic.
>
> Looks to me like what happened in the old days when you pressed the
> 'write protect' button on your root disk drive.
>
> Use rfd0 and you are fine. The I/O immediately fails with an error and 'dd'
> notices this and also gives up.
>
> Comments?
Indeed i agree completely. When writing to /dev/rfd0 an error is
properly reported, but writing to /dev/fd0 panics the system. Hence
there is a bug in the buffering code. To help understand it here is
the gdb report using a kernel with debugging symbols:
Script started on Thu May 27 11:36:53 1999
GNU gdb 4.18
Copyright 1998 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-unknown-freebsd"...
IdlePTD 2969600
initial pcb at 258aac
panicstr: vinvalbuf: dirty bufs
panic messages:
---
panic: vinvalbuf: dirty bufs
syncing disks... 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 giving up
dumping to dev 20401, offset 90112
dump 256 255 .......
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc0141ac0 in at_shutdown (
function=0xc022a8d8 <__set_sysctl__kern_sym_sysctl___kern_maxvnodes+176>,
arg=0xc90889c0, queue=-922187328) at ../../kern/kern_shutdown.c:446
#2 0xc0165cdc in vinvalbuf (vp=0xc90889c0, flags=1, cred=0xc0f14a00,
p=0xc8fe6a20, slpflag=0, slptimeo=0) at ../../kern/vfs_subr.c:599
#3 0xc01726cc in spec_close (ap=0xc9097e84)
at ../../miscfs/specfs/spec_vnops.c:648
#4 0xc01d97ba in ufsspec_close (ap=0xc9097e84)
at ../../ufs/ufs/ufs_vnops.c:1872
#5 0xc01d9c8d in ufs_vnoperatespec (ap=0xc9097e84)
at ../../ufs/ufs/ufs_vnops.c:2317
#6 0xc016c528 in vn_close (vp=0xc90889c0, flags=3, cred=0xc0f14a00,
p=0xc8fe6a20) at vnode_if.h:191
#7 0xc016cce1 in vn_closefile (fp=0xc0f5ae80, p=0xc8fe6a20)
at ../../kern/vfs_vnops.c:559
#8 0xc013a92c in closef (fp=0xc0f5ae80, p=0xc8fe6a20)
at ../../kern/kern_descrip.c:1065
#9 0xc013a723 in fdfree (p=0xc8fe6a20) at ../../kern/kern_descrip.c:977
#10 0xc013bbbb in exit1 (p=0xc8fe6a20, rv=256) at ../../kern/kern_exit.c:199
#11 0xc013ba24 in exit1 (p=0xc8fe6a20, rv=-922124396)
at ../../kern/kern_exit.c:104
#12 0xc01ff40f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 134598656,
tf_esi = 0, tf_ebp = -1077945416, tf_isp = -922124316, tf_ebx = -1,
---Type <return> to continue, or q <return> to quit---
tf_edx = 58, tf_ecx = -60, tf_eax = 1, tf_trapno = 22, tf_err = 2,
tf_eip = 134561160, tf_cs = 31, tf_eflags = 582, tf_esp = -1077945432,
tf_ss = 39}) at ../../i386/i386/trap.c:1100
#13 0xc01f59cc in Xint0x80_syscall ()
#14 0x8049835 in ?? ()
#15 0xbfbfdfdc in ?? ()
#16 0x80486c2 in ?? ()
#17 0x804931a in ?? ()
#18 0x8048b65 in ?? ()
#19 0x80480e9 in ?? ()
(kgdb) quit
sh-2.02# exit
Script done on Thu May 27 11:37:53 1999
--
Michel TALON
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905271010.MAA00428>