This driver is based of the enic (Cisco VIC) DPDK driver. It provides
basic ethernet functionality. Has been run with various VIC cards to
do UEFI PXE boot with NFS root.
Some Elantech trackpads have a mangled HID report descriptor, which
reads as having an incorrect input size (i.e. < IETP_REPORT_LEN_LO).
If the input size is incorrect, load a dummy report descriptor.
Reviewed by: wulf
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38387
According to the Intel manual
https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.pdf
the Thermal Status (0) and Thermal Status Log (1) bits report only a
high temperature on the CPU, not a critical temperature as suggested in
the coretemp driver. Check the Critical Temperature Log (5) instead.
The critical temperature waives guarantees of correct function,
therefore the CPU could have for example written some wrong values into
memory at that point and the OS should be stopped ASAP as the state is
no longer reliable.
Reviewed by: imp (confirmed descriptions of bits, linux ignores these bits)
Pull Request: https://github.com/freebsd/freebsd-src/pull/562
- remove Huawei 3G E3131 (E3131_INIT):
- frees up 0x1505/0x14fe shared IDs => product is EOL (since...)
- 3G networks are shutdown/scheduled
- E3131 devices will still work the same via scsi_huawei_eject2
- new 4G devices will switch & report correctly now
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/633
Switch the now added E5573Cs322_ECM (0x14db) as well per default to NCM.
With this patch we default all devices to simple NCM mode to avoid the
problem and get a consistent reliable behavior. No matter what firmware
version and provider mix are involved.
Rationale:
Even the bigger SOC shows under complex load in ECM (double-nat) mode
the same performance drop from 25Mbit to 2Mbit Line Speed, similar to E3372h.
Reason: Thermal problems (reported via serial debug interface in ACM Mode)
after 2-3 minutes load.
Fix the root cause and bundle a working firmware is out of reach because
Huawei sells the same hardware, different (crippled) firmware versions
at different price points in different markets as strategy.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/633
Add initialization for new Huawei 4G E3372_NCM, E3372v153_NCM,
E5573Cs322_NCM, E5573Cs322_ECM, and E5573Cs322_ACM.
Remove now-obsolete Huawei 3G E3131 init sequence. These devices are
obsolete, share IDs with new devices and the 3G networks are shutdown.
These old devices work correctly via the 4G code while still allowing
the shared IDs to work differently for the new devices.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/633
DEFINE_ALLOC_MR became unconditionally true, but it isn't used anywhere
now. Several places depended upon DEFINE_IB_FAST_REG, but that is now
always false.
Similarly DEFINE_IB_UMEM_WITH_CHUNK became always false/undefined.
DEFINE_IB_AH_ATTR_WITH_DMAC is now unconditionally true.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/603
Differential Revision: https://reviews.freebsd.org/D35560
NIC input errors have traditionally indicated problems at the link
level (crc errors, runts, etc). People tend to build monitoring
infrastructure around such errors in order to monitor for bad network
hardware. When L3/L4 checksum errors are included in the category of
input errors, it breaks such monitoring, as these errors can originate
anywhere on the internet, and do not necessarily indicate faulty
local network hardware.
Reviewed by: erj, glebius
Differential Revision: https://reviews.freebsd.org/D38346
Sponsored by: Netflix
Jumping direct to ret was not restoring the saved value of x19 and was
also not adjusting sp to discard the two saved registers.
Reviewed by: andrew
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D37922
This patch does remaining enablement in hyperv vpci driver to work
on arm64 Hyper-V. For that it required to use PCI protocol 1.4 and
corresponding different PCI message handling. Also new MSI allocation,
MSI-X mapping, release.
This is the last patch of total three patches to enalbe Hyper-V vPCI
support in arm64.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Obtained from: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37958
This is enabling the PCI protocol 1.4 and corresponding structures
in order to support arm64 Hyper-V.
This is the 2nd of the three patches to enable Hyper-V vPCI support
in arm64.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Obtained from: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37780
