No sense having a variable for this. So use BUS_SPACE_MAXADDR and remove
dma_hiaddr from softc.
Suggested by: jhb
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42808
Replace the test for DataLength == 0 with an assert. It can't happen,
but an assert doesn't hurt. Emacs removed some trailing white space too.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42807
Use the simpler template code for the parent busdma tag for all I/O to
this card.
Reviewed by: mav, jhb, imp
Differential Revision: https://reviews.freebsd.org/D42607
These calls "should" all be synchrounous. There's no bouncing that's
needed for them (at least in the typical case that we have a sane card
that has more bits of dma addresses decoded than we have memory), so
there's no errors possible. Ensure these calls are really synchronous
with BUS_DMA_NOWAIT flags (which should never fail now that the
bus_dmamem_alloc() has succeeded).
Reviewed by: mav, jhb, imp
Differential Revision: https://reviews.freebsd.org/D42606
This usage is obsolete. Replace with maximum bus space size. maxphys
will sort itself out at higher levels.
Reviewed by: mav, jhb, imp
Differential Revision: https://reviews.freebsd.org/D42605
Publish the firmware version on the card like we do for mps/mpr.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D42588
The number of signficant bits that are decoded are returned in the flags
field of the IOCFacts structure from the device. Rather than assume the
worst with a pessimal 32-bit maximum, look at this value and pass it
along to all the dma map creation requests.
A lof of those creations are repetitive and could just inherit from the
base tag if we moved to the templated interface. This is called out as
desireable future work not done at this time.
In addition, due to a chicken and an egg problem, we have to allocate
some of the maps with a 32-bit loaddr. These are the ones we need to
read iocfacts. And they are fine to be so restricted: they are little
used after startup, and when they are used, bouncing is fine.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D42559
Move enqueueing of commands to bus_dmamap_load_ccb callback
Fix fundamental difference between FreeBSD and Linux. On Linux, your dma
load callback always happends before it returns, so drivers are written
to load the map, then submit to hardware. On FreeBSD, the callback may
be deferred and return EINPROGRESS. This means the callback is
responsible for queueing the request to the hardware is done after the
SGL list is created. Make a number of interrelated cahnages:
At the end of mpi3mr_prepare_sgls, add a call to mpi3mr_enqueue_request.
Split the hardware submission out from the end of mpi3mr_action_scsiio
and move it into a new routine mpi3mr_enqueue_request.
Move all error completion from the end of mpi3mr_action_scsiio to where
the error is detected. We cannot pass errors back from the
mpi3mr_enqueue_request to do this on a 'failed' mpi3mr in a centralized
place (since it has to be fire and forget).
Add comments about zero length SGLs never making it into
mpi3mr_prepare_sgls. Keep the code there for the moment, but we only set
cm->data to non-NULL when scsiio_req->DataLength is not zero. So the
datalength can't be zero and we can't send the zero SGLs.
Add commentts about other "impossible" tests in mpi3mr_prepare_sgls that
really should be simple asserts of some flavor.
Eliminate cm->error_code, since we can't pass data back from the
mpi3mr_prepare_sgl callback anymore.
In mpi3mr_map_request, call mpi3mr_enqueue_request for the no data case.
This seems to work even though we've not done the special zero length
handling that was in mpi3mr_prepare_sgls, giving further evidence to it
not actually being needed. This is needed for SCSI CDBs that have no
data to pass to the drive like TEST UNIT READY.
With this change, and the prior ones, we're now able to run with mpi3mr
on 128GB systems and very heavy disk load (so many buffers land > 4GB:
the driver instructs busdma to never use memory abouve 4GB, which may be
too conservative, but an issue for another time).
Sponsored by: Netflix
Reviewed by: sumit.saxena_broadcom.com, mav, jhb
Differential Revision: https://reviews.freebsd.org/D42543
More uniformly use mpi3mr_set_ccbstatus in mpi3mr_action_scsiio. The
routine mostly used it, but also has setting of status by hand. In those
cases where we want to error out the request, use this routine.
As part of this, move setting CAM_SIM_QUEUED later in the function to
when we're sure it's been queued. Remove the places we clear it before
this.
Sponsored by: Netflix
Reviewed by: mav, jhb
Differential Revision: https://reviews.freebsd.org/D42542
Since we assume there's a timeout to cancel when this is true, only set
it true when we set the timeout. Otherwise we may try to cancel a timeout
when there's been an error in submission.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D42541
Reduce the scope of reset_mutext to protect the msleep in the watch dog
thread as well as the MPI3MR_FLAGS_SHUTDOWN bit. Use it to protect the
wakeup in mpi3mr_detach so this thread can exit sooner when we're trying
to do an orderly shutdown. Optimize the flow to check the sleep and
other conditions before going to sleep.
It's an open question if this should protect sc->unrecoverable, and if
we should wakeup the watchdog thread when we set it. We might also want
to move too booleans for the three flags that we have now in
mpi3mr_flags. There are a number of U8s that should really be bools and
we might want to also group them together to pack softc better.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D42539
All of these fields are either unused, or just initialized. Remove
them. This saves about 1MB of memory for the cards that I have which can
do 8k transactions at once.
Sponsored by: Netflix
Reviewed by: mav, jhb
Differential Revision: https://reviews.freebsd.org/D42538
Holding fwevt_lock when we call taskqueue_drain can lead to deadlock
because it's draining a queue needs fwevt_lock to do work, so that other
thread will try to take out the lock and block, making the thread never
finish and taskqueue_drain never complete. There's a witness
warning/error for this which was exposed when the lock was converted to
a MTX_DEF lock from a MTX_SPIN prior to committing to the FreeBSD tree.
The lock appears to be to protect against additional items being added
to the event list while we're doing a reset. Since the taskqueue is
blocked, items can get added to the list, but won't be processed during
the reset, but there is still a (likely small) race between the
taskqueue_drain and the taskqueue_block calls where an interrupt could
fire on another CPU, resulting in a task being enqueued and started
before the block can take effect. The only way to fix that race is to
turn off interrupt processing during a reset. So we replace a deadlock
with a smaller race.
Sponsored by: Netflix
Reviewed by: sumit.saxena_broadcom.com, mav, jhb
Differential Revision: https://reviews.freebsd.org/D42537
The driver argument is most certainly now used by these functions. When
originally implemented it might have been unused, but not now.
Reviewed by: royger
These were needed in the past, since that time the interrupt code has
been successfully isolated from the Xen/PCI code. As such a bit of
straightforward cleanup.
Differential Revision: https://reviews.freebsd.org/D32923
Reviewed by: royger
Fix a few spots where handle pointers were incorrectly used. Luckily
these appear rarely triggered given how long they've been lurking.
Fixes: 76acc41fb7 ("Implement vector callback for PVHVM and unify event channel implementations")
Fixes: 9f40021f28 ("Introduce a new, HVM compatible, paravirtualized timer driver for Xen.")
MFC after: 2 weeks
Reviewed by: royger
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.
Sponsored by: Netflix
[Why]
This ensures that vtterm_cnungrab() is the mirror of vtterm_cngrab().
And the latter always call vt_window_switch() and thus the backend's
vd_postswitch().
This makes sure that whatever the backend did during vtterm_cngrab(), it
can undo it during vtterm_cnungrab().
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42752
[Why]
We want the same behavior at the backend level, regardless if we need to
switch the current window or not.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42751
[Why]
In the DRM drivers and the integration with vt(4), we need to execute
DRM code outside of the vtbuf_lock. The reason is that this DRM code
acquires locks which can't be acquired when vtbuf_lock, an MTX_SPIN
mutex, is already held.
[How]
A vt(4) backend can now set the `vd_bitblt_after_vtbuf_unlock` flag to
true if it wants to be called outside of vt_buf_lock.
In this case, vt(4) uses an internal version of bitblt_text that uses
the `vd_drawn` arrays, plus a new `vd_pos_to_flush` array, to track
characters to draw/refresh. This internal version then uses the
backend's bitblt_bmp callback to draw the characters after vt_buf has
been unlocked.
Drawing borders and CPU logos is also deferred after the vt_buf lock is
released for the same reason.
We introduce another lock (a default mutex), only used when the
`vd_bitblt_after_vtbuf_unlock` flag is set, to replace part the role of
the vt_buf lock and manage concurrent calls to vt_flush().
The `SC_NO_CONSDRAWN` define is dropped because we now always need the
`vd_drawn` arrays.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42057
[Why]
The same protection was added to vt_flush() in the previous commit. We
want the same one in vt_window_switch(): if e.g. the DRM driver panics
while handling a call to vt_window_switch(), we don't want to
recursively call vt_window_switch() again and trigger another panic.
Reviewed by: imp, manu
Approved by: imp, manu
Differential Revision: https://reviews.freebsd.org/D42750
[Why]
If there is a problem with DRM drivers or in their integration with
vt(4) and displaying something on the console triggers a panic, there is
a high chance that displaying that panic will trigger another one,
recursively.
[How]
If vt_flush() is called and it detects is is called resursively from
another panic, it return immediately, doing nothing, to avoid the risk
of triggering another panic.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42056
It is desirable to shut down the raid controller even in the face of a
panic. In the SCHEDULER_STOPPED() case, set the interrupt mask bits so
that we request a polled wait, rather than sleep(), from
iop_queue_wait_msg().
Tweak the function name and signature.
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42337
I did not realize this driver was i386-only, and the change fails to
compile. Revert so that I can fix it properly.
This reverts commit 428ebb7cd9.
Pointy hat to: mhorne
xpt_path_string() is now a wrapper around xpt_path_sbuf(). Using it
to than concatenate result to another sbuf makes no sense. Just call
xpt_path_sbuf() directly.
MFC after: 1 month
Make better use of the shutdown flags. In particular this now handles
standard reboot where RB_POWERCYCLE is not set, and indicates a crash
when the system has panicked.
While here, give the function a prefix.
Reviewed by: royger, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42343
Don't attempt to service reconnections if RB_NOSYNC is set. More
crucially, don't do it if the scheduler is stopped, as the maintenance
thread will never run again.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42342
It is desirable to shut down the raid controller even in the face of a
panic. In the SCHEDULER_STOPPED() case, set the interrupt mask bits so
that we request a polled wait, rather than sleep(), from
iop_queue_wait_msg().
Tweak the function name and signature.
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42337
Ensure they are all panic/debugger safe.
Most handlers for this event are for disk drivers/geom modules. There
are a mix of checks being used here (or not), so let's standardize on
checking the presence of the RB_NOSYNC flag.
This flag is set whenever:
1. The kernel has panicked and kern.sync_on_panic=0*
2. We reboot from within the kernel debugger (the "reset" command)
3. Userspace requested it, e.g. by 'reboot -n'
Name the functions consistently.
*This sysctl is tuned to zero by default, but its existence means that
these handlers can be executed after a panic, at the user's discretion.
IMO this use-case is implicitly understood to be risky, and we'd be
better off eliminating it altogether.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42337
The registration was removed in favor of DEVICE_SHUTDOWN(). Drop the
unused eventhandler tag from the IAL_ADAPTER_T structure.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Fixes: cd3ef66680 ("Use DEVICE_SHUTDOWN(9) mechanism...")
Differential Revision: https://reviews.freebsd.org/D42334
Instead, use the attribtue bits from the identification data to
determine if we should listen to namespace changes and firmware
activation. Should have no functional change, though we may stop
listening for events that will never happen.
Sponsored by: Netflix
The VSC8514 Quad-Port 10/100/1000BASE-T PHY seems to match the handling
for the VSC8504 (for the little we support of what we could) and while
it works with our generic ukphy add it as vscphy for porper display of
names in the system message buffer and the like (or in case we decide
to implement some extra features).
Tested on: Ten64
MFC after: 3 days
'pcs-handles' are not mandatory in the device tree here so do not
enforce them. This allows us to find dpmac entries needed for phys
on the WHLE-LS1 as well.
MFC after: 3 days
Reviewed by: jceel, dsl
Differential Revision: https://reviews.freebsd.org/D42644
dpaa2_ni_media_change() was called in early setup stages, before we
were fully setup. That lead to internal driver state being all synched
and fine but hardware state was lost/never setup corrently.
Introduce dpaa2_ni_media_change_locked() so we can avoid reccursive
locking and call "dpaa2_ni_media_change()" instead of mii_mediachg()
as the latter does not setup our state there either.
In order for this all to work, call if_setdrvflagbits() just before
rather than after the above.
Also remove an unecessary direct call to dpaa2_ni_miibus_statchg()
which mii_mediachg() will trigger anyway.
This all fixes a problem [1] that one had to lose the link (either
unplugging/replugging the cable or using ifconfig media none;
ifconfig media auto) to re-trigger the all updates and get the
full state programmed when hardware expected.
MFC after: 3 days
GH-Issue: https://github.com/mcusim/freebsd-src/issues/21 [1]
Reviewed by: dsl, dch
Differential Revision: https://reviews.freebsd.org/D42643
dpni announces IFCAP_VLAN_MTU but internally does not increase the
maximum frame length. Createing a vlan interface on top of a dpni
interface will result in full-sized frames not passing.
Extend the maximum frame length by ETHER_VLAN_ENCAP_LEN to allow at
least for one layer of (software) vlans for now
MFC after: 3 days
GH-Issue: https://github.com/mcusim/freebsd-src/issues/22
Reviewed by: dsl
Differential Revision: https://reviews.freebsd.org/D42645
If removing a node of type FS_TYPE_FLOW_DEST we lock the flow group too
late. This can lead to a deadlock with fs_add_dst_fg().
PR: 274715
MFC after: 1 week
Reviewed by: kib
Tested by: mm
Differential Revision: https://reviews.freebsd.org/D42368
