> I wonder if the diff below makes a difference. It's hard to debug and it
> might be worth adding a counter for bad swap slots.
It did not help (but your diff is probably correct).
> Index: uvm/uvm_anon.c
> ===
> RCS file: /cvs/src
> On 21/10/23(Sat) 14:28, Miod Vallat wrote:
> > > Stuart, Miod, I wonder if this also help for the off-by-one issue you
> > > are seeing. It might not.
> >
> > It makes the aforementioned issue disappear on the affected machine.
>
> Thanks at lot for te
> Stuart, Miod, I wonder if this also help for the off-by-one issue you
> are seeing. It might not.
It makes the aforementioned issue disappear on the affected machine.
> Comments, ok?
> diff --git sys/uvm/uvm_pdaemon.c sys/uvm/uvm_pdaemon.c
> index 284211d226c..a26a776df67 100644
> --- sys/uvm
I had the misfortune of hitting a KASSERT in dwge:
panic: kernel diagnostic assertion "len > 0" failed: file "/usr/src/sys/dev/fdt
/if_dwge.c", line 1102
Stopped at panic+0x106:addia0,zero,256TIDPIDUID PR
FLAGS PFLAGS CPU COMMAND
*405136 98879 1500 0x3
> lines 195 and 196. Now my question, does this not sorta look wrong?
>
> Shouldn't these values be a little more unique? As in not the same?
No, these are correct. These lines are used when the compiler does not
support __predict_false and __predict_true, so __predict_whaterver(x)
has to behav
> CC'ed back the mailing list.
Oops, I thought I had replied to the list as well, my bad.
> Tested your patch. It works on my Chromebook.
Excellent. It's in!
Thanks,
Miod
> On Sat, Aug 12, 2023 at 02:27:13PM +0000, Miod Vallat wrote:
> > Third time's (hopefully) the charm. How about that diff? Too much things
> > have been removed in uwacom.
>
> partial success! The wacom driver is recognized, no panics this time. But
> the input is
Third time's (hopefully) the charm. How about that diff? Too much things
have been removed in uwacom.
Index: dev/hid/hid.c
===
RCS file: /OpenBSD/src/sys/dev/hid/hid.c,v
retrieving revision 1.5
diff -u -p -r1.5 hid.c
--- dev/hid/hid.c
> On Sat, Aug 12, 2023 at 08:00:48AM +0000, Miod Vallat wrote:
> > I have had a look at your diff and I think it's decent enough to go in
> > after some polishing.
> >
> > Can Wacom tablet users try this cleaned up diff?
>
> Hi,
>
> My WACOM table
I have had a look at your diff and I think it's decent enough to go in
after some polishing.
Can Wacom tablet users try this cleaned up diff?
Index: dev/hid/hid.c
===
RCS file: /OpenBSD/src/sys/dev/hid/hid.c,v
retrieving revision 1.5
> On, at least, some Chromebook PS/2 protocol is implemented by EC rather
> than a real PS/2 controller. It works fine except for 2 things:
> * Unusual layout like multimedia keys instead of F*
> * Reset command returns garbage (usually last key)
> This patch attempts to handle later as it stops ke
> Now that we have request_sleep() we can add a new internal KS_Cmd_Sleep
> keycode, map it into the macbook keyboard, catch in wskbd and go to sleep.
>
> ok?
> --- sys/dev/usb/ukbdmap.c
> +++ sys/dev/usb/ukbdmap.c
> @@ -176,6 +176,7 @@ static const keysym_t ukbd_keydesc_us[] = {
> KC(127),
> Good Day,
>
> https://uk.dynabook.com/discontinued-products/pa3542e-2prp/
>
> one more device with old (probably DL-160, but unsure so leaving
> DLUNK) DisplayLink chip. works ok.
Patch applied, thanks!
Miod
After suspending a machine with acpithinkpad(4) and resuming, the fan
senors report a value of 65535 (i.e. 0x) for a few seconds, and
then start reporting correct values.
The following diff marks the sensor as invalid when such a value is
read.
Index: acpithinkpad.c
==
> I'm fine with removing this. Just wonder if this was ever implemented
> for one of the architectures that we no longer support and whether
> there was any effect on performance.
Nope, never implemented anywhere. If you want to see a pmap_copy()
implementation, look at FreeBSD.
pmap_copy() is an optional pmap interface which has never been
implemented. In pure Mary Kondo style, we should thank it for the joy it
brought to CSRG people, and move it to the recycling bin - it's not
going to be implemented anytime soon.
Index: share/man/man9/pmap.9
===
pci_{io,mem}_find() have intentionally been left undocumented,
developers being (rightfully) advised to use pci_mapreg_info() instead.
The following diff removes these undocumented functions and converts
their last few users.
Bonus changes introduced while looking into this:
- correctly cope with
> The last times the attribute names were updated were 14 and 21 years ago.
> Modern drives, especially SSDs, get a lot of Unknown columns from the
> 'readattr' command.
>
> Attributes were coalesced from smartmontools, NetBSD's atactl, and
> Wikipedia's citations. Manufacturer-specific attribu
> Currently it is not possible to use unicode codepoints > 0xFF on the console,
> because our UTF-8 decoding logic is badly broken.
>
> The code in question is in wsemul_subr.c, wsemul_getchar().
>
> The problem is that we calculate the number of bytes in a multi-byte
> sequence by just looking a
> Does this actually change something on any of our architectures?
This gets rid of warnings such as:
/usr/src/lib/libexpat/lib/xmlparse.c: In function 'accountingReportDiff':
/usr/src/lib/libexpat/lib/xmlparse.c:7704: warning: format '%6d' expects
type 'int', but argument 3 has type 'ptrdiff_t'
libexpat assumes the compiler might not know of the C99 format
specifiers for ptrdiff_t and size_t, and tries to guess alternative
format strings.
The following diff relieves it of this misery (but can't be sent
upѕtream, as it is too aggressive).
Index: lib/internal.h
===
> Here are a few more instances of KASSERT being placed in an #ifdef DIAGNOSTIC
> block. This is redundant, as KASSERT is already a nop if DIAGNOSTIC is not
> defined.
Yes and no. You are right that KASSERT is a nop on non-DIAGNOSTIC
kernels, but there are sometimes good reasons to keep a single
tl;dr: if you have a sparc64 machine, please try this diff and report if
your system no longer works with it.
On sparc64, the kernel keeps the existing OpenFirmware memory mappings
into the kernel pmap, so as to be able to use ofw routines and walk the
device tree.
However, these transla
> I'm not sure which way to go: either sprinkle some -fno-common between
> crunchgen and distrib/special/Makefile.inc, or drop -dc on lld archs
> only. What would you folks prefer?
I'd rather have the same behaviour for all platforms, but I need to test
a few more gcc platforms first.
You need this extra chunk for your diff to work. With that, the built
instbin binary appears to behave as expected on hppa.
Index: distrib/special/Makefile.inc
===
RCS file: /OpenBSD/src/distrib/special/Makefile.inc,v
retrieving revis
> IIUC this ld(1) behavior is somewhat similar to -fno-common for cc(1).
> base-clang already does -fno-common by default, base-gcc does not. The
> diff below replaces ld -dc by cc -fno-common, but TBF I'm not sure what
> we're trying to achieve (avoid?) here. A test (make build + release) on
> a
> > In other words,
> > copystr(src, dst, dstsiz, len)
> > is equivalent to:
> > if (strlcpy(dst, src, dstsiz) >= dstsiz)
> > return ENAMETOOLONG;
> > if (len != NULL)
> > *len = strlen(dst);
>
> This should be *len = strlen(dst)+1 as copystr includes the termin
With the introduction of the PMAP_PREFER_{ALIGN,OFFSET} macros a long
time ago, there are actually no more uses of the PMAP_PREFER macro left
in the kernel.
The following diff removes PMAP_PREFER() but keeps a simple #define for
it to let uvm knows the PMAP_PREFER_{ALIGN,OFFSET} macros are availab
Ho ho ho,
copystr(9) is a very old and seldom used kernel function, which
performs a bounded string copy and optionally returns the length of the
copied string.
In other words,
copystr(src, dst, dstsiz, len)
is equivalent to:
if (strlcpy(dst, src, dstsiz) >= dstsiz)
> Here is a diff. Maybe bluhm@ can try this on the macppc machine that
> triggered the original "vref used where vget required" problem?
On a similar machine it panics after a few hours with:
panic: uvn_flush: PGO_SYNCIO return 'try again' error (impossible)
The trace (transcribed by hand) is
u
I'm a bit late to the thread, but whatever its outcome, things have to
work correctly on older sparc64 hardware, where the default behaviour
for on-board and Sun-branded expansion card interfaces is to use the
same MAC address.
This hints that hostname. should have priority over
hoshname. for the
> This actually breaks my machine. malloc() is saying allocation too
> large. OF_getproplen will return -1 on that. Is it possible that
> len is treated as uint64_t as it is an int and sizeof is effectively
> uint64_t?
Ah, yes; size_t is unsigned and wider than int on 64-bit platforms,
therefor
The following diff removes the last mentions of the sun4 old style
eeprom behaviour in the eeprom(8) manual page, as well as options
specific to it.
Index: eeprom.8
===
RCS file: /OpenBSD/src/usr.sbin/eeprom/eeprom.8,v
retrieving revi
> This patch switches sparc64 to clockintr(9).
[...]
> Testing on the UltraSPARC IIe ("Hummingbird") would also be helpful.
> Apparently it has %SYS_TICK and %SYS_TICK_COMPARE, but in an unusual
> hardware configuration. I imagine this machine is a bit rare, though.
All Sun Blade 100 and 150 ar
> +.if (${COMPILER_VERSION:L} != "clang" && ! exists(/usr/local/bin/eg++))
> +regress:
> + @echo 'Run "pkg_add g++" to run unittests on GCC architectures'
> + @echo SKIPPED
Or the C++ test could be downgraded to C++98 so that it may be used on
all supported platforms:
Index: utils_unittes
> Found that the reason is that 'sc_apple_fn' inside 'ukbd_softc' is not
> being assigned to
> newly created 'sc_fn' inside 'hidkbd'
Argh, sorry about that.
Does the following diff fix the problem on your machine?
Index: ukbd.c
===
> I've also removed the hidkbd_apple_mba_iso_munge() function as it is
> the same as hidkbd_apple_iso_munge() so this also cleans up the switch
> in ukbd.c
Oh no, it isn't.
See, you are in a maze of twisty little functions, all alike.
The current state of ukbd has four apple munge routines:
- "
> rev3:
Almost there! Minor nits below, then ok.
> Index: dev/hid/hidkbd.c
> +static const struct hidkbd_translation apple_iso_trans[] = {
> + { 53, 100 },/* less -> grave */
> + { 100, 53 }
> +};
> +
> +static const struct hidkbd_translation apple_iso_mba_trans[] = {
> + { 53, 1
> On 16/09/22 12:20 +0000, Miod Vallat wrote:
> > > Index: dev/hid/hidkbdtrans.h
> >
> > > +static const struct hidkbd_translation apple_fn_trans[] = {
> >
> > No effing way. Every file including this header will embed its own copy
> > of these tab
> Index: dev/hid/hidkbdtrans.h
> +static const struct hidkbd_translation apple_fn_trans[] = {
No effing way. Every file including this header will embed its own copy
of these tables.
Better keep the tables in their original locations. The munge interfaces
already take a pointer to a table and it
> Hey,
>
> the diff below adds FN key combos for Page Up, Page Down and some more
> on the M2 keyboard. Most of the logic was copied from ukbd.
This means most of the munging logic should move from ukbd into hidkbd,
but that can be done later.
If you don't want to do this yet, you need to addre
When the kernel is low on memory, the pagedaemon thread will try various
strategies to free memory.
One of those is to ask the pmap layer to free some memory. This is done
in uvm_swapout_threads(), which is roughly a wrapper around the
invocation of pmap_collect() on behalf of all processes.
Howe
Constify nam2blk[] and chrtoblktbl[], these are never modified at
runtime. Plus an octeon bonus: devmap[].
Index: sys/arch/alpha/alpha/autoconf.c
===
RCS file: /OpenBSD/src/sys/arch/alpha/alpha/autoconf.c,v
retrieving revision 1.38
di
The general policy in OpenBSD is to not embed ident(1) strings in
libraries. However, libelf is currently compiled with ident strings, and
thus /usr/lib/libelf* are the only files in /usr/lib sporting ident
strings.
The following diff disables them.
Index: _elftc.h
===
> So we would get rid of all the 32-bit compat stuff from arch/sparc64?
Yes, but this has never been used, so no worries about it.
> Index: include/cpu.h
> ===
> RCS file: /cvs/src/sys/arch/sparc64/include/cpu.h,v
> retrieving revisi
> What's the status on this diff?
I'm waiting for review from at least one of the softraid suspects prior
to putting this in, in case there are further cinematics to address.
> > The ability to be able to read the manual pages from the binaries
> > themselves, when running is interactive mode, is an intentional feature
> > and the reason they embed a gzipped version of the formatted manpage.
>
> Even in the installer?
Especially in the installer, because you might not
> Well, something tells me the inclusion of the manual pages for fdisk
> and disklabel is deliberate. Makes some sense as these are complex
> utilities and their interactive use is documented in those pages.
The ability to be able to read the manual pages from the binaries
themselves, when runnin
> After about 92 hours, one machine showed cp0_raise_calls=622486 and
> another 695892. cp0_raise_miss was zero on both of them. On two other
> machines I had forgotten to allow ddb access from console and could
> not check the values.
Put kern.allowkmem=1 in /etc/sysctl.conf, and then you can do
> What is the result if root runs disklabel, and forces it to all zeros?
If the root duid is all zeroes, then the only way to refer to the root
disk is to use its /dev/{s,w}d* device name, as zero duids are ignored.
If you set a zero duid in disklabel(8), setdisklabel() in the kernel
will compute
Come to think further about it, I think it is better for diskmap to
always trust disk drivers to either :
- not have any label (dk_label == NULL, or points to zeroed memory)
or
- have a valid label (duid is not zeroes).
The following diff thus relaxes the logic to always trust
dk_label->d_uid, unl
> after a prompt from stsp@ and florian@, reporting that newfs_msdos
> fails when given an $duid.i argument, I set down to see what could be
> going on. My test using an USB stick failed to reprdouce the problem.
> Then I started using a vnd, and that shows the issue (once in a
> while). The feelin
The alpha part contains code in the kernel to handle unaligned memory
accesses from userland programs, to prevent them from dying in horrible
SIGBUS.
This made sense in the '90s, but since then people have learned to work
with strict-alignment architectures, and this code has been less and
less tr
> Other platforms (architectures?) (powerpc, powerpc64, arm64, riscv64)
> multiplex their singular interrupt clock to schedule both a
> fixed-period hardclock and a pseudorandom statclock.
>
> This is the direction I intend to take every platform, mips64
> included, after the next release.
>
> In
> Do those machines not have Coprocessor 0? If they do, why would you
> prefer glxclk over CP0?
cop0 only provides one timer, from which both the scheduling clock and
statclk are derived. glxclk allows two timers to be used, and thus can
provide a more reliable statclk (see the Torek paper, etc -
Following the switch to ypconnect(), several fields in the dom_binding
struct used internally are no longer needed. The following diff removes
them.
Index: yp/ypinternal.h
===
RCS file: /OpenBSD/src/lib/libc/yp/ypinternal.h,v
retrievi
When the fdt does not provide a list of brightness states, pwmbl(4)
builds a 256 state ramp (i.e. state[i] = i with 0 <= i < 256).
The following diff keeps that behaviour, but gets rid of the malloc
call for that ramp, since the values are trivially known.
Compiles but not tested due to the lack
> We only run on New World Macs, and the only ones without openpic(4)
> might be the oldest models of iMac G3 from 1998; these would attach
> macintr0 and not openpic0 in dmesg. I don't know anyone who might
> have such an iMac. The iMac model PowerMac2,1 from 1999 (with the
> (slot-loading cd dr
> Are we keeping this "randompid" global around to make it possible to
> disable random PIDs by toggling it in ddb(4)?
IIRC this logic was needed because some kthreads were created before
arc4random was operational, but that was before substantial changes to
the random generator. However since the
> > As seen in sys/arch/powerpc64/include/trap.h, not-so-ancient PowerPC and
> > POWER processors define exception addresses past EXC_LAST.
>
> Erh, wait, not really. EXC_AST is "fake" and EXC_USER is a flag that
> indicates we came from userland.
I was referring to the few hardware vectors abov
As seen in sys/arch/powerpc64/include/trap.h, not-so-ancient PowerPC and
POWER processors define exception addresses past EXC_LAST.
The following diff changes EXC_LAST to no longer be the last
"traditional" (0x100 bytes long) exception address, but the
(conveniently page-aligned) end of the except
sys/net/pf.c r1.968 added a call to m_print() #ifdef DDB in a
troublesome situation.
Once the root cause of the problem was fixed, the DDB-specific code path
was removed in r1.970, but the added includes were kept, although
nothing in pf.c depends on DDB anymore.
Index: pf.c
=
Two simple changes here:
- dumpframe() is not used by anything. I opted to remove it, but it
could be wrapped in #if 0 or #ifdef DEBUG if people want to keep it
around.
- the /* NOTREACHED */ comment in sendsig() is obviously reachable, so
remove it and update the comment to match the new wor
Unlike userland, the OpenBSD kernel longjmp() function does not take a
return value for setjmp as second argument, but is guaranteed to return
nonzero.
The following diff makes sure the code matches this expectation.
Completely untested, yadda yadda.
Index: support.S
The current state of the kernel starts userland processes with register
a0 pointing to the stack, with a comment mentioning this is copied from
FreeBSD.
But while FreeBSD userland startup code (lib/csu) depends on this,
OpenBSD binaries do not need this.
Thus, don't bother setting up a0 upon star
A long, long time ago (I think it was late 2003), OpenBSD/i386 was
vulnerable to a trusted-yet-NULL pointer dereference in the agp code.
The attack involved using mmap(2) with MAP_FIXED and a hint of zero.
Shortly afterwards, in addition to fixing the overtrusting code, it was
decided never to all
The riscv64 was likely copied from an architecture
providing optimized byte-swapping code (I'd bet arm64), but doesn't have
any such optimization, and copies the MI code.
Acknowledge this by dropping the __HAVE_MD_SWAP define to get the MI
code for free, rather than duplicating it.
Completely un
The following diff makes {audio,midi,radio,video}_hw_if structs in the
kernel const, in order to move them to rodata.
Index: share/man/man9/audio.9
===
RCS file: /OpenBSD/src/share/man/man9/audio.9,v
retrieving revision 1.29
diff -u -
> This issue has been fixed somewhat recently in U-Boot. It only
> happens if you connect a USB keyboard to the machine. With the
> exception of Apple machines and possibly the Raspberry Pi, I expect
> most people to use a serial console on arm64 (and armv7 and riscv64)
> machines. And Apple mac
By default (with no override in /etc/boot.conf), the arm64 boot loader
will attempt to boot the kernel after a 5 second timeout.
On the RPi 4b here, it will indeed boot the kernel, but after about 80
seconds.
The reason for this delay is that there is logic in the boot code, while
waiting for key
I have noticed that a few manual page for network drivers mention the
duplex options in square brackets. This is inconsistent with the vast
majority of the network drivers' manual pages, so let's homogeneize
this.
Index: bse.4
===
RCS
The following diff declares the various devices bwfm@sdmmc checks for,
and introduces no functional change.
Index: if_bwfm_sdio.c
===
RCS file: /OpenBSD/src/sys/dev/sdmmc/if_bwfm_sdio.c,v
retrieving revision 1.42
diff -u -p -r1.42 if_
sys/dev/sdmmc/devlist2h.awk was based upon sys/dev/pcmcia/devlist2h.awk.
The latter contains code to define optional CIS tuple overrides, which
are not used in sdmmc - there is only one override and it is applied in
sdmmc_check_cis_quirks().
The following diff removes this feature from devlist2h.
> I think this makes sense if only for better GNU gzip compatibility.
> OK millert@
But does the `-k' flag needs to be added to compress(1) too?
> Should the default for makefs not be changed, rather than requiring an
> argument?
I'm not fond of that idea, but why not, as long as it gets documented.
> 100 seem extremely small. Imagine a person installing a machine with 5
> drives. Our installer lets people iterate over all their drives.
As you may vaguely remember, I have plans to clean up MAKEDEV a bit,
which have the side effect of removing many unneeded device nodes from
the ramdisk target, used on the installation media.
Doing this will in turn expose a slight difference in filesystem
creation between the pre-makefs(8) world
> What happened to this?
I need to split this into orthogonal diffs, and also since this will
expose an issue in makefs(8), I need to polish and send a fix for makefs
first...
> Index: usr.sbin/installboot/armv7_installboot.c
> ===
> RCS file: src/usr.sbin/installboot/armv7_installboot.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 armv7_installboot.c
> --- usr.sbin/installboot/armv7_installboot.c 20 Ju
On PowerMac11,2 systems, the PCIe bus attaches as:
mpcpcibr0 at mainbus0 pci: u4-pcie
pci0 at mpcpcibr0 bus 0
However none of the devices attached to pci0 will appear in pcidump.
This is caused by an incorrect bus number during attachment of the
pci(4) subdevice. The following diff queries the `
> The register is set to -1, all bits set, and then its upper half
> is cleared. Now that the "and" has been removed, the value seems
> unused. The result of the removed "and" seemed unused too.
Oh, indeed, you're right, that makes things even simpler.
New diff:
Index: sys/arch/alpha/alpha/in_ck
> > - sum += in_cksumdata((caddr_t) &ipov, sizeof(ipov));
> > + sum += in_cksumdata((caddr_t) &ipov + 8, sizeof(ipov) - 8);
>
> I think this would be clearer with a comment.
Sure, added one.
> Please remove the trailing space that some of the changed lines have.
Ok. Updated
> Hi,
>
> linking with librpcsvc should be superfluous now.
Then you should also update DPADD to remove $(LIBRPCSVC}...
> Index: Makefile
> ===
> RCS file: /var/cvs/src/usr.bin/passwd/Makefile,v
> retrieving revision 1.41
> diff -u
in4_cksum(), used to compute packet checksums for the legacy internet
protocol, has been hand-optimized for speed on most elderly platforms,
with the most recent pieces of silicon using a portable C
implementation.
Most of these implementations, in a not-so-uncommon case, need to
checksum an extra
> Sounds like a call for the huge U change.
Since none of these #define seem to be used by .S files, go for it. We
don't really want to bring Mach's U() macro back.
> An unsinged TF_TIMER does not create that problem.
Why don't you simply append an U suffix to TF_TMR_REXMT?
All the is*() ctype.h functions take an int as argument, but valid
values are only EOF, and the range of values of `unsigned char'.
All, but one: the XPG4 isascii(), which has no such restriction.
Quoting https://pubs.opengroup.org/onlinepubs/9699919799/ :
``The isascii() function is defined on al
`return f()' when f is a void function is not allowed by the C standard
but is a gcc extension.
Index: com.c
===
RCS file: /OpenBSD/src/sys/dev/ic/com.c,v
retrieving revision 1.173
diff -u -p -r1.173 com.c
--- com.c 14 Aug 2020
The todr_handle struct contains two unused function pointers, which are
either not implemented or with clones of eopnotsupp(). The following
diff removes this waste of kernel text.
Index: arch/sparc64/dev/rtc.c
===
RCS file: /OpenBSD/
The following diff attempts to clean up a few loose ends in the current
MAKEDEV files:
- remove no-longer applicable device definitions (MSCP and SMD disks,
this kind of thing).
- makes sure all platforms use the same `ramdisk' target for
installation media devices, rather than a mix of `ramd'
A few platforms create pty nodes in /dev in the installation media
filesystem. That wastes 2x62 inodes on an tight filesystem.
The following diff removes these useless (since installation media
kernels lack the pty pseudo-device) /dev entries.
Miod
PS: while there, one might want to unify the cr
> I guess the rest of the page contains 0?
No, it contains a truncated copy of the sigcode.
> It would be better if it contained "trap" instructions. We still don't
> have an ideal way of doing that tho.
That would work, but that would make the code a bit more complicated.
And I'm not sure it's
The code responsible for filling a page with repeated copies of the
signal trampoline code assumes that PAGE_SIZE % sigfillsz == 0.
While this is true on all currently supported OpenBSD platforms, this
might not be the case in the future (and isn't the case on some
no-longer official platforms).
The following diff causes all 64-bit platforms to use the same maxusers
settings. (which in turn affects the maxprocess, maxthread, maxfiles and
initialvnodes kernel variables)
Index: sys/arch/alpha/conf/files.alpha
===
RCS file: /Ope
> No problem, real-life often takes precedence.
No way! operator(7) would need an update!
When asking for the backtrace of a secondary processor in ddb, if that
backtrace reaches the secondary cpu startup code before the
switch_trampoline call, it will trust uninitialized stack data and is
likely to panic with an unaligned access at db_stack_trace_print+0x1d0.
(this was found the hard w
> My understanding is that HZ=100 was a practical choice because the
> machines of the day could not reliably drive a faster clock interrupt.
The VAX architecture defines a 100Hz timer, which is the only timer you
can be sure will be available to the kernel. A few of the later models
(VAXstation 4
> regcomp.c uses the "start + count < end" idiom to check that there are
> "count" bytes available in an array of char "start" and "end" both point
> to.
>
> This is fine, unless "start + count" goes beyond the last element of the
> array. In this case, pedantic interpretation of the C standard m
> > Rebooting with command: boot bsd.rd.gz
>
> This is interesting. The change has it just being named bsd.rd, without the
> .gz.
That's just me testing a compressed bsd.rd.
> Since this change went in, bsd.rd doesn't boot unless I uncompress it first.
>
> upgrade detected: switching to /bsd.upgrade
> Trying /bsd.upgrade...
> NOTE: random seed is being reused.
> Booting /pci@400/pci@2/pci@0/pci@c/nvme@0/disk@1:a/bsd.upgrade
> 4246528@0x100+5120@0x140cc00+3248796@0
regex(3) documents non-standard extensions REG_ITOA and REG_ATOI to
regerror(). In the OpenBSD tree, the only use of them is by the regress
test, so why not move that specific code to the regress test and shrink
libc a bit - remember that this code is present in the installation
media through grep(
1 - 100 of 476 matches
Mail list logo
