Sometimes, especially with older firmware, mps(4) would have trouble
initializing the card in one of these two steps. Add in a retry after a
short delay. Sean Bruno and Stephen McConnell thought this was OK in the
bug discussions, but never committed it. Steve indicated the delay
might not be necessary, but the OP clearly needed to make it longer to
make things work. I've kept the delay, and added the suggested comment.
Ported the iocfacts part to mpr as well, since we see similar errors
about once every month or two over a few thousand controllers at
work. We've not seen it with IOC_INIT as far back as I can query the
error log database, so I didn't port that forward. We'll see if this
helps, but won't know for sure until next year (so I'm committing it now
since it won't hurt and might help). We usually see this failure in
connection with complicated recovery operations with a drive that's
failing, though, at least in the last year's worth of failures. It's
not clear this is the same as OP or not.
PR: 212841
Sponsored by: Netflix
Co-authored-by: imp
(cherry picked from commit c0e0e530ced057502f51d7a6086857305e08fae0)
The units of the size reported in the 'sectors' xenbus node is always 512b,
regardless of the value of the 'sector-size' node. The sector offsets in
the ring requests are also always based on 512b sectors, regardless of the
'sector-size' reported in xenbus.
Fix both blkfront and blkback to assume 512b sectors in the required fields.
The blkif.h public header has been recently updated in upstream Xen repository
to fix the regressions in the specification introduced by later modifications,
and clarify the base units of xenstore and shared ring fields.
PR: 280884
Reported by: Christian Kujau
MFC after: 1 week
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D46756
(cherry picked from commit e7fe85643735ffdcf18ebef81343eaac9b8d2584)
Current cleanup code assumes that all the fields are allocated and/or setup by
the time cleanup is called, but this is not always true: a failure in mid-setup
of the device will cause the functions to be called with possibly uninitialized
fields.
Fix the functions to cope with such sate, while also attempting to make the
cleanup idempotent.
Finally fix an error path during setup that would not mark the device as
closed, and hence prevents the kernel from finishing booting.
Fixes: 96375eac94 ("xen-netfront: add multiqueue support")
Sponsored by: Citrix Systems R&D
(cherry picked from commit 318bbb6d5a1eae77eb5dc687bcc63c0f99558e21)
The current sizing of the array used to store grant table frames is broken, as
the calculation:
max_nr_glist_frames = (boot_max_nr_grant_frames *
GREFS_PER_GRANT_FRAME /
(PAGE_SIZE / sizeof(grant_ref_t)));
Is plain bogus, for once grant_ref_t is the type of the grant reference, but
not the entry used to store such references in the grant frames. But even if
the above calculation is switched to use grant_entry_v1_t, it would end up as:
max_nr_glist_frames = (boot_max_nr_grant_frames *
(PAGE_SIZE / sizeof(grant_entry_v1_t)) /
(PAGE_SIZE / sizeof(grant_entry_v1_t)));
Which is pointless (note GREFS_PER_GRANT_FRAME has been expanded to (PAGE_SIZE
/ sizeof(grant_entry_v1_t))).
Just use boot_max_nr_grant_frames directly to size the grant table frames
array.
Fixes: 30d1eefe39 ("Import OS interfaces to Xen services.")
Sponsored by: Citrix Systems R&D
(cherry picked from commit 1a12f0aea81b57d0dd2374047b8f4c97a037a8df)
Add IDs for Realtek, Atheros (QCA), and Mediatek.
While I am not sure we'll ever support the ath10k and possibly mt76
SDIO devices, rtw88 ones can be found with SoCs (e.g. r2s-plus) and
are actively being worked on.
Update Broadcom/Cypress entries.
Sponsored by: The FreeBSD Foundation
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D46460
(cherry picked from commit a800b5bcd1b6638530d3a0759b17cd8d93b7e7ca)
This chipset suffered an (un)usual number of bugs and iterations. Let's
add our NVM/firmware code from e1000 and the similar igc_nvm function
from DPDK to keep track of issues.
Sponsored by: BBOX.io
(cherry picked from commit 33ed9bdca307bedb3d66a50ed7d4d7b4bf4acf39)
igc, derived from igb, does not use these registers. All interrupt
timing is governed by EITR or LLI and driven by write-back.
Sponsored by: BBOX.io
(cherry picked from commit a40ecb6f740530fb7e6a95e702113aa3fe24d975)
These are more succinct than jumping through the function pointers
directly and add some additional error handling.
(cherry picked from commit 1e3b1870ad2a426de6e3f5445211b698f20f7f1f)
Provide macros to derive the various needed values and make it a bit
more clear the differences between em and igb.
The igb default EITR was not landing at the right offset.
Respect the 'max_interrupt_rate' tunable.
Sponsored by: BBOX.io
(cherry picked from commit 9bf9164fc8aad1ca828c725413e06462aef1e4dd)
The absolute and packet timers only apply to lem and em with some only
applying to the later.
This cleans up the sysctl tree to only show these where applicable and
stops writing to unexpected registers for igb.
Sponsored by: BBOX.io
(cherry picked from commit 1c578f1c93112d3d53820f8b6b411488b83f0ab2)
Avoid a race condition when accessing guest memory, by reading memory
contents only once.
This has also been applied to _vq_record() in
sys/dev/beri/virtio/virtio.c, as per markj@'s suggestion.
Reported by: Synacktiv
Reviewed by: markj
Security: HYP-10
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45735
(cherry picked from commit 869d760cb9d7a307faa2fbe8c1c2b238a81b74d4)
Based on sysinit_sub_id, SI_SUB_CLOCKS is after SI_SUB_CONFIGURE.
SI_SUB_CONFIGURE = 0x3800000, /* Configure devices */
At this stage, the variable “cold” will be set to 0.
SI_SUB_CLOCKS = 0x4800000, /* real-time and stat clocks*/
At this stage, the clock configuration will be done, and the real-time
clock can be used.
In the e1000 driver, if the API safe_pause_* are called between
SI_SUB_CONFIGURE and SI_SUB_CLOCKS stages, it will choose the wrong
clock source. The API safe_pause_* uses “cold” the value of which is
updated in SI_SUB_CONFIGURE, to decide if the real-time clock source is
ready. However, the real-time clock is not ready til the SI_SUB_CLOCKS
routines are done.
Obtained from: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D42920
(cherry picked from commit 930a1e6f3d2dd629774f1b48b1acf7ba482ab659)
As a consequence now ice_alloc_vsi_qmap() does not fail. Remove unneeded
error checks.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D45852
(cherry picked from commit 5f97656fa334b494d70866cb1bfff406d3efd92d)
