Support early printf for the ns8250 uart driver. Adding
options UART_NS8250_EARLY_PORT=0xYYY
options EARLY_PRINTF
to your kernel config will enable it. The code is rather simple minded,
so caveat emptor. This will enable printf before cninit. cninit
automatically disables this and switches to the real routine. It only
works for port-mapped COM ports, and only if you know the port's address
at compile time. It's intended for be a debugging aide, not a general
purpose thing.
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D42306
The driver has a tunable hw.xn.enable_lro which is intended to control
whether LRO is enabled. This is currently non-functional - even if its
set to zero, the driver still requests LRO support from the backend.
This change fixes the feature so that if enable_lro is set to zero, LRO
no longer appears in the interface capabilities and LRO is not requested
from the backend.
PR: 273046
MFC after: 1 week
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D41439
It is observed that netvsc's send rings could stall on the latest
Azure Boost platforms. This is due to vmbus_rxbr_read() routine
doesn't check if host is waiting for more room to put data, which
leads to host side sleeping forever on this vmbus channel. The
problem was only observed on the latest platform because the host
requests larger buffer ring room to be available, which causes
the issue to happen much more easily.
Fix this by adding check in the vmbus_rxbr_read call and signaling
the host in the callers if check returns positively.
Reported by: NetApp
Tested by: whu
MFC after: 3 days
Sponsored by: Microsoft
Move creation of watchdog process from just before we configure the
interrupt config hook to into the config hook itself. This prevents it
from racing the config intr hook and doing an extra reset of the
card. This extra reset is usually harmless, but sometimes it can prevent
discovery of devices if done at just the wrong time. This can lead to no
disks being registered in a box full of disks, for example. Starting it
later eliminates this race, making discovery reliable.
Reviewed by: imp
Problem: Under certain I/O conditions, a program doing large block disk
reads can cause a controller to crash.
Root Cause: The SCSI read request and destination address in the BDMA
descriptor is incorrect, causing the BDMA engine in the controller to
assert.
Fix: Change the alignment for creating bus_dma_tags in the driver from
PAGE_SIZE (4k) to 1, which allows the controller to manage it's own
address range for BDMA transactions.
Risk: Medium
Exposure: This reverts a change first made to support NVMe drives on
Excalibur. At that time a 4k alignment was necessary. This no longer
seems to be the case.
PR: 259541
Reported by: Ka Ho Ng <khng@freebsd.org>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D41619
pqisrc_free_device frees the device softc with the os spinlock
held. This causes crashes when devices are removed because the memory
free might sleep (which is prohibited with spin locks held). Drop the
spinlock before releasing the memory.
MFC After: 2 days
PR: 273289
Reviewed by: imp
This includes event definitions from sys/pmc_events.h, definitions from
sys/pmc.h, and the man pages.
Reviewed by: jkoshy
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41275
This is i386-only, and has been effectively disabled since 2018 when the
companion support was removed from libpmc (e92a1350b5). Remove the
kernel support to simplify the AMD class.
Reviewed by: jkoshy
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41274
Make them a little bit more consistent with one another in terms of what
is done:
- Add/reduce assertions to what is most useful: a loop to ensure
pcpu_fini freed everything
- Add PMCDBG trace entries
The exception is the dmc620/cmn600 classes, which behave a little
differently, so leave them untouched.
Reviewed by: jkoshy
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41270
Currently if _BBN doesn't match the first bus in the decoded bus range
from _CRS for a Host to PCI bridge, the driver fails to attach as a
defensive measure.
There is now firmware in the field where these do not match, and the
_BBN values are clearly wrong, so rather than failing attach, trust
the range from _CRS over _BBN.
Co-authored-by: Justin Gibbs <gibbs@FreeBSD.org>
Reported by: gibbs
Reviewed by: imp (earlier version)
Differential Revision: https://reviews.freebsd.org/D42231
Turns out we need all the barrier.
The one before writing the OWN bit is needed so the DMA engine
have coherent data, the second one (after the OWN bit is set) is
also needed because the DMA buffers are allocated with VM_MEMATTR_DEFAULT
whic equals to being cached.
This reverts commit 2b4f615e7d4720b16007cfa8aaedf720f572067a.
This reverts commit 4870346488051b9c4a1dc8b11cab55d4e5b7c230.
Reported by: mmel
Tell bus_dma(9) which NUMA domain the PCI driver is closest to so it
can allocate memory from there when possible.
Reviewed by: markj, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D42186
An interface's bpf could feasibly not exist, in which case
bpf_peers_present() would panic from a NULL pointer dereference. Solve
this by adding a new IfAPI that could deal with a NULL bpf, if such
could occur in the network stack.
Reviewed by: zlei
Sponsored by: Juniper Networks, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42082
An interface's bpf could feasibly not exist, in which case
bpf_peers_present() would panic from a NULL pointer dereference. Solve
this by adding a new IfAPI that includes a NULL check. Since this API
is used in only a handful of locations, it reduces the the NULL check
scope over inserting the check into bpf_peers_present().
Sponsored by: Juniper Networks, Inc.
MFC after: 1 week
We need the DMA engine to have everything coherent *before* we
set the OWN bit (the bit that tells the DMA engine that it owns
the descriptor).
Fixes: 487034648805 ("dwc: Rewrite barrier part")
Reported by: jhb
Handle ged interrupts directly from the interrupt handler,
while the interrupt source is masked, so as to conform
with the acpi spec, and avoid spurious interrupts and
lockups on boot.
When an acpi ged interrupt is encountered, the spec requires
the os (as stated in 5.6.4: General Purpose Event Handling)
to leave the interrupt source masked until it runs the
EOI handler. This is not a good fit for our method of
queuing the work (including the EOI ack of the interrupt),
via the AcpiOsExecute() taskqueue mechanism.
Note this fixes a bug where an arm64 server could lock up if
it encountered a ged interrupt at boot. The lockup was
due to running on a single core (due to arm64 not using
EARLY_AP_STARTUP), and due to that core encountering a
new interrupt each time the interrupt handler unmasked
the interrupt source, and having the EOI queued on a taskqueue
which never got a chance to run. This is also possible
on any platform when using just a single processor.
The symptom of this is a lockup at boot, with:
"AcpiOsExecute: failed to enqueue task, consider
increasing the debug.acpi.max_tasks tunable" scrolling
on console.
Similarly, spurious interrupts would occur when running
with multiple cores, because it was likely that the
interrupt would fire again immediately, before the
ged task could be run, and before an EOI could be sent
to lower the interrupt line. I would typically see
3-5 copies of every ged event due to this issue.
This adds a tunable, debug.acpi.ged_defer, which can be
set to 1 to restore the old behavior. This was done
because acpi is a complex system, and it may be
theoretically possible something the ged handler does
may sleep (though I cannot easily find anthing by inspection).
MFC after: 1 month
Reviewed by: andrew, jhb, imp
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42158
While we should have cleared all the pending I/O prior to calling
nvme_qpair_destroy, which should ensure that if the callout_drain causes
a call to nvme_qpair_timeout(), it won't schedule any new
timeout. However, it doesn't hurt to set timeout_pending to false in
nvme_qpair_destroy() and have nvme_qpair_timeout() exit early if it sees
it w/o scheduling a timeout. Since we don't otherwise stop the timeout
until we're about to destroy the qpair, this ensures we fail safe. The
lock/unlock also ensures the callout_drain will either remove the callout,
or wait for it to run with the early bailout.
We can likely further improve this by using callout_stop() inside the
pending lock. I'll investigate that for future refinement.
Sponsored by: Netflix
Suggestions by: jhb
Reviewed by: gallatin
Differential Revision: https://reviews.freebsd.org/D42065
While it seemed like a good idea to have this state, we can do
everything we wanted with the state by checking ctrlr->is_failed since
that's set before we start failing the qpairs. Add some comments about
racing when we're failing the controller, though in practice I'm not
sure that kind of race could even be lost.
Sponsored by: Netflix
Reviewed by: chuck, gallatin, jhb
Differential Revision: https://reviews.freebsd.org/D42051
After da8324a925, the pre/post hooks are gone. So remove a coment
about why we don't call them in this case.
Sponsored by: Netflix
Reviewed by: chuck, jhb
Differential Revision: https://reviews.freebsd.org/D42050
da8324a925 removed one of the two instances of NVME_2X_RESET. It
failed to snag the other one, and remove it from the options file.
Remove from both of those here.
Sponsored by: Netflix
Reviewed by: chuck, gallatin, jhb
Differential Revision: https://reviews.freebsd.org/D42049
In 4b977e6dda we removed the call to nvme_ctrlr_post_failed_request
because we can now directly fail requests in this context since we're in
the reset task already. No need to queue it. I left it in place against
future need, but it's been two years and no panics have resulted. Since
the static analysis (code checking) and the dyanmic analysis (surviving
in the field for 2 years, including at $WORK where we know we've gone
through this path when we've failed drives) both signal that it's not
really needed, go ahead and GC it. If we discover at a later date a flaw
in this analysis, we can add it back easily enough by reverting this and
4b977e6dda.
Sponsored by: Netflix
Reviewed by: chuck, gallatin, jhb
Differential Revision: https://reviews.freebsd.org/D42048
callout_stop() requires the associated lock to be held.
This is a bit hacky, but I believe it's safe since the subsequent
mrsas_cmd_done() call will also acquire the SIM lock to stop a different
callout.
PR: 265484
Reviewed by: imp
Tested by: Jérémie Jourdin <jeremie.jourdin@advens.fr>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39559
- Add a txdesc_clear which clears the tx desc instead of doing that in
dwc_setup_txdesc based on arguments.
- Remove dwc_set_owner, in the end we always set the owner of the desc
as we do it for id > 0 and then for the first one.
- Remove dwc_ prefix
No functional changes intended.
This doesn't represent the mac_type but if the DMA engine support
extended descriptors.
Read the HW_FEATURE register to learn if the DMA engine supports it.
No functional changes intended.
And rename it to DMA_DEFAULT_PBL, this is the default for all (most ?)
dma engine that dwc should support.
While here stop including dwc1000_reg.h in if_dwc.c, we don't need it anymore.
No functional changes intended.
