cpuctl(8): update Transmeta identification for Efficeon (TM8000 series).
It uses family 15 and it has a new way to decode processor revision, so update
family > 6 default to "Efficeon" and call transmeta_cpu_info() for it.
Decode processor revision from leaf leaf 0x80860002 EAX
when leaf 0x80860001 EBX contains 0x02000000.
Untested on the actual hardware (I don't have one).
Verified by the CPUID dump available online.
PR port-mips/60780 UBSan: long int << fix (src/common/lib/libc/string/memset2.c)
The comments say that memword_t is intended to be unsigned, but
presume that __register_t will provide that attribute. It usually
doesn't, so we need an unsigned type for building the fill value.
Thanks to Alexander Schreiber for running the UBSan built system
and reporting this (and others), and hopefully, in advance for
testing that this one is now fixed.
XXX - pullup -11 -10 (probably, it cannot possibly hurt)
End libc Makefile .${PARSEDIR} abuse
It is pointless assigning ${.PARSEDIR) to a variable using '='
as when that variable is later expanded, ${.PARSEDIR} will not
have a value, and we end up with things like:
.... -I. -I/home/source/ab/HEAD/src/lib/libc/arch/mips/softfloat
-I -DSOFTFLOAT_FOR_GCC
-I/home/source/ab/HEAD/src/lib/libc/arch/mips/softfloat
-I -DSOFTFLOAT_FOR_GCC
-DSOFTFLOAT -I/home/source/ab/HEAD/src/sys ....
That exxtracted from a failing command from the autobuilds (which I
first saw on my local system attempting a mips64eb build). That is
all part of one (long) command line from which I extracted that piece
(and then manually line wrapped it for this log message).
Note the 2nd and 4 lines ... those are meant to have ${.PARSEDIR}
between the -I and -D (I doubt there is a "./-DSOFTFLOAT_FOR_GCC"
[12 lines not shown]
gtmr: simplify the checking of the parent device properties.
The code still looks for the "physical" property on the device and the
parent device, but it's more obvious now.
Fix a whitespace issue in the process.
etc/etc.evbarm/Makefile.inc: follow-on hash generation fix
Revs. 141 & 142 introduced a guard that tried to prevent checksum
consolidation from running in contexts where there's nothing to process
-- that is, images aren't created at all. However, it then also
prevented clean builds that do include images from consolidating their
checksums as intended, since the "exists" check that was added reflects
too early a file system state on clean builds ("gzimg" doesn't exist
yet). It also didn't address the fact that there can be targets that
do in fact create and populate a "gzimg" directory, yet don't actually
generate any images as presently construed/defined are relevant for
hash generation, as happens with the evbearmv4-el arch.
Another fix for PR install/59195. Tested with earmv5hf (no images, no
"gzimg" directory created), evbearmv4-el (no images, "gzimg" directory
is created), and aarch64 (images and "gzimg" directory are created),
with clean builds into new directory structures and subsequent update
builds tested for each arch.
Prefer using ${.PARSEDIR} over assuming that ${.CURDIR} is src/lib/libc.
Mostly this changes ${.CURDIR} refs into either ${.PARSEDIR}, ${LIBCDIR},
or ${NETBSDSRCDIR} refs.
Set LIBCDIR earlier to ensure it's available always.
This will be used to build a smaller libc (eg, with no assert strings.)
Tested builds on atari, x86-64, arm64, and vax.
Yet another printf format fix...
Use PRI[diuoxX]PTR for [u]intptr_t types rather than PRId64.
Pointers (and hence [u]intptr_t's) are not 64 bits in ILP32 systems.
I picked 'x', well, just because ...
And this time I verified it builds on i386!
Fix wacky printf usage - hopefully unbreak 32 bit builds
Rather than converting an int type to a (void *) and then
printing using %p (one presumes to obtain hex), use the PRIx64
(the value is int64_t) macro (just like previous output lines do)
instead. (Use the '#' printf flag as well, to get the 0x when
needed, and just 0 if the value is 0).
As it was, 32 bit builds would complain about converting between
a pointer and an integer of a different size - converting it to
intptr_t before void * would have fixed that, but would lose the
top 32 bits of the value on 32 bit systems.
kqueue/kernel/t_pipe: Fix newly failing test.
If the read side of a pipe has been closed, then for the write side:
- poll will set POLLOUT, not POLLNVAL (nor fail with EBADF), and
- select will report writable, not fail with EBADF,
because the write side is immediately writable and will fail with
EPIPE/SIGPIPE -- it won't block if you try to write.
So surely kqueue with EVFILT_WRITE should simply report immediately
writable too, not fail with EBADF. And that is what I caused to
happen by simplifying and clarifying the code and fixing various edge
cases. (The bad response that this test was added to check is a
kernel crash on null pointer dereference; that, fortunately, has not
regressed.)
PR kern/59056: poll POLLHUP bugs
pipe(2): Don't cv_wait_sig in a loop without breaking on signal.
If a signal does arrive, it will turn into a busy wait! Not helpful.
But this wait should be limited to scheduling delays for other
threads anyway, not for general I/O, so there's no need to be
interruptible by a signal.
Prompted by:
PR kern/59056: poll POLLHUP bugs
pipe(2): Restructure select/poll/kqueue records.
1. When a thread is waiting on an endpoint of a pipe, have it wait on
_that endpoint_ (i.e., cv_wait or selrecord), not on the other
endpoint sometimes depending on the direction of the I/O.
2. Make poll(2) on the writer side of a pipe wake with POLLERR when
the reader side is closed, because write would return immediately,
and fail with EPIPE/SIGPIPE. See also:
https://mail-index.NetBSD.org/tech-kern/2026/09/21/msg031255.html
(In contrast, for the other way around, when the writer side of a
pipe is closed, poll(2) on the reader is already defined to wake
with POLLHUP, and while read would return immediately, it will not
_fail_; it will simply report EOF, so there is no justification
for POLLERR in that direction.)
3. For EVFILT_READ, require the reader side of a pipe; likewise, for
[6 lines not shown]
pipe(2): Simplify PIPE_RESTART handling.
Now that it applies to each side independently, we can just make it
final, because new I/O operations are not allowed on an file that has
had its .fo_restart called. Makes reasoning about all this easier.
XXX Consider renaming PIPE_RESTART to PIPE_CLOSING: the .fo_restart
operation means the file is irreversibly destined to be closed soon
and just needs any pending I/O on it to be interrupted and fail
promptly so we can finally close the file.
Preparation for:
PR kern/59056: poll POLLHUP bugs
pipe(2): Make pipe sides a little more symmetric.
1. When reading from or writing to a pipe, busy _this side_ of the
pipe, not the other side.
2. In pipeclose, all operations on _this side_ of the pipe have already
quiesced. But operations on the other side may not have. So wait
for the _other side_ to be unbusied before disconnecting the peer
(changing ppipe->pipe_peer from pipe to NULL).
With (1) and (2) we can prove a simple property that makes reasoning
about this code easier: If a pipe is busy, its peer pointer is stable
even across cv_wait on the pipe lock. Without these changes I'm not
sure I could prove that property (though I haven't exhibited a
reproducer for any issues arising from its failure).
3. Make write wait on wpipe->pipe_wcv, and make read wait on
rpipe->pipe_rcv, consistently, so that any waiters on one side of a
pipe will always be waiting on one of _that side's_ condvars.
[17 lines not shown]
pipe(2): Fix wakeup of pending writers on close of write side.
The job of pipe_restart is to wake any pending I/O operations on the
file when it is about to be closed. New references cannot be taken
for new I/O operations; once all existing references are drained, the
system calls pipe_close.
What pipe_restart did was to wake pipe->pipe_rcv and pipe->pipe_wcv.
But the condvars of _which pipe_?
After renaming the variables to match reality, it becomes clear that
wpipe->pipe_wcv and wpipe->pipe_rcv are never used -- instead,
pipe_read waits for rpipe->pipe_rcv, and pipe_write waits for
rpipe->pipe_wcv. So pipe_restart on the write side of a pipe woke
wpipe->pipe_rcv and wpipe->pipe_wcv, which nothing was waiting for,
and failed to wake rpipe->pipe_rcv or rpipe->pipe_wcv.
(Perhaps we should just have a single struct pipe::pipe_cv member,
and have pipe_read use rpipe->pipe_cv and pipe_write use
[4 lines not shown]
pipe(2): Split new function pipefree out of pipeclose.
Makes it easier to reason about pipeclose this way.
Prompted by:
PR kern/59056: poll POLLHUP bugs
