never attempt to hash directories once they are deleted. This fixes
a problem where operations on a deleted directory could trigger
dirhash sanity panics.
about rules and dynamic rules. it later fills this buffer with these
rules.
it also takes the opporunity to compare the expiration of the dynamic
rules with the current time and either marks them for deletion or simply
charges the countdown.
unfortunatly it does this all (the sizing, the buffer copying, and the
expiration GC) with no spl protection whatsoever. it was possible for
the dynamic rule(s) to be ripped out from under the request before it
had completed, resulting in corrupt memory dereferencing.
Reviewed by: ps
MFC before: 4.4-RELEASE, hopefully.
to supply the number of bytes to be bcopy()'d to move an entry. If
d_ino == 0 however, DIRSIZ() is not guaranteed to return a sensible
length, so ufs_direnter could end up corrupting a directory during
compaction. In practice I believe this can only happen after fsck_ffs
has fixed a previously-corrupted directory.
We now deal with any mid-block unused entries specially to avoid
using DIRSIZ() or bcopy() on such entries. We also ensure that the
variables 'dsize' and 'spacefree' contain meaningful values at all
times. Add a few comments to describe better this intricate piece
of code.
The special handling of mid-block unused entries makes the dirhash-
specific bugfix in the previous revision (1.53) now uncecessary,
so this change removes it.
Reviewed by: mckusick
interrupt for the CSC interrupt, then we revert to ISA. If we didn't
have an interrupt set up with hw.pcic.irq, then do polling.
Also, don't complain about ignoring function 1 for any devices except
pcic devices. This would normally only show up if someone set
hw.pcic.ignore_function_1=1.
MFC: as soon as I can test it on some troublesome laptops.
on and off since John Dyson left his work-in-progress.
It is off by default for now. sysctl vm.zeroidle_enable=1 to turn it on.
There are some hacks here to deal with the present lack of preemption - we
yield after doing a small number of pages since we wont preempt otherwise.
This is basically Matt's algorithm [with hysteresis] with an idle process
to call it in a similar way it used to be called from the idle loop.
I cleaned up the includes a fair bit here too.
level implementation stuff out of machine/globaldata.h to avoid exposing
UPAGES to lots more places. The end result is that we can double
the kernel stack size with 'options UPAGES=4' etc.
This is mainly being done for the benefit of a MFC to RELENG_4 at some
point. -current doesn't really need this so much since each interrupt
runs on its own kstack.
I'm at it also add a comment in mtx_validate() explaining the purpose
of the last change.
Basically, this fixes booting kernels compiled with MUTEX_DEBUG. What used
to happen is before we setidt from init386() [still using BTX idt], we
called mtx_init() on several mutex locks, notably Giant and some others.
This is a problem for MUTEX_DEBUG because it enables mtx_validate() which
calls kernacc(), some of which in turn requires Giant.
Fix by calling kernacc() from mtx_validate() only if (!cold).
explain the subtle side effects that are going to happen and why we go
ahead and ack the interrupt source. This stuff is tricky to get
right.
Also, emperical tests have shown that doing a shutdown in attach to be
ineffectual, so remove it from there. Analysis of the code paths
shows that nearly identical writes to these registers happen in later
parts of the code. The hanging problem on thinkpads when we change
the interrupt routing type is something else.
shutdown and also before we get going with the device initialization.
This may fix the hangs some people are seeing on warmboot. It appears
that some machines will reset the cardbus bridge on boot, while others
don't. So we turn off the card, and ack the interrupts (which likely
is a nop in the shutdown case since we're still fielding interrupts).
This should turn off the interrupts.
Since I don't have hardware that hangs on reboot, I'm committing this
without testing that aspect of the patch (it causes no harm on my
Dell).
initialization structure. Warn the user for those chipsets that
aren't yet customized that they might not work. Second, try to power
off the slot on attach and ack the interrupts. I don't know, but this
might solve the hangs that people will see on Thinkpads if they set
hw.pcic.init_routing=1.
go into the PLX 9052's interrupt control register and turn on the magic
interrupt enable bit.
Partial thanks are due to OpenBSD for pointing out that the chip is a
PLX 9052 and pointing me to the datasheet PDF.
