A way to reproduce the bug is

* create a alias to bpf0 

mknod /dev/foo c 23 0		  #assuming i386

* reboot just to make sure

* first thing insert a wi0 (any pcmica/pcbus card should trigger the bug)

* start dhclient

/sbin/dhclient wi0

* Stat the `foo' file to get an alias

ls -l /dev/foo

* Pull out the card, this will trigger the bug and will put one of
  your cardslotN processes in 'vgone'. Now you system soon will get
  unusable since some program will lock the /dev and then / will get
  locked up.

The the trace is 

bpfdetach -> vdevgone -> vfinddev -> VOP_REVOKE -> genfs_revoke

	Now genfs_revoke tries to vgone all aliases vnodes
	It picks the another vnode and vgones it

vgone -> vgonel -> vclean(DOCLOSE) -> VOP_CLOSE() -> ufs_specclose ->
spec_close -> vcount

	vcount now finds the original node that we did VOP_REVOKE on
	and tries to be smart and flush it out. The problem is that
	is already VXLOCKed.


One way around the problem might be to make vcount not vnone VXLOCKed
vnodes with refcount 0.

Artur Grabowski <art@openbsd.org> helped my realize what was happening
when I showed him the problem at when we meet at work.

Love