[libc++][chrono][NFC] Refactor `nodiscard.verify.cpp` (#175411)
A pre-requisite for https://github.com/llvm/llvm-project/pull/174968 -
just moved around a few lines as a first step to splitting the test.
powerpc: fix release image building for Apple partitions
awk changed somewhere between 14 and 15 and it stopped accepting
a hexadecimal number as its input - it will always return 0.
This results in a very badly written apple boot block.
So just remove it; do the math in shell.
PR: kern/292341
Differential Revision: https://reviews.freebsd.org/D54639
Reviewed by: imp
MFC after: 1 week
wd33c93: split wd33c93_timeout() into timeout and callback
The code actually directly calls the same function for both
processing a timeout (and thus sending an abort, bus reset, etc)
and the callout running.
However, the timeout code doesn't actually complete an acb.
So if an acb times out, it seems to just .. be timed out.
Forever.
So in preparation for adding support for completing an acb with
timeout, split wd33c93_timeout() into timeout and callout.
This should be a no-op.
Patch from Adrian Chadd on port-mips@:
https://mail-index.netbsd.org/port-mips/2025/12/01/msg001535.html
wd33c93: add a debug section for submitted SCSI requests from scsipi
Whilst debugging things like hangs I found it useful to know the
class of scsi request coming in from the upper layer.
* Add a new debug bit entry - SCSIREQ
* Use it to echo the submitted SCSI requests
* Note that the unhandled one will just .. never be serviced, which is
problematic and should be addressed in a subsequent commit.
Patch from Adrian Chadd on port-mips@:
https://mail-index.netbsd.org/port-mips/2025/12/01/msg001535.html
wd33c93: abort the given transfer, not what's on or not currently active
The timeout is per-transfer, not global. And if this happens after
a state changing event - eg the device disconnecting - then sc->sc_nexus
is NULL. Calling wd33c93_abort() with a NULL acb leads to a panic.
Patch from Adrian Chadd on port-mips@:
https://mail-index.netbsd.org/port-mips/2025/12/01/msg001535.html
