In the VESA driver, simply ignore errors. It is not clear to me how to
return them to userspace.
This is in preparation for annotating copyin() and related functions
with __result_use_check.
MFC after: 1 week
(cherry picked from commit ddc8576d297937a1395f47550a8f5b1fac79afc2)
Try to copy out output values before handling errors, and check that we
did so successfully. In particular, it doesn't seem sensible to ignore
errors here, otherwise userspace won't have any way to refer to the
allocations.
This is in preparation for annotating copyin() and related functions
with __result_use_check.
Reviewed by: royger
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43145
(cherry picked from commit 6cdff09c0d70f780a738dbd3d87deb3b13ec8446)
In preparation for adding a __result_use_check annotation to copyin()
and related functions, start checking for errors from copyout() in
the mpr(4) user command handler. This should make it easier to catch
bugs.
Reviewed by: imp, asomers
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D43177
(cherry picked from commit 68cc77a3b73ffda1e8ac891b9852faca833e11b7)
In preparation for adding a __result_use_check annotation to copyin()
and related functions, start checking for errors from copyout() in
the mps(4) user command handler. This should make it easier to catch
bugs.
Reviewed by: imp, asomers
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D43176
(cherry picked from commit bcf4a7c7ace21a01d10003de9c7692f0887526c1)
If copyin() fails, the driver will blindly proceed with whatever had
been in the uninitialized DMA buffer. This is not what we want. Check
for copyin failures.
This is in preparation for annotating copyin() and related functions
with __result_use_check.
Reviewed by: ram
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43097
(cherry picked from commit a01ff11cb73d7a1988f6241f63d141371ff23717)
A failed copyin will cause the driver to use the contents of
uninitialized buffers instead, which is unlikely to be the behaviour
that we want. Check for errors.
This is in preparation for annotating copyin() and related functions
with __result_use_check.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43098
(cherry picked from commit 6bfb7306ef92aaccffae42ed00ce6d7201b76966)
This is in preparation for annotating copyin() and related functions
with __result_use_check.
Reviewed by: wulf
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43103
(cherry picked from commit b2caed2f8d699d6dc59ecf8810d945cdea148c44)
If copyin() fails, the driver will proceed blindly with a zeroed buffer,
which is not what we want. In preparation for annotating copyin() with
__result_use_check, start checking for errors.
Reviewed by: wulf
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43102
(cherry picked from commit e452fa70d50761b5fe5f19c3c93c107be116728c)
Some Raspberry Pi pass smsc95xx.macaddr=XX:XX:XX:XX:XX:XX as bootargs.
Use this if no ethernet address is found in an EEPROM.
As last resort fall back to ether_gen_addr() instead of random MAC.
(cherry picked from commit 3878bbf1bb9e68f8579b57cde7d4e5c77de93320)
if_smsc: fix build on armv6 & armv7
compile error was:
/usr/src/sys/dev/usb/net/if_smsc.c:1597:40: error: format specifies type 'unsigned long' but the argument has type 'ssize_t' (aka 'int') [-Werror,-Wformat]
"failed alloc for bootargs (%lu)", len);
~~~ ^~~
%zd
(cherry picked from commit 8a0ee306227a17a998bdc7af2275fd94b9164342)
PR: 274092
Reported by: Patrick M. Hausen (via ML)
Reviewed by: imp, karels, zlei
Tested by: Patrick M. Hausen
Approved by: karels
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D42463
Hardware timeout uses a 8-bit timeout value and expects the timeout to
be less than 255 seconds. Added software timer implemetation to timeout
and abort the IOs with timeout more than 255 seconds.
Fix the timeout problem by dividing CAM timeouts by 1000 as hardware
expects timeout value in seconds. Before this change, CAM timeouts in
milliseconds were getting truncated to 8 bits and converted to seconds.
So the actual timeout used when going down to the card would depend on
the bottom 8 bits of the timeout used.
Add the mapping of ocs_fc error status to CAM status.
Reported by: ken
Reviewed by: ken
Tested by: ken, ram
Approved by: ken
MFC after: 1 week
(cherry picked from commit 70547544ce931357c980be47d937e5b57a2d7f49)
struct nvme_hmb_desc contains a pad field which was not getting
initialized before being synced. This doesn't have much consequence but
triggers a report from KMSAN, which verifies that host-filled DMA memory
is initialized before it is made visible to the device. So, let's just
initialize it properly.
Reported by: KMSAN
Reviewed by: mav, imp
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43090
(cherry picked from commit d9b7301bb791faab48b6c7733c34078427b9a374)
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
(cherry picked from commit 8c4ee0b22c98fc1e208dd133f617bd329cd10728)
Most all of the memory used by the cards in the mpr(4) and mps(4)
drivers is required, according to the specs and Broadcom developers,
to be within a 4GB segment of memory.
This includes:
System Request Message Frames pool
Reply Free Queues pool
ReplyDescriptorPost Queues pool
Chain Segments pool
Sense Buffers pool
SystemReply message pool
We got a bug report from Dwight Engen, who ran into data corruption
in the BAE port of FreeBSD:
> We have a port of the FreeBSD mpr driver to our kernel and recently
> I found an issue under heavy load where a DMA may go to the wrong
> address. The test system is a Supermicro X10SRH-CLN4F with the
> onboard SAS3008 controller setup with 2 enterprise Micron SSDs in
> RAID 0 (striped). I have debugged the issue and narrowed down that
> the errant DMA is one that has a segment that crosses a 4GB
> physical boundary. There are more details I can provide if you'd
> like, but with the attached patch in place I can no longer
> re-create the issue.
> I'm not sure if this is a known limit of the card (have not found a
> datasheet/programming docs for the chip) or our system is just
> doing something a bit different. Any helpful info or insight would
> be welcome.
> Anyway, just thought this might be helpful info if you want to
> apply a similar fix to FreeBSD. You can ignore/discard the commit
> message as it is my internal commit (blkio is our own tool we use
> to write/read every block of a device with CRC verification which
> is how I found the problem).
The commit message was:
> [PATCH 8/9] mpr: fix memory corrupting DMA when sg segment crosses
> 4GB boundary
> Test case was two SSD's in RAID 0 (stripe). The logical disk was
> then partitioned into two partitions. One partition had lots of
> filesystem I/O and the other was initially filled using blkio with
> CRCable data and then read back with blkio CRC verify in a loop.
> Eventually blkio would report a bad CRC block because the physical
> page being read-ahead into didn't contain the right data. If the
> physical address in the arq/segs was for example 0x500003000 the
> data would actually be DMAed to 0x400003000.
The original patch was against mpr(4) before busdma templates were
introduced, and only affected the buffer pool (sc->buffer_dmat) in
the mpr(4) driver. After some discussion with Dwight and the
LSI/Broadcom developers and looking through the driver, it looks
like most of the queues in the driver are ok, because they limit
the memory used to memory below 4GB. The buffer queue and the chain
frames seem to be the exceptions.
This is pretty much the same between the mpr(4) and mps(4) drivers.
So, apply a 4GB boundary limitation for the buffer and chain frame pools
in the mpr(4) and mps(4) drivers.
Reported by: Dwight Engen <dwight.engen@gmail.com>
Reviewed by: imp
Obtained from: Dwight Engen <dwight.engen@gmail.com>
Differential Revision: <https://reviews.freebsd.org/D43008>
(cherry picked from commit 264610a86e14f8e123d94c3c3bd9632d75c078a3)
struct siba_bhndb_softc embeds struct siba_softc and adds an extra
field, "quirks". In practice, this bug was harmless since "quirks" is
unconditionally initialized during driver attach and would have lived in
the redzone of the softc allocation, but KASAN catches the out-of-bounds
access.
PR: 275515
Reported by: Frank Hilgendorf <frank.hilgendorf@posteo.de>
MFC after: 1 week
(cherry picked from commit 4c3aa00c0a0093c78f42d138bb9eef9b1a7cbb39)
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
(cherry picked from commit c4dacfa7f4b82f23ec0924d9db772860b2066f9b)
(cherry picked from commit f97aab79868cd7d891c52b14bd964523fa56f015)
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
(cherry picked from commit 2ce1c45b3411410a5d0a4d08198a3b0010d493b7)
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
(cherry picked from commit 9e0b0f5de67fd46bddf0e12ef7b71d76a7ec1667)
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
(cherry picked from commit 4eb861d362d6a9493df7f77eab8e28f9c826702a)
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
(cherry picked from commit a4b19cf5c76ac66d02a3ef8a549115ba865d630c)
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
(cherry picked from commit 1965dd85c3b33ed99cb8ef164dd7c5b20425a85e)
VSC8641 is a ciphy not a vscphy.
Sort it with the other entries of ciphy to avoid confusion.
(cherry picked from commit 43324ec770f6b598f0ce25487f69a64b3c9822bd)
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
GH-Issue: https://github.com/mcusim/freebsd-src/issues/22
Reviewed by: dsl
Differential Revision: https://reviews.freebsd.org/D42645
(cherry picked from commit 0480dccd3f347da0dbccf5917633435d5ce6cb86)
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.
GH-Issue: https://github.com/mcusim/freebsd-src/issues/21 [1]
Reviewed by: dsl, dch
Differential Revision: https://reviews.freebsd.org/D42643
(cherry picked from commit 964b3408fa872178aacf58f2d84dc43564ec0aa7)
'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.
Reviewed by: jceel, dsl
Differential Revision: https://reviews.freebsd.org/D42644
(cherry picked from commit 6c46ebb05dccdcee18f64dc122e6685c05180217)
Some touchpads places button usages (in HID report descriptor) in to
the 2-nd level collection rather than in to the top level one. That
confuses current code. Remove collection level check in HID report
descriptor parser to fix device detection.
Reported by: Peter Much <pmc@citylink.dinoex.sub.org>
PR: 267094
(cherry picked from commit 1d46c8e5c2702c141c6be982b3ca44e74d1cb8f1)
