It doesn't help us catch overflowing vector entries at compile time.
Instead use the .org directive. The last entry in the IVT doesn't
strictly need to be limited to 256 bytes, but doing so allows the
the VHPT to be placed immediately following the IVT without wasting
any space due to alignment.
as being valid. Previously only the magic number and the virtual
address were checked, but it makes little sense to require that
the virtual address is the same (the message buffer is located at
the end of physical memory), and checks on the msg_bufx and msg_bufr
indices were missing.
Submitted by: Bodo Rueskamp <br@clabsms.de>
Tripped over during a kernel debugging tutorial given by: grog
Reviewed by: grog, dwmalone
MFC after: 1 week
on a vnode-backed object must be incremented *after* obtaining the vnode
lock. If it is bumped before obtaining the vnode lock we can deadlock
against vtruncbuf().
Submitted by: peter, ps
MFC after: 3 days
* Re-organise RID allocation so that we don't accidentally give a RID
to two different processes. Also randomise the order to try to reduce
collisions in VHPT and TLB. Don't allocate RIDs for regions which are
unused.
* Allocate space for VHPT based on the size of physical memory. More
tuning is needed here.
* Add sysctl instrumentation for VHPT - see sysctl vm.stats.vhpt
* Fix a bug in pmap_prefault() which prevented it from actually adding
pages to the pmap.
* Remove ancient dead debugging code.
* Add DDB commands for examining translation registers and region
registers.
The first change fixes the 'free/cache page %p was dirty' panic which I
have been seeing when the system is put under moderate load. It also
fixes the negative RSS values in ps which have been confusing me for a
while.
With this set of changes the ia64 port is reliable enough to build its
own kernels, even with a 20-way parallel build. Next stop buildworld.
access an array beyond it's length. This only happens in the last iteration of
a loop, and the value fetched is not used then, so the bug is a relatively
innocent one. Fix this by not fetching any value on the last iteration of said
loop.
Submitted by: MKI <mki@mozone.net>
MFC after: 1 week
o Bite the bullet and create controller types for the 6729 and also for
the 673x. Rename the 672x to 6722.
o Define minimal extended register info (just register 0xa for reading VS[12]).
# I think the last version may have broken 673x controllers, but this should
# fix them.
Tested on the 6722, but not the 6729.
Ideas from: Chiharu Shibata-san's article in bsd-nomads:15866
on my CL-PD6722, but won't work on the CL-PD6729. The latter two need
more sophisticated detection of 3.3V cards than I'm up to at the
moment. Also, only a few of the ISA chipsets that support 3.3V will
likely work at the moment.
It appears that for 3.3V cards we must detect them and adjust the
pwr.vcc value from 50 to 33. Give a strong hint to automatically
power up the card for PD_POWER cards.
This makes my SMC 2602W (the 3.3V version of the 2632W) work on my
Fujitsu Stylistic 500.
SMC 3.3V card donated by: Ryan Losh
Thanks to: bsd-nomads for reviews of past 3.3V code
instead of recovering, which happens in particular during a rapid series
of SIGWINCH's. This change forces nvi to loop on the call in the event
that the call is interrupted.
Interestingly, I submitted this bug report in 1998, and a solution was
posted shortly thereafter by Matthias Buelow; it's been sitting in the
PR database ever since.
Note: this takes this file off the vendor branch. If and when we find
a vendor for this code, the fix should be given back to them.
PR: bin/8438
Submitted by: Matthias Buelow <mkb@altair.mayn.de>
MFC after: 1 month
constant, just in case uint32_t turns into a `short' ten years from now.
If this is MFC'd it will be necessary to hard-code the constant since
-stable doesn't have UINT32_MAX.
src/sys/fs/fifofs/fifo_vnops.c) to serve locks better, my previous
workaround for lack of decent fifo system wasn't cutting it,
particularly the kernel would send a message down the fifo and
immediately close it, this would lead to delayed unlock requests
being seen by the lockd causing all sorts of badness.
Basically, don't reopen the fifo, just select(2) on it.
