zfs: add zfs_range_lock_try
i plan to use this to fix pgdaemon deadlock issue. (PR/60004)
(thus i didn't bother to implement RL_READER.)
note: recent openzfs has a similar function. (zfs_rangelock_tryenter)
this commit ought to be reverted when/if we switch to it.
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=60004
apei_hest: fix a zero-sized kmem_zalloc issue
zero-sized kmem_zalloc is illigal.
this fixes a crash seen on HP Z4 G4.
when installing netbsd 10.1 on the machine, i had to
work this around by "userconf disable apei" and
```
userconf=disable apei*
```
in boot.cfg.
"acpidump -dt" on the machine said:
```
Error Source Count=0
```
under the "HEST:" section.
[13 lines not shown]
pchtemp: add a simple driver for intel pch thermal sensor
tested on PCI_PRODUCT_INTEL_2HS_THERM, which was found on HP Z4 G4.
although other variants look compatible, i have not actually tested them.
(no hardware)
dmesg:
```
[ 512.596379] pchtemp0 at pci0 dev 20 function 2: Intel PCH Temperature Sensor
```
envstat:
```
[pchtemp0]
pchtemp0 temperature: 41.500 degC
```
enable in kernel configs where amdtemp is enabled.
the man page is mostly copy-and-paste from amdtemp.4.
Added restrict to SYNOPSIS for strtok_r(), and fix broken example.
strtok_r() (and strtok() which already had it here) gained "restrict"
for their params in ISO C 99 (and then in Posix 2001).
The example code worked for the particular example given (the input
data actually used) but was hopelessly broken in general. As part
of that (but not the actual breakage), if something defines MAXTOKENS
then allow that many tokens, not one less ... add an extra slot for
the terminating NULL.
While here, update the STANDARDS section a little.
Added "restrict" to args in declaration of strtok_r()
The "restrict" was included in strtok_r() in C99 and POSIX Issue 6 (2001).
(The same time it was added to strtok()).
strtok_r() actually dates from Posix I5 (1995), not I6 (2001) as the
guard on its definition states, but after all this time, clearly no-one
cares about that.
t_fpclassify: Show the floating-point bits more carefully.
Use formatbits(&f) rather than formatbits(f). This serves two
purposes:
1. Type-checking.
Can't accidentally pass a double where a float is needed -- a bug
that previously appeared a few times in this code.
2. Reducing the chance that the data will pass through floating-point
load/store instructions on x87.
Floating-point load of binary32 (float) or binary64 (double)
converts to x87 80-bit extended precision format internally, which
preserves all floating-point _numbers_ and _infinities_ but has
the side effect of changing signalling NaN to quiet NaN (and
raising FE_INVALID). This means that signalling NaNs were getting
wrongly printed _as if_ they were quiet NaNs, which is frustrating
[4 lines not shown]
More cleanups and simplifications (more of the previous).
In particular, there is no need to say "using the swapctl(2)
system call", the SEE ALSO to that page should make that clear
enough to anyone who actually cares, which is not required of
a user of swapctl(8).
Minor other changes (a few grammar cleanups), and one new
BUGS entry added (should have been there for ages now).
swapctl(8): edit to g/c ornate verbosity
In a typical
-x The -x option is used to cause swapctl to frob.
description the relevant bits of information are 1) "-x" and 2)
"frob", so just make it say:
-x Frob.
The pleonastic repetitions just get in the way. The effect is
cumulative and by the second page it makes you want to bang your head
against the wall and not in a good way.
Take 2 on attempted build fix.
The issue seems to be the
#define makequietsignallingl makequietsignalling
which happens when ! defined(__HAVE_LONG_DOUBLE)
That worked before as
long double f = makequietsignalling(...);
(effectively) just did a type conversion from double to long double
(which might be a no-op, but is still a type conversion) and so was
OK.
But the new method
makequietsignalling(&ldvar, ...)
[10 lines not shown]
