i386/116100: Fatal trap 12 right after reboot (da0s1error = 6)

[Bruce Evans]

The following reply was made to PR i386/116100; it has been noted by GNATS.

From: Bruce Evans <brde at optusnet.com.au>
To: Dmitry Andrianov <666.root at gmail.com>
Cc: freebsd-gnats-submit at FreeBSD.org, freebsd-i386 at FreeBSD.org
Subject: Re: i386/116100: Fatal trap 12 right after reboot (da0s1error = 6)
Date: Wed, 5 Sep 2007 15:47:49 +1000 (EST)

 On Wed, 5 Sep 2007, Dmitry Andrianov wrote:
 
 >> Environment:
 > 7.0-CURRENT-200704 FreeBSD 7.0-CURRENT-200704 #0: Sun Apr  1 14:46:54 UTC 2007  root at almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
 
 This is old, so not broken by me :-).
 
 >> Description:
 > bash-2.05b#mount -t msdosfs /dev/da0s1 /mnt
 > bash-2.05b#
 > ..
 > bash-2.05b#reboot
 >
 > <118>Sep  3 18:54:08 zingel reboot: rebooted by root
 > <118>Sep  3 18:54:08 zingel syslogd: exiting on signal 15
 > Waiting (max 60 seconds) for system process `vnlru' to stop...done
 > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
 > Waiting (max 60 seconds) for system process `syncer' to stop...
 > Syncing disks, vnodes remaining...1 0 0 0 done
 > All buffers synced.
 > g_vfs_done():da0s1[READ(offset=65536, length=4096)]error = 6
 
 An i/o error in unmount is likely to cause problems.  The system never
 gives up trying to write unwriteable buffers, and tends to panic trying
 to write them later.  I recently fixed some panics in unmount (not yet
 committed), but the fix is to make unmount not fail, and that won't
 help for reboot because unmount cannot fail.  msdosfs and perhaps even
 ffs normally does a write in unmount _after_ the "All buffers synced"
 message has been printed.
 
 > (da0:dead_sim0:0:0:0): Synchronize cache failed, status == 0x8, scsi status == 0x0
 > (da0:dead_sim0:0:0:0): removing device entry
 
 Removing a device entry is a wrong thing to do if there is i/o pending on
 the device.  It would work if the i/o is reattached to dead_something,
 but that apparently isn't done.
 
 You need to figure out what caused the i/o error -- is it msdosfs, the
 disk driver or the disk?
 
 Bruce