Bug 17839

	"Page fault while in kernel mode" panic whenever /etc/security
	is run. (This is very inconvenient since /etc/periodic/daily
	runs it daily.)

	The instruction pointer at the time of the page fault is bogus,
	apparently since biodone() is jumping off the deep end.

	I suspect the ad driver since a traceback shows ad_interrupt()
	calling biodone() leading up to the panic.  See below.

	I suspect the biodone() code is failing in an SMP environment
	since it runs fine on my uniprocessor hardware.

	I am running some of my filesytems under vinum so it may have a
	role in this too.

	It gave up trying to sync 492 dirty buffers following the panic.
	That seems like a lot to me so perhaps that's related to the
	panic? FWIW, crash dumps work fine through the ata driver once
	it is reset following the panic.

	(kgdb) where
	#0  0xc0151390 in boot ()
	#1  0xc0151748 in poweroff_wait ()
	#2  0xc028670f in trap_fatal ()
	#3  0xc02863a5 in trap_pfault ()
	#4  0xc0285f77 in trap ()
	#5  0xc0ef8ef4 in ?? ()	<-- instruction pointer at time of page fault
	#6  0xc01752d7 in biodone ()
	#7  0xc0258a5e in ad_interrupt ()
	#8  0xc025544e in ata_intr ()

	This line printed by panic() may be helpful:
		interrupt mask          = bio  <- SMP: XXX
	since it seems to have something to do with the SMP code.

Fix: 

Don't have one yet, but I'll tell you what I've tried:

	I tried running a kernel with INVARIANT set and that didn't catch
	anything.

	I tried running a kernel with VFS_BIO_DEBUG set and that didn't
	even make it throught /etc/rc before panicing.

	I don't know what to try next, but I'll happily run any further
	tests you can propose on my hardware.  Should I try -CURENT?
How-To-Repeat: 
	Just run /etc/security on the above hardware.  Blamo.

	The panic happens about 5 minutes into /etc/security, perhaps
	since I have several filesystems.  Some use vinum and some don't.

	Other activity may well also cause the panic, but /etc/security
	kills it every time.