(1) failsafe.c allows character input from the failsafe
console device. This is the early console device that is used for output before
the pmap layer is initialized.
(1) locore.S: make sure that the size of the cacheline for
dcbz is set to the default of 128 bytes. It also sets up other mode bits on
the 970. This fix allows the G5 to boot into full multi user mode using a
NFS mounted root file system.
mutex thread, thus leaving a thread sleeping on an unlocked mutex.
Reviewed by myself and Christos.
Problem reported by Arne H. Juul, arnej at pvv dot ntnu dot no,
in PR 26208. This fix represents option 1 presented in the PR.
so that apps can use this construct safely:
obj = prop_dictionary_get(dict, "value");
if (! prop_number_equals_integer(obj, 5)) {
...
}
Suggested by Iain Hibbert.
Otherwise:
./sh -c 'x=" "; for a in $x; do echo a${a}a; done'
is processed as a single empty parameter (instead of no parameters).
Should fix the breakage I introdiced in rev 1.75 and PR/34256 and PR/34254
it was initialised quite late due to its reliance on disc data the mount
process could have stopped before initialising and thus could panic again
only now for uninitialising an not initialised pool! *sigh*
---
# XXX Disable zero-copy page loaning in sosend() temporarily:
# PV mappings created by sosend_loan() in sys/kern/uipc_socket.c may
# produce virtual cache aliases and it seems to cause TLB MISS panic
# in cache flush code called from bus_dmamap_sync(9) PREWRITE ops
# during heavy TX packet traffic on tlp(4).
user supplied a bad name or anamelen parameter to accept(2).
If bad paramaters were suplied and a copyout() failed, the
struct file was cleaned up but not the associated socket. This
could leave sockets in CLOSE_WAIT that could never be closed.
the same memory block allocated as before and it bombs out on its
descriptor pool allready being initialised. It turns out that the pool was
not allways destroyed. This fix ought to clean it up whatever the cause of
the mishap that results in a reject.
From the redhat web page:
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gcc/offsetof.html
__offsetof__ (expression)
is equivalent to the parenthesized expression, except that the
expression is considered an integral constant expression even if
it contains certain operators that are not normally permitted in
an integral constant expression. Users should never use __offsetof__
directly; the only valid use of __offsetof__ is to implement the
offsetof macro in <stddef.h>.
g++-3 does not have a built-in offsetof(), but we cannot use the c version,
otherwise we break with -Wold-style-cast.
Inspired by the DF version, but a bit different.
