process is on the alternate stack or not. For compatibility
with sigstack(2) state is being updated if such is needed.
We now determine whether the process is on the alternate
stack by looking at its stack pointer. This allows a process
to siglongjmp from a signal handler on the alternate stack
to the place of the sigsetjmp on the normal stack. When
maintaining state, this would have invalidated the state
information and causing a subsequent signal to be delivered
on the normal stack instead of the alternate stack.
PR: 22286
-current and RELENG_4 with GENERIC.
NKPT is the number of initial bootstrap page table pages we create for
the kernel during startup. Once VM is up, we resize it as needed, but
with 4G ram, the size of the vm_page_t structures was pushing it over
the limit. The fact that trimmed down kernels boot on 4G ram machines
suggests that we were pretty close to the edge.
The "30" is arbitary, but smaller than the 'nkpt' variable on all
machines that I checked.
- Use a better test for determining when a process is running.
- Convert some checks to assertions.
- Remove unnecessary tests.
- Save the priority before acquiring a mutex rather than in msleep(9).
4) The cardbus CIS code treats the CIS_PTR as a mapping register if
it is mentioned in the CIS. I don't have a spec handy to understand
why the CIS_PTR is mentioned in the CIS, but allocating a memory range
for it is certainly bogus. My patch ignores bar #6 to prevent the
mapping.
[The pccard spec says that BAR 0 and 7 (-1 and 6 in thic case since we
did a minus one) is "reserved". The off by 1 error has been fixed.
also bar=5 is invalid for IO maps, so we check it.]
5) The CIS code allocated duplicate resources to those already found
by cardbus_add_resources(). The fix is to pass in the bar computed
from the CIS instead of the particular resource ID for that bar,
so bus_generic_alloc_resource succeeds in finding the old resource.
[fixed, also removed superfluous (and incorrect) writing back to the
PCI config space.]
7) The CIS code seems to use the wrong bit to determine rather a particular
register mapping is for I/O or memory space. From looking at the
two cards I have, it seems TPL_BAR_REG_AS should be 0x10 instead
of 0x08. Otherwise, all registers that should be I/O mapped gain
a second mapping in memory space.
[Oops, the spec does say 0x10..., fixed]
Submitted by: Justin Gibbs
work right when the administrator has modified their runtime environment
in a manner not anticipated by our script.
Requested by: Tom Maher <tardis@ece.cmu.edu>
Providing shell scripts that do nothing but load a similarly named
kernel loadable module in out of vogue.
There is no ibcs2(4) manual page, and I haven't managed to coax
anyone into contributing one based on the linux(4) manual page.
our kernel module system learned how to handle dependencies.
Providing a whole bunch of shell scripts that do nothing but load
a similarly named kernel loadable module is out of vogue.
The svr4(8) manual page has been replaced with a much better svr4(4)
page.
