In FreeBSD, this is normal situation that the Tx ring is being full. In
hat case, the packet is put back into drbr and the next attempt to send
it is taken after the cleanup.
Too much logs like this can cause system instability and even cause the
device reset (because keep alive or cleanup could be missed).
To fix that, the log level of this message is changed to debug.
Upon this change upgrade the driver version to v0.8.2.
Submitted by: Michal Krawczyk <mk@semihalf.com>
Obtained from: Semihalf
Sponsored by: Amazon, Inc.
upstream it seems).
The tlv variable was changed to a pointer but the advancement of the data pointer
was left as sizeof(tlv). While the sizeof the (now) pointer equals the
sizeof 2 x uint32_t (size of the struct) on 64bit platforms, on 32bit platforms
the size of the advancement of the data pointer was wrong leading to
firmware load issues.
Correctly advance the data pointer by the size of the structure and not by
the size of a pointer.
PR: 219683
Submitted by: waddlesplash gamil.com (Haiku) on irc
MFC after: 1 week
ccr reuses the control queue and first rx queue from the first port on
each adapter. The driver cannot send requests until those queues are
initialized. Refuse to create sessions for now if the queues aren't
ready. This is a workaround until cxgbe allocates one or more
dedicated queues for ccr.
PR: 233851
MFC after: 1 week
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D18478
o In vm_pager_bufferinit() create pbuf_zone and start accounting on how many
pbufs are we going to have set.
In various subsystems that are going to utilize pbufs create private zones
via call to pbuf_zsecond_create(). The latter calls uma_zsecond_create(),
and sets a limit on created zone. After startup preallocate pbufs according
to requirements of all pbuf zones.
Subsystems that used to have a private limit with old allocator now have
private pbuf zones: md(4), fusefs, NFS client, smbfs, VFS cluster, FFS,
swap, vnode pager.
The following subsystems use shared pbuf zone: cam(4), nvme(4), physio(9),
aio(4). They should have their private limits, but changing that is out of
scope of this commit.
o Fetch tunable value of kern.nswbuf from init_param2() and while here move
NSWBUF_MIN to opt_param.h and eliminate opt_swap.h, that was holding only
this option.
Default values aren't touched by this commit, but they probably should be
reviewed wrt to modern hardware.
This change removes a tight bottleneck from sendfile(2) operation, that
uses pbufs in vnode pager. Other pagers also would benefit from faster
allocation.
Together with: gallatin
Tested by: pho
Do not lose error condition by always returning 0 from set_led.
None of the calls to set_led checks for return value at the moment so
none of API consumers in base is affected.
PR: 231567
Submitted by: Bertrand Petit <bsdpr@phoe.frmug.org>
MFC after: 1 week
Family 15h is a bit of an oddball. Early models used the same temperature
register and spec (mostly[1]) as earlier CPU families.
Model 60h-6Fh and 70-7Fh use something more like Family 17h's Service
Management Network, communicating with it in a similar fashion. To support
them, add support for their version of SMU indirection to amdsmn(4) and use
it in amdtemp(4) on these models.
While here, clarify some of the deviceid macros in amdtemp(4) that were
added with arbitrary, incorrect family numbers, and remove ones that were
not used. Additionally, clarify intent and condition of heterogenous
multi-socket system detection.
[1]: 15h adds the "adjust range by -49°C if a certain condition is met,"
which previous families did not have.
Reported by: D. C. <tjoard AT gmail.com>
PR: 234657
Tested by: D. C. <tjoard AT gmail.com>
Extend the vendor class USB audio quirk to cover devices without
the USB audio control descriptor.
PR: 234794
MFC after: 1 week
Sponsored by: Mellanox Technologies
Issue:
ocs_fc(4) driver panics. It's induced by setting the port_state
sysctl to offline, then online, then offline, then online, and so
forth and so on in rapid succession.
Reason:
While we set the port_state to online fc discovery will start and OS
is enumerating the target discs by calling ocs_action(), then set the
port state to "offline" which deletes domain/sport/nodes.
In ocs_action()->XPT_GET_TRAN_SETTINGS we are accessing the remote
node which can be invalid to get the wwpn, wwnn and port.
Fix:
Removed accessing of remote node and domain in some ocs_action() cases.
Populated the required values from ocs_fcport.
This removes the dependency of node and domain structures while
processing XPT_PATH_INQ and XPT_GET_TRAN_SETTINGS.
We will invalidate the target entries after the device lost
timeout(30 seconds).
Approved by: ken, mav
MFC after: 3 weeks
The code is similar to the one for RTL8188E* and probably
should be shared with RTL8188CE (needs to be tested).
Checked with RTL8188CUS, STA mode.
MFC after: 5 days
- Remove macros that covertly create epoch_tracker on thread stack. Such
macros a quite unsafe, e.g. will produce a buggy code if same macro is
used in embedded scopes. Explicitly declare epoch_tracker always.
- Unmask interface list IFNET_RLOCK_NOSLEEP(), interface address list
IF_ADDR_RLOCK() and interface AF specific data IF_AFDATA_RLOCK() read
locking macros to what they actually are - the net_epoch.
Keeping them as is is very misleading. They all are named FOO_RLOCK(),
while they no longer have lock semantics. Now they allow recursion and
what's more important they now no longer guarantee protection against
their companion WLOCK macros.
Note: INP_HASH_RLOCK() has same problems, but not touched by this commit.
This is non functional mechanical change. The only functionally changed
functions are ni6_addrs() and ni6_store_addrs(), where we no longer enter
epoch recursively.
Discussed with: jtl, gallatin
Dell-branded Intel P4600 NVMe drives benefit from NVMe 1.3's NOIOB
feature. Unfortunately just like Intel DC P4500s, they don't advertise
themselves as benefiting from this...
This changes adds P4600s to the existing list of old drives which
benefit from striping.
PR: 233969
Submitted by: David Fugate <dave.fugate@gmail.com>
Reviewed by: imp, mav
Approved by: imp (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18772
setting the data prior to setting up the interrupt. Now we only set
the cookie afterwards, and that (a) cannot be helpd and (b) isn't used
in the ISR.
PR: 147127
Submitted by: hps@
On system with Celeron 1.5GHz CPU, sometimes when a PCMCIA to Compact Flash
adapter containing a Compact Flash card is inserted in the cardbus slot the
system hangs. This problem has not been observed in systems with a 2.8GHz
XEON CPU or faster.
Analysis of the cbb driver shows functional interrupts are routed to PCI
BEFORE the interrupt handler for functional interrupts has been registered.
Fix applied as described in the bug.
PR: 128040
Submitted by: Arthur Hartwig
Use BUS_DMA_NOWAIT for loads at initialization time.
Report actual numeric error code if any problem occurs at the
initialization.
Reported and tested by: pho
Reviewed by: mav
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D18741
tws_passthru() was doing a copyin of a user-specified request
without validating its length, so a malicious request could overrun
the buffer. By default, the tws(4) device file is only accessible
as root.
admbug: 825
Reported by: Anonymous of the Shellphish Grill Team
Reviewed by: delphij
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18536
out dead USB HUB devices by implementing an error counter, so that the USB
enumeration thread does not spend all its time reading from non-responding
devices, blocking user-space access in the end.
Tested by: Matthias Apitz <guru@unixarea.de>
MFC after: 1 week
Sponsored by: Mellanox Technologies
done on the old keyboard and then do the corresponding number of grabs
on the new keyboard.
This fixes a race that can leave the system with a non-functioning
keyboard. It goes like this...
- The bios claims there is an AT keyboard, atkbd attaches.
- SI_SUB_INT_CONFIG_HOOKS runs.
- USB probes devices. Devices begin attaching, including disks.
- GELI prompts for a password for a just-attached disk, which results
in a cngrab() while atkbd is the keyboard.
- A USB keyboard attaches.
- vt_upgrade() runs and switches the keyboard to the new USB keyboard,
but because cngrab was never called for it, it's not activated and
keystrokes are ignored.
- Now there is no functional keyboard and no way to get one; even
plugging in a different USB keyboard doesn't help, because the console
is still grabbed, still waiting for a GELI pw.
Discussed with: ray@
front-end doesn't support SDMA or the latter implements a platform-
specific transfer method instead. While at it, factor out allocation
and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to
keep the code more readable when adding support for ADMA variants.
o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum
of 512 KiB instead of using a fixed 4-KiB-buffer. With the default
MAXPHYS of 128 KiB and depending on the controller and medium, this
reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on
sequential reads while an increase of throughput of up to ~84 % was
seen.
Front-ends for broken controllers that only support an SDMA buffer
boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY
and supply a size via struct sdhci_slot. According to Linux, only
Qualcomm MSM-type SDHCI controllers are affected by this, though.
Requested by: Shreyank Amartya (unconditional bump to 512 KiB)
o Introduce a SDHCI_DEPEND macro for specifying the dependency of the
front-end modules on the sdhci(4) one and bump the module version
of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order
to ensure that all components are in sync WRT struct sdhci_slot.
o In sdhci(4):
- Make pointers const were applicable,
- replace a few device_printf(9) calls with slot_printf() for
consistency, and
- sync some local functions with their prototypes WRT static.
Previous code typically crashed in case of NVMe device unplug or even clean
detach while some I/Os are still in flight. To fix this the new code calls
disk_gone() and waits for confirmation of all references gone before calling
disk_destroy(), freeing other resources and allowing controller detach.
While there, fix disk lists locking and reimplement unit numbers assignment.
MFC after: 1 month
Sponsored by: iXsystems, Inc.
Due to hardware errata in Aero controllers, reads to certain
fusion registers could intermittently return all zeroes.
This behavior is transient in nature and subsequent reads will return
valid value.
Fix:
For Aero controllers, any read will retry the read operations
from certain registers for maximum three times, if read returns zero.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
For Aero adapters-
1. Driver will use 32 bit atomic descriptor to fire IOs and DCMDs.
2. Driver will use 64 bit request descriptor to fire IOC INIT.
3. If Aero firmware supports 32 bit atomic descriptor, then only driver will use it
otherwise driver will use 64 bit request descriptor.
For rest of adapters(Ventura, Invader and Thunderbolt), driver will use 64 bit request
descriptors only.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
Driver will throw a warning message when a Configurable secure type controller is
encountered.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
Due to HW Errta on Aero/Sea A0 chipset on secure boot mode & on heavy IO load,
sometimes read operation on MPT Fusion registers will give zero value,
So, as a workaround driver will retry the MPT Fusion register
read operation for max three times upon reading zero value form these
registers.
Submitted by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
Enable atomic type descriptor support only for Sea & Aero cards,
due to HW errata this atomic descriptor support has to be disabled
on Ventura cards.
Submitted by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
Added deviceID's for Sea,Aero to mpr Driver
Aero:
0x00E0 Invalid
0x00E1 Configurable Secure
0x00E2 Hard Secure
0x00E3 Tampered
Sea:
0x00E4 Invalid
0x00E5 Configurable Secure
0x00E6 Hard Secure
0x00E7 Tampered
For Tampered & Invalid type cards, driver will claim the device & quit the probe function with below error message,
"HBA is in Non Secure mode"
for Configurable Secure type cards, driver will display below message in .probe() callback function,
"HBA is in Configurable Secure mode"
Submitted by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
Following list of changes done in the driver as a part of TM handling on the NVMe drives.
Below changes are only applicable on NVMe drives and only when custom NVMe TM handling bit is set to zero by IOC.
1. Issue LUN reset & Target reset TMs with Target reset method field set to Protocol Level reset (0x3),
2. For LUN & target reset TMs use the timeout value as ControllerResetTO value provided by firmware using PCie Device Page 0,
3. If LUN reset fails to terminates the IO then directly escalate to host reset instead of going for target reset TM,
4. For Abort TM use the timeout value as NVMeAbortTO value given by the IOC using Manufacturing Page 11,
5. Log message "PCie Host Reset failed" message up on receiving P
Submitted by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
typedef struct mps_pass_thru
{
uint64_t PtrRequest;
uint64_t PtrReply;
uint64_t PtrData;
uint32_t RequestSize;
uint32_t ReplySize;
uint32_t DataSize;
uint32_t DataDirection;
uint64_t PtrDataOut;
uint32_t DataOutSize;
uint32_t Timeout;
} mps_pass_thru_t, * ptrmpssas_pass_thru_t;
In the above mps_pass_thru structure; Application expects PrtReply buffer
should contain both MPI reply followed by sense data. So, updated driver
to copy sense data at PtrReply + sizeof(MPI2 reply) location where
application wants the driver to copy back the sense data info.
Submitted by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
CAM does not require SIM lock since FreeBSD 10.4, and NVMe code never
required it at all, using per-queue locks instead. This formally allows
parallel request submission in CAM mode as much as single per-device and
per-queue locks of CAM allow.
MFC after: 1 month
g_io_deliver() finishing initialization of the bio, but g_io_deliver()
actually destroys the bio. INVARIANTS makes the bug obvious by
overwriting the bio with garbage.
Restore the old order for calling devstat (except don't restore not calling
it for the error case), and translate to the devstat KPI so that this order
works.
Reviewed by: kib
To check if txsync can be skipped, it is necessary to look for
unseen TX space. However, this means comparing ring->cur
against ring->tail, rather than ring->head against ring->tail
(like nm_ring_empty() does).
This change also adds some more comments to explain the optimization
performed at the beginning of netmap_poll().
MFC after: 3 days
Sponsored by: Sunny Valley Networks
The bug was introduced by r339639, although it is present in the upstream
netmap code since 2015. It is due to resetting the want_rx variable to
POLLIN, rather than resetting it to POLLIN|POLLRDNORM.
It only affects select(), which uses POLLRDNORM. poll() is not affected,
because it uses POLLIN.
Also, it only affects FreeBSD, because Linux skips the optimization
implemented by the piece of code where the bug occurs.
MFC after: 3 days
Sponsored by: Sunny Valley Networks
Add a generic mechanism to override mp?_wait_command's timeout behavior,
which continues to invoke reinit by default. Invokers who set
cm_timeout_handler may avoid automatic reinit and do their own handling.
Adapt mp?sas_get_sata_identify to this mechanism and remove its callout
hack.
Reviewed by: scottl
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D18614
In the event that the ID command timed out, mps(4)/mpr(4) did not free the
command until it could be cancelled. However, it freed the associated
buffer (cm_data). Fix the lifetime issue by freeing the associated buffer
only after Abort Task or controller reset.
Reviewed by: scottl
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D18612
This code validates the netmap buf_size against the interface MTU
and maximum descriptor size, to make sure the values are consistent.
Moving this functionality to its own function is needed because this
function is also called by Linux-specific code.
MFC after: 3 days
implement not double-caching for reads from vnode-backed md devices.
Use VOP_ADVISE() similarly instead of !IO_DIRECT unsimilarly for writes.
Add a "cache" option to mdconfig to allow changing the default of not
caching.
This depends on a recent commit to fix VOP_ADVISE(). A previous version
had optimizations for sequential i/o's (merge the i/o's and only uncache
for discontiguous i/o's and for full blocks), but optimizations and
knowledge of block boundaries belong in VOP_ADVISE(). Read-ahead should
also be handled better, by supporting it in md and discarding it in
VOP_ADVISE().
POSIX_FADV_DONTNEED is ignored by zfs, but so is IO_DIRECT.
POSIX_FADV_DONTNEED works better than IO_DIRECT if it is not ignored,
since it only discards from the buffer cache immediately, while
IO_DIRECT also discards from the page cache immediately.
IO_DIRECT was not used for writes since it was claimed to be too slow,
but most of the slowness for writes is from doing them synchronously by
default. Non-synchronous writes still deadlock in many cases.
IO_DIRECT only has a special implementation for ffs reads with DIRECTIO
configured. Otherwise, if it is not ignored than it uses the buffer and
page caches normally except for discarding everything after each i/o,
and then it has much the same overheads as POSIX_FADV_DONTNEED. The
overheads for reading with ffs and DIRECTIO were similar in tests of md.
Reviewed by: kib
Move static variable definition (cdevsw) to a more conventional location
(the C file it is used in), rather than a header.
This fixes the GCC warning, -Wunused-variable ("defined but not used") when
the tpm20.h header is included in files other than tpm20.c (e.g.,
tpm_tis.c).
X-MFC-with: r342084
Sponsored by: Dell EMC Isilon
On amd64 the RSP address can be read in single 8-byte transaction,
which is obviously not possible on 32-bit platforms. Fix that
by performing 2 4-byte read on them.
Obtained from: Semihalf
Sponsored by: Stormshield
This fixes a warning seen when compiling amd64 GENERIC with clang 7.
Also remove the workaround added in r337324. clang 7 and gcc 4.2
generate the same code with or without the code change.
Reviewed by: imp (previous version)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D18603
- Fix PR 227760 by getting the TOE to respond to the SYN after the call
to toe_syncache_add, not during it. The kernel syncache code calls
syncache_respond just before syncache_insert. If the ACK to the
syncache_respond is processed in another thread it may run before the
syncache_insert and won't find the entry. Note that this affects only
t4_tom because it's the only driver trying to insert and expand
syncache entries from different threads.
- Do not leak resources if an embryonic connection terminates at
SYN_RCVD because of L2 lookup failures.
- Retire lctx->synq and associated code because there is never a need to
walk the list of embryonic connections associated with a listener.
The per-tid state is still called a synq entry in the driver even
though the synq itself is now gone.
PR: 227760
MFC after: 2 weeks
Sponsored by: Chelsio Communications
Those should ensure correctness of ichwd_find_ich_lpc_bridge() and
ichwd_find_ich_lpc_bridge() as well as make it easier for both humans
and static analyzers to see the relation between tco_version and ich and
smb variables in ichwd_identify().
Reported by: Coverity
CID: 1396314, 1396317
MFC after: 10 days
The code is unreachable since the entries of radeon_ioctls[] are not
associated with any device: we provide only the KMS entry points.
Moreover, r600_cp_dispatch_texture() contains an integer overflow bug
that can be triggered from userspace.[1]
Reported by: Anonymous of the Shellphish Grill Team[1]
Reviewed by: dumbbell
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18516
This includes removing stray whitespace, adding a line after the
variable declaration block and removing a redundant check.
MFC after: 1 week
X-MFC with: r339754
In testing on a Dell Latitude 7480, having ig4.ko loaded during a
suspend caused the system to hang. It turns out that ig4iic_intr() was
being called after the device entered D3, and entered an infinite loop
because a read of the I2C status register returned all ones, causing us
to attempt to read a byte from the data buffer until one of the status
bits clears. This occured because ig4iic_pci0 shares an interrupt with
the VGA device on this laptop, so ig4iic_intr() gets called even when
there is no work to do. This is exactly the problem fixed by r342170,
which resolves the hang for me and allows suspend/resume to work with
ig4.ko loaded. So, re-enable autoloading of ig4.ko in the hope that
r342170 resolves the problem universally.
Reviewed by: gonzo
MFC after: 1 month (pending an MFC of r342170)
Differential Revision: https://reviews.freebsd.org/D18587
The goal of this change is to fix a problem with PCI shared interrupts
during suspend and resume.
I have observed a couple of variations of the following scenario.
Devices A and B are on the same PCI bus and share the same interrupt.
Device A's driver is suspended first and the device is powered down.
Device B generates an interrupt. Interrupt handlers of both drivers are
called. Device A's interrupt handler accesses registers of the powered
down device and gets back bogus values (I assume all 0xff). That data is
interpreted as interrupt status bits, etc. So, the interrupt handler
gets confused and may produce some noise or enter an infinite loop, etc.
This change affects only PCI devices. The pci(4) bus driver marks a
child's interrupt handler as suspended after the child's suspend method
is called and before the device is powered down. This is done only for
traditional PCI interrupts, because only they can be shared.
At the moment the change is only for x86.
Notable changes in core subsystems / interfaces:
- BUS_SUSPEND_INTR and BUS_RESUME_INTR methods are added to bus
interface along with convenience functions bus_suspend_intr and
bus_resume_intr;
- rman_set_irq_cookie and rman_get_irq_cookie functions are added to
provide a way to associate an interrupt resource with an interrupt
cookie;
- intr_event_suspend_handler and intr_event_resume_handler functions
are added to the MI interrupt handler interface.
I added two new interrupt handler flags, IH_SUSP and IH_CHANGED, to
implement the new intr_event functions. IH_SUSP marks a suspended
interrupt handler. IH_CHANGED is used to implement a barrier that
ensures that a change to the interrupt handler's state is visible
to future interrupts.
While there, I fixed some whitespace issues in comments and changed a
couple of logically boolean variables to be bool.
MFC after: 1 month (maybe)
Differential Revision: https://reviews.freebsd.org/D15755
PR: maybe related to 233998 (inconclusive at this time)
Submitted by: byuu <byuu AT tutanota.com> (previous version)
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D18506
It was written basing on:
TCG PC Client Platform TPM Profile (PTP) Specification Version 22, Revision 1.03.
It only supports Locality 0. Interrupts are only supported in FIFO mode.
The driver in FIFO mode was tested on x86 with Infineon SLB9665 discrete TPM chip.
Driver in both modes was also tested on qemu with swtpm running on host.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D18048
This is based on a patch developed by
Tetsuya Uemura <t_uemura@macome.co.jp>.
Many thanks!
Submitted by: Tetsuya Uemura <t_uemura@macome.co.jp> (earlier version)
Tested by: Tetsuya Uemura <t_uemura@macome.co.jp>
MFC after: 2 weeks
very minimal prints and even few important messages will not get logged.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
capable IOs. NVME specification supports specific type of scatter gather list
called as PRP (Physical Region Page) for IO data buffers. Since NVME drive is
connected behind SAS3.5 tri-mode adapter, MegaRAID driver/firmware has to convert
OS SGLs in native NVMe PRP format. For IOs sent to firmware, MegaRAID firmware
does this job of OS SGLs to PRP translation and send PRPs to backend NVME device.
For fastpath IOs, driver will do this OS SGLs to PRP translation.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
required Write IOs as Fast Path IOs (after the appropriate checks
allowing Fast Path to be used) to the appropriate physical drives
(translated from the OS logical IO) and wait for all Write IOs to complete.
Design: A write IO on RAID volume will be examined if it can be sent in
Fast Path based on IO size and starting LBA and ending LBA falling on to
a Physical Drive boundary. If the underlying RAID volume is a RAID 1/10,
driver issues two fast path write IOs one for each corresponding physical
drive after computing the corresponding start LBA for each physical drive.
Both write IOs will have the same payload and are posted to HW such that
replies land in the same reply queue.
If there are no resources available for sending two IOs, driver will send
the original IO from upper layer to RAID volume through the Firmware.
When both IOs are completed by HW, the resources will be released
and SCSI IO completion handler will be called.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
stream to help HBA Firmware do the Full Stripe Writes. For read IOs on
certain RAID volumes like Read Ahead volumes,this will help driver to
send it to Firmware even if the IOs can potentially be sent to
hardware directly (called fast path) bypassing firmware.
Design: 8 streams are maintained per RAID volume as per the combined
firmware/driver design. When there is no stream detected the LRU stream
is used for next potential stream and LRU/MRU map is updated to make this
as MRU stream. Every time a stream is detected the MRU map
is updated to make the current stream as MRU stream.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
for different number of supported VDs for SAS3.5 MegaRAID adapters.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: ken
MFC after: 3 days
Sponsored by: Broadcom Inc
In the nda(4) driver, only set DISKFLAG_CANDELETE (a.k.a. can support
BIO_DELETE) if the drive supports Dataset Management. There are reports
that without this check, VMWare Workstation does not work reliably.
Fix is to check the ONCS field in the NVMe Controller Data structure for
support. This check previously existed but did not survive the
big-endian changes.
Reported by: yuripv@yuripv.net
Reviewed by: imp, mav, jimharris
Approved by: imp (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D18493
The pwm subsystem consist of API for PWM controllers, pwmbus to register them
and a pwm(8) utility to talk to them from userland.
Reviewed by: oshgobo (capsicum), bcr (manpage), 0mp (manpage)
Differential Revision: https://reviews.freebsd.org/D17938
If bus_dmamap_load_mbuf() fails following a defrag, the caller of
bwn_dma_tx_start() would free the original mbuf after m_defrag() had
already done so. Fix this by returning the defragged mbuf to the
caller instead. Update bwn_pio_tx_start() similarly for consistency.
Reported by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Reviewed by: landonf
Tested by: landonf
MFC after: 3 days
admbug: 820
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18342
PR: 217505
Submitted by: John O. Brickley <obryan.brickley@gmail.com>, updated by Maciej Pasternacki <maciej@pasternacki.net>
Reported by: John O. Brickley <obryan.brickley@gmail.com>
MFC after: 1 week
initialize the controller.
According to the datasheet, the old code checks if port 2 (P2E, 0x4) was
the only enabled port (except port 0, which was ignored by mask 0xfe),
and issue a write to the PCS register to disable all but port 0, right
before ahci_ctlr_reset.
Some other operating systems would issue a port enable to all ports, but
since the current code only does the special initialization for ICH8M,
it entirely and rely on BIOS to do the right thing (the alternative
would be https://reviews.freebsd.org/D18300?id=50922 , should we see
reports that we really need to do it).
Reviewed by: mav
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D18300
On EF10 HW we can avoid sending packets without checksum offload
or with IP-only checksum offload to dedicated queues. Instead, we
can use option descriptors to change offload policy on any queue
during runtime. Thus, we don't need to create two dedicated queues.
Submitted by: Ivan Malov <Ivan.Malov at oktetlabs.ru>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18390
The number of Tx queues on event queue 0 can depend on the NIC family type,
and this property will be leveraged by future patches.
This patch prepares the code for this change.
Submitted by: Ivan Malov <Ivan.Malov at oktetlabs.ru>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18389
FreeBSD driver needs a patch to provide a means for packets
which do not need checksum offload but have flow ID set
to avoid hitting only the first Tx queue (which has been used
for packets not needing checksum offload).
This should be possible on Huntington, Medford or Medford2 chips
since these support toggling checksum offload on any given queue
dynamically by means of pushing option descriptors.
The patch for FreeBSD driver will then need a means to figure out
whether the feature can be used, and testing adapter family might
not be a good solution.
This patch adds a feature bit specifically to indicate support
for checksum option descriptors. The new feature bits may have
more users in future, apart from the mentioned FreeBSD patch.
Submitted by: Ivan Malov <Ivan.Malov at oktetlabs.ru>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18388
In order to find out why the first event queue and corresponding
interrupt is triggered more frequent, it is useful to know which
events go to each event queue.
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18418
devstat_end_transaction() was called before the i/o was actually ended
(by delivering it to GEOM), so at least the i/o length was messed up.
It was always recorded as 0, so the average transaction size and the
average transfer rate was always displayed as 0.
devstat_end_transaction() was not called at all for the error case, so
there were sometimes multiple starts per end. I didn't observe this in
practice and don't know if it did much damage. I think it extended the
length of the i/o to the next transaction.
Reviewed by: kib
ACPI SRAT table on arm64 uses GICC entries to provide CPU locality
information. These entries use an AcpiProcessorUid to identify the
CPU (unlike on x86 where the entries have an APIC ID).
Update acpi_pxm.c to extend the cpu_add/cpu_find/cpu_get_info
functions to handle AcpiProcessorUid. Use the updated functions
while parsing ACPI_SRAT_GICC_AFFINITY entry for arm64.
Also update sys/conf/files.arm64 to build acpi_pxm.c when ACPI is
enabled.
Reviewed by: markj (previous version)
Differential Revision: https://reviews.freebsd.org/D17942
This moves the architecture independent parts of sys/x86/acpica/srat.c
to sys/dev/acpica/acpi_pxm.c, to be used later on arm64. The function
declarations are moved to sys/dev/acpica/acpivar.h
We also need to update sys/conf/files.{i386,amd64} to use the new file.
No functional changes.
Reviewed by: markj, imp
Differential Revision: https://reviews.freebsd.org/D17941
Because of that typo the driver would try to attach to every device
on acpi bus. That disrupted acpi attachment of uart driver, at least.
MFC after: 4 days
X-MFC with: r339754
The iflib subsystem implements netmap support in a driver-independent
way (sys/net/iflib.c). We can therefore remove the headers that
used to implement netmap support for all the drivers now supported
by iflib (em, igb, ixl, ixgbe, lem).
MFC after: 1 week
through.
cxgb4vf doesn't own the buffer size list but still expects the first two
entries to be 4K and some power of 2 respectively. The BSD cxgbe
doesn't care where its preferred buffer sizes are as long as they're in
the list somewhere, so just move its entries towards the end as a
workaround.
MFC after: 1 month
Sponsored by: Chelsio Communicatons
Specifically, assume that the device is present if evaluation of _STA
method fails.
Before r330957 we ignored any _STA evaluation failure (which was
performed by AcpiGetObjectInfo in ACPICA contrib code) for the purpose
of acpi_DeviceIsPresent and acpi_BatteryIsPresent. ACPICA 20180313
removed evaluation of _STA from AcpiGetObjectInfo. So, we added
evaluation of _STA to acpi_DeviceIsPresent and acpi_BatteryIsPresent.
One important difference is that the new code ignored a failure only if
_STA did not exist (AE_NOT_FOUND). Any other kind of failure was
treated as a fatal failure. Apparently, on some systems we can get
AE_NOT_EXIST when evaluating _STA. And that error is not an evil twin
of AE_NOT_FOUND, despite a very similar name, but a distinct error
related to a missing handler for an ACPI operation region.
It's possible that for some people the problem was already fixed by
changes in ACPICA and/or in acpi_ec driver (or even in BIOS) that fixed
the AE_NOT_EXIST failure related to EC operation region.
This work is based on a great analysis by cem and an earlier patch by
Ali Abdallah <aliovx@gmail.com>.
PR: 227191
Reported by: 0mp
MFC after: 2 weeks
