amount of kvm used for buffers was set at 70%, some 188M. Then
the total amount of kvm became 1G, and the amount for buffers
thus became some 716M. This is really too much, and some
device drivers want to map quite a bit of kvm these days.
So, cap it at 384M, which gives each buffer a little over 8k (the
default FFS blocksize) physical in an 1G physram configuration.
support it in the kernel yet. If we don't do this, GDB arbitrarily
assumes we wanted it to be 9, which is silly.
In the kernel, leave it undefined so that sys_process.c doesn't
generate code for it.
the instruction we used with GDB 4.x. The new instruction has the advantage
of fitting the pattern that ARM recommend using for instructions that need to
stay undefined.
(eg ARM920), the mode in which the processor operates is governed by
the use of both the PT_C and PT_B bits:
PT_C=1,PT_B=1 -> Write-back
PT_C=1,PT_B=0 -> Write-through
To support this define pte_cache_mode (initialized to PT_C|PT_B) and
use that when enabling cacheing for a page.
to allocate a L1 pt is often enough to bring the system to its knees:
so make the messages PDEBUG(0,...).
However, even with this step having more than a small number of
processes searching for a L1 pt can still be enough to bring the system
down, since they all run at high priority and sleep for very little time,
thus blocking out user code from completing. So implement an exponential
backoff when waiting for a page table, so that we don't hog the CPU when
memory is scarce.
Tested by running a make of the C compiler with "gnumake -j30" (and plenty
of swap space).
is shared with another process (as can happen if vfork is being used),
then that other process will end up not having a page 0, which is bad
news indeed, since then there is no way back into the kernel.
Found this using a multi-ice box, so they are useful after all!
This seems to fix pr port-arm32/11921 and (possibly) kern/9859.
string, if present, will override the second argument (which may be the
path/kernel being loaded). This will provide a way to netboot the kernel
and allow the root device be set to a disk partition.
line parameters, and device_register() to try to match the boot device. Works
on a Challenge S (and similar machines), but will need more work for other
SCSI adapters.
and RC7500 from the old arch/arm32 that is gonna be deleted in its whole
soon.
IMPORTANT for RC7500 ... this also removes all RC7500 support .... its a
big pitty but was virtually unsupported allready for a few years and noone
had one... if someone wants to make RC7500 or decendants support undo this
removal and start from here.
arch/arm/iomd/* .... the RC7500 isnt really an iomd/vidc machine but has
different video/audio chip and was kind of hardwired/hacked into the other
chip drivers.
If __PCI_DEV_FUNCORDER is defined, don't do the song-and-dance to check if
a device is multi-function; machdep code is going to tell us exactly which
functions to probe.
Note this required changing how pci_func_devorder() works in the
sparc64 PCI machdep code; now the "curnode" is assumed to point
to the bus, rather than some function (typically 0) on the device,
just as pci_bus_devorder() makes that assumption.
All this should allow the PCI code to actually locate the second
HME device on a Sun Netra t1, which is at 3,1 -- previously, the
PCI code would have missed it because there is no device at 3,0.
(Sun deserves a brick to the head for this one -- this seems clearly
out of line with the PCI spec.)
