graphics/graphviz: remove duplicate lang/tcl BUILD_DEPENDS
Especially after 441bc7f0904b21b777c7a8815a10476b5faaa71d, when
${TCLTK_DEFAULT} != 8.6, build-depends (or before, if poudriere)
complains of nonexistent lang/tcl91.
PR: 300092
devel/fifechan: the port had been improved (+)
- Stretch out CMAKE_MINIMUM_REQUIRED() version range
to accommodate for upcoming CMake 4.x and beyond
- Note that version 0.2.0 is available, however not
compatible with current `games/py-fife' port which
is already at its latest version (as of right now)
- Adjust the option knob order and some descriptions
net/ieee_oui.h: clarify how `OUI_FREEBSD_BASE` is managed
Note that the FreeBSD Foundation manages the current value
associated with `OUI_FREEBSD_BASE`.
Trim trailing whitespace in comments in the change while here.
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/82
ufshci: report the SCSI status and sense to CAM
A CHECK CONDITION was reported to CAM as a transport error without
valid sense, so CAM retried blindly. After a reset the device answers
NOT READY, and those retries ran out and detached the disk.
Report the SCSI status and sense with CAM_AUTOSNS_VALID, and freeze the
device queue on a SCSI status error. A GOOD status with a failed
response is still an error. Stop logging every CHECK CONDITION.
Reviewed by: imp
Sponsored by: Samsung Electronics
Differential Revision: https://reviews.freebsd.org/D61122
ufshci: try the link startup more than once
A device that is still powering on may not answer the first
DME_LINKSTARTUP, and the driver gave up after one try.
Try up to three times. Both attach and reset use this path.
Reviewed by: imp
Sponsored by: Samsung Electronics
Differential Revision: https://reviews.freebsd.org/D61121
ufshci: tell CAM when the controller is gone for good
When the controller failed for good, CAM was not told, so its disks
stayed and every command to them failed.
Post AC_LOST_DEVICE from the failure path so CAM removes them.
Reviewed by: imp
Sponsored by: Samsung Electronics
Differential Revision: https://reviews.freebsd.org/D61120
ufshci: fail the controller when a polled command never completes
The reset task waits on its own polled bring-up commands. If one was
lost, nothing could complete it, and the poll panicked after ten
seconds.
Fail the controller instead. The failure path completes every
outstanding request, including the polled one, so the poll returns an
error to its caller. A polled command is only sent while the controller
is being brought up or by the passthrough ioctl, and a lost one means
the controller is not usable anyway.
Reviewed by: imp
Sponsored by: Samsung Electronics
Differential Revision: https://reviews.freebsd.org/D61119
ufshci: hold back I/O during a reset
The disable path only claims what is in flight at that moment. An I/O
submitted after a reset was requested rang a doorbell that the reset
then wiped, so it was lost. An I/O sent as soon as the queue was back
reached the device before the bring-up had initialized it, and the
device answered NOT READY.
Keep such an I/O on a list instead, without a slot, from the moment a
reset is requested until the bring-up has finished, and send the list
in order then. A request that a reset returned to CAM comes back while
the list is still held, so it waits there too. A completion sends the
next one when the slots have run out. If the controller fails first,
the failure path completes the list with an error. Admin and task
management requests still go out, because the reset task waits on its
own commands and the watchdog sends the aborts. This is how nvme(4)
holds requests while a queue is in recovery.
Reviewed by: imp
[2 lines not shown]
ufshci: requeue requests that a reset aborted
A request taken back by a reset was reported to CAM as an error, which
used up a retry. A few resets in a row failed the I/O even though the
device never saw it.
Pass the overall command status to the completion callback and requeue
aborted requests. The polled completion carries it too, so the
passthrough ioctl reports it instead of a placeholder zero. The abort
path now reports an invalid status instead of aborted, so a command
that never finishes still uses up its retries.
Reviewed by: imp
Sponsored by: Samsung Electronics
Differential Revision: https://reviews.freebsd.org/D61117
ufshci: reclaim in-flight requests across a reset in SDB mode
A reset wipes the controller's request list, so a request that was in
flight never completes. Its slot stayed scheduled, the watchdog timed
it out again, and the next reset went round the same way. CAM never
got the request back.
Claim in-flight requests when the queue is disabled and return them as
aborted once it is back. If the reset fails first, the failure path
completes them instead.
Reviewed by: imp
Sponsored by: Samsung Electronics
Differential Revision: https://reviews.freebsd.org/D61116
ufshci: keep a slot for admin requests
The slot reserve step handed any free slot to whoever asked first, so
I/O could fill the queue and leave no slot for the driver's own admin
commands, which a reset sends through the same queue. A full queue was
also reported to CAM as busy, and CAM used up its retries on that
within microseconds.
Keep the last slot for admin requests and give CAM one opening fewer,
since letting CAM fill every I/O slot cut the throughput sharply. On a
full queue, freeze the device queue and requeue the request. Remove the
unused reserve_admin_slot hook.
Reviewed by: imp
Sponsored by: Samsung Electronics
Differential Revision: https://reviews.freebsd.org/D61114
ufshci: tear down the controller in a safe order
Detach freed the request queues while the interrupt, the watchdog or a
running reset could still use them. It also left the controller
running, so a pending interrupt could hit the next attach before its
queues existed.
Tear down the interrupt, stop the watchdogs, free the task queue,
disable the controller, and only then destroy the queues. A stopped
watchdog stays stopped, so a reset still running cannot arm it again.
A reset requested after the task queue is freed is ignored.
Reviewed by: imp
Sponsored by: Samsung Electronics
Differential Revision: https://reviews.freebsd.org/D61115
ufshci: claim a slot before completing it
A request is completed with the queue lock dropped, because the
completion callback may submit the next request and take that lock
again. The completion scan checked a slot under the lock, dropped the
lock, and only then completed the request, with the slot still marked
scheduled. The failure path and the abort completion look for such
slots under the same lock, so one of them could pick the same slot in
that window. The request was then completed twice, freed twice, and
its CCB went back to CAM twice. After a reset every in-flight slot
reads as done at once, so the window was easy to hit.
No existing state could mark that window. FREE would hand the slot to
a new request while the old completion still reads it, RESERVED means
a submit in progress, and NEED_ERROR_HANDLING is about to mean a
request that a reset has claimed but nobody has completed yet.
Add a completing state. Every path that completes a slot sets it
under the lock before dropping the lock, and every path skips a slot
[6 lines not shown]
ufshci: add debug aids for driving the recovery path
The reset and recovery paths only run when the hardware fails, so they
never ran on an emulated controller. The failure path also took the
controller offline without logging anything.
Add the force_reset, drop_next_ios and drop_next_admins sysctls to
drive these paths, and log when the controller fails. The aborts the
watchdog sends must go out, so the task management queue is never
dropped.
Reviewed by: imp
Sponsored by: Samsung Electronics
Differential Revision: https://reviews.freebsd.org/D61112
ufshci: detect completions with the completion notification register
The single doorbell completion scan took a cleared doorbell bit as a
completion. A bit that was never set reads the same, so a slot whose
doorbell was not rung yet, or one that a reset wiped, looked complete
and was finished with a stale descriptor.
UFSHCI 3.0 added UTRLCNR, which the controller sets when it completes
a request and the driver already clears afterwards. Use it to find
completed slots on a 3.0 or later controller. Older controllers keep
the doorbell check, and the task management list has no such register.
Reviewed by: imp
Sponsored by: Samsung Electronics
Differential Revision: https://reviews.freebsd.org/D61111
mii: fix the LINT-NOVIMAGE build for LAN867X
`sys/kernel.h` must be included for all kernel drivers, per driver(9).
`sys/kernel.h` provides defines for `SI_*`, which
`EARLY_DRIVER_MODULE(..)` in `sys/bus.h` relies on and the latter header
is not "self-standing".
Found when running `make tinderbox`.
Fixes: 83d0eed50106 ("lan867xphy: New driver for Microchip ...")
games/py-fife: update the port to the latest version 0.4.3
This makes it ready for CMake 4.x, albeit still relying on the
old CMP0078 policy, and cleans up a bunch of "from __future__"
imports in the Python code.
Reported by: portscout
