| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Work from Theo and myself.
|
|
|
|
|
|
|
|
well (not at all) with shortages of the vm_map where the pages are mapped
(usually kmem_map).
Try to deal with it:
- group all information the backend allocator for a pool in a separate
struct. The pool will only have a pointer to that struct.
- change the pool_init API to reflect that.
- link all pools allocating from the same allocator on a linked list.
- Since an allocator is responsible to wait for physical memory it will
only fail (waitok) when it runs out of its backing vm_map, carefully
drain pools using the same allocator so that va space is freed.
(see comments in code for caveats and details).
- change pool_reclaim to return if it actually succeeded to free some
memory, use that information to make draining easier and more efficient.
- get rid of PR_URGENT, noone uses it.
|
|
|
|
|
|
|
|
|
|
headers.
|
|
|
|
* check the qualify the intr pending bits with the enable bits
* enable/disable the cs4231 IEN bit in the pin control register
* move the cs4231 (not dma) interrupt handling to the general interrupt processing
[This properly allows for sharing with, eg. magma]
|
|
64Mhz vs. the "normal" 25Mhz). This (with the cs4231 patch) makes this
board work.
|
|
(This fixes the crash in pr2212, but the magma still doesn't want to
talk to the world... looks like oscillator problems).
[Many thanks to John Baker <jdbaker@blkbox.com> for donating a MAGMA board
for testing]
|
|
|
|
|
|
|
|
|
|
machines or some configurations or in some phase of the moon (we actually
don't know when or why) files disappeared. Since we've not been able to
track down the problem in two weeks intense debugging and we need -current
to be stable, back out everything to a state it had before UBC.
We apologise for the inconvenience.
|
|
the response queue. Instead of the ad hoc ISP_SWIZZLE_REQUEST, we now have
a complete set of inline functions in isp_inline.h. Each platform is
responsible for providing just one of a set of ISP_IOX_{GET,PUT}{8,16,32}
macros.
The reason this needs to be done is that we need to have a single set of
functions that will work correctly on multiple architectures for both little
and big endian machines. It also needs to work correctly in the case that
we have the request or response queues in memory that has to be treated
specially (e.g., have ddi_dma_sync called on it for Solaris after we update
it or before we read from it).
One thing that falls out of this is that we no longer build requests in the
request queue itself. Instead, we build the request locally (e.g., on the
stack) and then as part of the swizzling operation, copy it to the request
queue entry we've allocated. I thought long and hard about whether this was
too expensive a change to make as it in a lot of cases requires an extra
copy. On balance, the flexbility is worth it. With any luck, the entry that
we build locally stays in a processor writeback cache (after all, it's only
64 bytes) so that the cost of actually flushing it to the memory area that is
the shared queue with the PCI device is not all that expensive. We may examine
this again and try to get clever in the future to try and avoid copies.
Another change that falls out of this is that MEMORYBARRIER should be taken
a lot more seriously. The macro ISP_ADD_REQUEST does a MEMORYBARRIER on the
entry being added. But there had been many other places this had been missing.
It's now very important that it be done.
For OpenSD, it does a ddi_dmamap_sync as appropriate. This gets us out of
the explicit ddi_dmamap_sync on the whole response queue that we did for SBus
cards at each interrupt. Now, because SBus/sparc doesn't use bus_dma, some
shenanigans were done to support this. But Jason was nice enough to test the
SBus/sparcv9 changes for me, and they did the right thing as well.
Set things up so that platforms that cannot have an SBus don't get a lot of
the SBus code checks (dead coded out).
Additional changes:
Fix a longstanding buglet of sorts. When we get an entry via isp_getrqentry,
the iptr value that gets returned is the value we intend to eventually plug
into the ISP registers as the entry *one past* the last one we've written-
*not* the current entry we're updating. All along we've been calling sync
functions on the wrong index value. Argh. The 'fix' here is to rename all
'iptr' variables as 'nxti' to remember that this is the 'next' pointer-
not the current pointer.
Devote a single bit to mboxbsy- and set aside bits for output mbox registers
that we need to pick up- we can have at least one command which does not
have any defined output registers (MBOX_EXECUTE_FIRMWARE).
Explicitly decode GetAllNext SNS Response back *as* a GetAllNext response.
Otherwise, we won't unswizzle it correctly.
Nuke some additional __P macros.
|
|
|
|
(sync with other arches)
|
|
|
|
|
|
(Does it show that I'm doing a binary search for a bug in a bigger diff?)
|
|
|
|
|
|
Make pv allocation non-waiting. sneak in some ansification.
|
|
|
|
|
|
misc pmap usage fixes.
|
|
|
|
|
|
|
|
|
|
that noone ever has a thought of using it again.
|
|
|
|
ourselves, don't malloc and then uncache the memory.
|
|
|
|
|
|
|
|
|
|
Add support for "raid" devices (prepare future raidframe changes).
OK deraadt@, Reviewed by drahn@, jason@, mickey@ and miod@
|
|
|
|
we use the function.
At the same time fix the pte pool backend functions to allocate and map
the memory themselves.
|
|
date: 2000/02/11 19:22:52; author: thorpej;
Add some very simple code to auto-size the kmem_map. We take the
amount of physical memory, divide it by 4, and then allow machine
dependent code to place upper and lower bounds on the size. Export
the computed value to userspace via the new "vm.nkmempages" sysctl.
NKMEMCLUSTERS is now deprecated and will generate an error if you
attempt to use it. The new option, should you choose to use it,
is called NKMEMPAGES, and two new options NKMEMPAGES_MIN and
NKMEMPAGES_MAX allow the user to configure the bounds in the kernel
config file.
|
|
Today we add a pmap argument to pmap_update() and allocate map entries for
kernel_map from kmem_map instead of using the static entries. This should
get rid of MAX_KMAPENT panics. Also some uvm_loan problems are fixed.
|
