in the early boot phase.
Define prom_interpret() to be a simple form of the Openfirmware OF_interpret().
Re-arrange OLDMON code in prom_getidprom() to make it compile on sparc64.
previous version would easily make the low order bits oscillate between 0
and some other value.
Together with the previous change, this should make those
pmap_pinit: out of segments
panics even less likely.
We should really attempt a systematic search before panic()ing at the end.
This should fix PR #24754, as well as many of the hangs and process
aborts reported on port-macppc@ in the last weeks.
This error would cause the pmap's vsid never to be freed, and would
occasionnally free a valid vsid used by another pmap, sometimes the kernel's.
. add a related KASSERT() to avoid regression
abstracted by itry, ithrow, icatch et.al. macros
there is problem with these in stack setup for FreeBSD/ia64 at least,
and in general the rewritten explicit code is slighly more optimal
and smaller in size
the NetBSD code change is somewhat different to what was done in FreeBSD,
to improve readability of the code
the owner of the mount point (or user specified via -u); this is necessary
to succeed the permission check in the kernel SMB share code
owner setting via -O would still apply, but it's now not necessary when
doing non-root mount
enable the check for cloned /dev/nsmb, to simplify eventual future switch
to cloned /dev/nsmb device
use compile time string concatenation for one constant string
If raidPtr->numFailures isn't initialized properly, then all sorts of
whacky things can happen, including incorrect DAGs being generated.
(Triggering this problem is a little esoteric, which is why this bug has
been in hiding for so long -- I only saw it after rebooting with a
degraded RAID 5 set that was autoconfigured, rebuilding the failed
componennt, and then failing the component while IO was happening to
the RAID set.)
returning a failure code and processing that all the way up the stack.
- deal with a dead peer similarly and do it without setjmp/longjmp() (at
christos' request).
These fix bin/20304 and my own observations when the remote abruptly closes
the connection.
