Approved by: so Security: FreeBSD-EN-25:11.ena (cherry picked from commit 59b30c1a864ee8a22c2e9912301cb88674f714c9) (cherry picked from commit a1685d25601ee7abfaf6d6a993932ae3318e070e)
Patch 0a33c047a443 introduced new values to
hw.ena.force_large_llq_header. The default value of 2 means no
preference, while 0 and 1 act as the previous false and true
respectively, which allowed forcefully setting regular or large LLQ.
There are 2 ways to force the driver to select regular LLQ:
1. Setting hw.ena.force_large_llq_header = 0 via sysctl.
2. Turning on ena express, which makes the recommendation by the FW to
be regular LLQ.
When the device supports large LLQ but the driver is forced to
regular LLQ, llq_config->llq_ring_entry_size_value is never initialized
and since it is a variable allocated on the stack, it stays garbage.
Since this variable is involved in calculating max_entries_in_tx_burst,
it could cause the maximum burst size to be zero. This causes the driver
to ignore the real maximum burst size of the device, leading to driver
resets in devices that have a maximum burst size (Nitro v4 and on. see
[1] for more information).
In case the garbage value is 0, the calculation of
max_entries_in_tx_burst divides by 0 and causes kernel panic.
The patch modifies the logic to take into account all use-cases and
ensure that the relevant fields are properly initialized.
[1]: https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html
Fixes: 0a33c047a443 ("ena: Support LLQ entry size recommendation from device")
Sponsored by: Amazon, Inc.
Differential Revision: https://reviews.freebsd.org/D50040
Approved by: so
Security: FreeBSD-EN-25:11.ena
(cherry picked from commit 56c45700f2ae15755358f2da8266247613c564df)
(cherry picked from commit 3f4a674a8ee430dec7c72c45ffe759eabefa7a1f)
Approved by: re (cperciva) MFC after: 3 days Reviewed by: ray Differential Revision: https://reviews.freebsd.org/D47570 (cherry picked from commit 79af8f72b3aff993703778423e83320df0953a37) (cherry picked from commit 3bcbd391dd7e1376ab7ad37e94f5b746abfc0591)
Approved by: re (cperciva) PR: 282389 MFC after: 3 days (cherry picked from commit bab5e3d468305928e9e5cf1ca9efcee4c89f6a76) (cherry picked from commit 5cc7196a81fe6924a2994a1efc31468ad045b0ce)
Some iichid(4) child devices, currently hkbd(4) only, opens parent device in their attach handlers. That breaks internal iichid(4) state leading to rejecting any incoming data on software and hardware levels. Fix it with adding of extra state check in iichid(4) attach handler. Approved by: re (cperciva) Reported by: many Submitted by: trasz (initial version) PR: 280290 MFC after: 3 days (cherry picked from commit 018cb11cb7d412b031e1be681a6a19e734473f99) (cherry picked from commit c53ec86f0ee97f07f80c0902b189c845bf448e7d)
386BSD provided a MD function sysbeep. This took two arguments (pitch
and period). Pitch was jammed into the PIT's divisor directly (which
means the argument was expected to sound a tone at '1193182 / pitch'
Hz). FreeBSD inherited this interface.
In commit e46598588587 (svn 177642, Mar 26 2008), phk changed this
function to take a tone to sound in hz. He converted all in-tree
instances of 1193182 / hz to just hz (and kept the few misguided folks
that passed hz directly unchanged -- this was part of what motivated the
change). He converted the places where we pre-computed the 8254 divisor
from being pitch to 1193182 / pitch (since that converts the divisor to
the frequency and the interfaces that were exposed to userland exposed
it in these units in places, continuing the tradition inherited from SCO
System V/386 Unix in spots).
In 2009, Ed Shouten was contracted by the FreeBSD Foundation to write /
finish newcons. This work was done in perforce and was imported into
subversion in user/ed/newcons in revision 199072
(https://svnweb.freebsd.org/base?view=revision&revision=199072) which
was later imported into FreeBSD by ray@ (Aleksandr Rybalko).
From that earliest import into svn import to this date, we ring the bell
with:
sysbeep(1193182 / VT_BELLPITCH, VT_BELLDURATION);
where VT_BELLPITCH was defined to be 800. This results in a bell
frequency of 1491Hz, more or less today. This is similar to the
frequency that syscons and pcvt used (1493Hz and 1500Hz respectively).
This in turn was inherited from 386BSD, it seems, which used the hard
coded value 0x31b which is 795 -> 1500Hz.
This '800' was intended to be the bell tone (eg 800Hz) and this
interface was one that wasn't converted. The most common terminal prior
to the rise of PCs was the VT100, which had an approximately 800Hz
bell. Ed Shouten has confirmed that the original intent was 800Hz and
changing this was overlooked after the change to -current was made.
This restors that original intent and makes the bell less obnoxious in
the process.
Reviewed by: des, adrian
Differential Revision: https://reviews.freebsd.org/D32594
Sponsored by: Netflix
(cherry picked from commit ba48d52ca6c867559156dd916631f9ac47abe80f)
This change was accidentally reverted in 80f21bb039ce.
(cherry picked from commit 2416be588ea113cc06b924ed85861ed3bc391fe0)
(cherry picked from commit 1c9f1cb4f0a71bef37796a8ba139b86cc716ee88)
Approved by: re (cperciva)
Changes to acpi_gpiobus.c handle discovering and parsing the _AEI objects and storing necessary data in device ivars. A new gpioaei.c file implements the device, which simply requests an interrupt when the pin is triggered and invokes the appropriate _Exx or _Lxx ACPI method. This makes the GPIO "power button" work on arm64 Graviton systems, allowing EC2 "Stop"/"Reboot" instance calls to be handled cleanly. (Prior to this change, those requests would time out after 4 minutes and the instance would be forcibly killed.) Reviewed by: imp, andrew, Ahmad Khalifa Approved by: re (kib) MFC after: 3 days Sponsored by: Amazon Differential Revision: https://reviews.freebsd.org/D47253 Co-authored-by: Andrew Turner <andrew@FreeBSD.org> (cherry picked from commit 9709bda03cd0f20eba0ba4276fc3c2e06354a54f) (cherry picked from commit c2cd78d9446ebe79accf6c1862230dfbe7276525)
GPIO interrupts work just fine and will be used shortly. We still do not support GPIO_INTR_SHAREABLE however, so leave that within the NOT_YET scope. Reviwed by: andrew Approved by: re (kib) MFC after: 1 week Sponsored by: Amazon Differential Revision: https://reviews.freebsd.org/D47251 (cherry picked from commit 2d4219919a48aa6d67ae62e2b8859ffe3b035bd2) (cherry picked from commit 1f6941760746367704c9f1fa730a00b99d4d46b2)
This allows acpi_gpiobus to override the method and fall back to the generic gpiobus_read_ivar function if needed. Reviewed by: andrew Approved by: re (kib) MFC after: 1 week Sponsored by: Amazon Differential Revision: https://reviews.freebsd.org/D47250 (cherry picked from commit bc0d10d01c3c69004d600e14d53cd0dceffe4b09) (cherry picked from commit fffdfe2f6770946bb5d5204df0a97105e1dceccb)
AWS Graviton [1234] systems have a bug in their ACPI where they mark the PL061's GPIO pins as needing to be configured in PullUp mode (in fact the PL061 has no pullup/pulldown resistors); this flag needs to be removed in order for _AEI objects to be handled on these systems. Reviewed by: Ali Saidi Approved by: re (kib) MFC after: 1 week Sponsored by: Amazon Differential Revision: https://reviews.freebsd.org/D47239 (cherry picked from commit 2f3f867ac6dd7ff3769366b828b79c44b38828e1) (cherry picked from commit 5fa51c3653b14b364e26a4cce2733c7be6ee7721)