* Mark being-deleted files in the Ifile so we can finish deleting them
at fs mount time.
* Flag the Ifile with "cleaner must clean" when writers are waiting for
the cleaner, rather than relying solely on the cleaner's estimation of
whether it should clean or not.
* Note partial segments written by a user agent (in particular,
fsck_lfs) so that repeated rolls forward don't interfere with one
another.
* Add a new fcntl, LFCNPASS, that allows the log to wrap exactly once,
for better testing of the validity of checkpoints.
* Keep track of the on-disk nlink count when cleaning, so that we don't
partially complete directory operations while cleaning.
* Ensure that every single Ifile inode write represents a consistent
view of the filesystem. In particular, the accounting for the segment
we are writing the inode into must be correct, and the accounting for
the segment that inode used to reside in must be correct. Rather than
just rewriting the inode if we wrote it wrong, rewrite the necessary
ifile blocks before writing the inode so we never write it wrong.
* Don't unmark any VDIROP vnodes if we haven't written them to disk,
avoiding yet another problem with the "wait for the cleaner" error
return from lfs_putpages().
Also, move the last callback to an aiodone call, so we no longer do any
memory management from interrupt context.
children attaching and config(1) detects isa0 as orphaned in RC3230.
While turning isabus into an interface attribute doesn't work (because the
attribute 'isabus' already exists), depending on that very same attribute
works.
XXX I wonder what to allow, what to disallow. I'll think about it.
bus_dma does and several drivers depend on it. in particular,
both re(4) and ath(4) would both spew "can't map mbuf" messages
as rapidly as possible (spamming the 9600 bps console) and
effectively locking up the interface until ifconfig "down up"
cycle was run. with this fix, i get a much, much slower spew
of messages, and the interface (re(4)) continues to operate.
The bug displayed itself by locking up console output on a 7043-140
following a powercycle. This may also have been the cause of bogus
interrupts on motorola class machines.
