PPP: drop SPPP lock before calling rt_ifmsg
rt_ifmsg will lock SPPP itself, so ensure it's unlocked before calling.
Add a comment to explain why this should be safe.
Thanks to @riastradh for review and commentary.
Fixes PR kern/59963.
properly mask the "number of arguments" word to avoid invalid output.
i had a system soft-hang with cc1plus waiting for memory, but there
is enough memory free now, but when i tried to "bt/a <cc1plus addr>"
i was getting an extremely large output (several megabytes before i
killed simh).
we fetch the argument count from a 32-bit space in the stack frame,
but it's only the bottom byte that matters, the other bytes should
always be zero for netbsd, as they're used by VMS.
mask the high bytes of this value before consuming it.
also, since we don't expect to see them, simply give up when we find
a "callg" instruction. i did attempt to handle this, but since they
should not be present, and seeing one would indicate that an unexpected
stack write to that bit, handling it just leads to more faults as they
vax_ap pointer does not point to valid memory and triggers crash (ie,
back to db> prompt.)
properly mask the "number of arguments" word to avoid invalid output.
i had a system soft-hang with cc1plus waiting for memory, but there
is enough memory free now, but when i tried to "bt/a <cc1plus addr>"
i was getting an extremely large output (several megabytes before i
killed simh).
we fetch the argument count from a 32-bit space in the stack frame,
but it's only the bottom byte that matters, the other bytes should
always be zero for netbsd, as they're used by VMS.
mask the high bytes of this value before consuming it.
also, since we don't expect to see them, simply give up when we find
a "callg" instruction. i did attempt to handle this, but since they
should not be present, and seeing one would indicate that an unexpected
stack write to that bit, handling it just leads to more faults as they
vax_ap pointer does not point to valid memory and triggers crash (ie,
back to db> prompt.)
fix gffb_putchar_mono():
- don't use the glyph cache - it doesn't buy us anything when drawing mono
characters and it can't deal with WSATTR_HILIT
- gffb_sync() before drawing characters - turns out we can overrun the command
buffer with this, which leads to occasional lockups. No measurable loss of
speed.
Appease clang not liking ","+len:
error: adding 'size_t' (aka 'unsigned long') to a string does not append
to the string [-Werror,-Wstring-plus-int]
note: use array indexing to silence this warning
Enable the standard set of USB devices from usbdevices.config in
macppc/conf/POWERMAC_G5, like they are in macppc/conf/GENERIC.
Discussed on port-macppc.
bin/59861 fix ccdconfig -g (and much more)
This change is (roughly) based upon the patch provided in the PR by
ssszcmawo at gmail, but with many changes, and additions.
First, make ccdconfig -g not include the ccd size in its output.
It is supposed to produce the format defined for the config file,
so a ccd can be manually configured, and then the entry for it
added to /etc/ccd.conf later so it will be configured again at
each reboot. The size is computed based upon the devices,
it is not an input parameter, and hence does not belong in the output.
Nevertheless, being able to observe the size is useful for understanding
the ccd, so add a new -p option which does include the size in its output.
While here, add an option (-h) allow the size to be output in the form
generated by humanize_number(3) for better human comprehension.
[41 lines not shown]
Make the optional flags for ccdconfig truly optional.
The usage message, and the man page synopsis, has always
said:
usage: ccdconfig [-cv] ccd ileave [flags] dev [...]
(plus the other variants not material here). That is, the "flags"
can be omitted.
And they could, as implemented, but only when there are (not counting
the -c/-v options) exactly 3 args.
That is:
ccdconfig ccd0 32 dev
would work, with dev being the (sole) device, rather than treated
as flags. In any other case (like, more than one dev, which is
[23 lines not shown]
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.
