Some AMD systems I have report 8 NMI and 3591 polled error sources.
Previous code could handle only one NMI source and used separate
callout for each polled source. New code can handle multiple NMIs
and groups polled sources by power of 2 of the polling period.
MFC after: 2 weeks
This reverts commit 266f97b5e9, reversing
changes made to a10253cffe.
A mismerge of a merge to catch up to main resulted in files being
committed which should not have been.
Port 9781c28c6d and a8837c77ef to the mps driver. Before this
change devq was frozen only if some command was sent to the target after
reset started, but release was called always. This change freezes the
devq immediately, leaving mprsas_action_scsiio() check only to cover
race condition due to different lock devq use.
This should also avoid unnecessary requeue of the commands, creating
additional log noise and confusing some broken apps. It also avoids a
'busy' requeue of I/Os failing when we're doing recovery that takes
longer than the normal busy timeout. These I/Os failing can lead to
filesystems being unmounted in the force unmount case for I/O errors.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D33228
Add driver for TMP461 thermal sensor. Register new sysctl node
of integer type for device. Read register and fill sysctl with
valid temperature.
Reviewed by:
Sponsored by: Alstom
Obtained from: Semihalf
Differential revision: https://reviews.freebsd.org/D32818
Similarly to the other Intel drivers, don't try to process
RX checksum offloads when this feature (IFCAP_RXCSUM) is
disabled.
Reviewed by: gallatin, kbowling, erj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D33155
The ifp (struct ifnet) backpointer in the e1000 private ifnet
data is not used anymore since the iflib transition.
Remove it so that developers are not tempted to use it and
get a NULL pointer dereference.
Reviewed by: markj, kbowling, erj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D33157
While it still looks like previous code worked by coincidence, this
change broke things even more instead of fixing.
Reported by: avg@
MFC after: 1 week
The vast majority of the busy/unbusy users in the tree don't acquire
Giant before calling device_busy/unbusy. However, if multiple threads
are opening a file, say, that causes the device to busy/unbusy, then we
can race to the root marking things busy. Move to using a reference
count to keep track of how many times a device_t has been made busy. Use
that count to make the same decisions that we'd make with the old device
state.
Note: gpiopps.c uses D_TRACKCLOSE. Others do as well. However, there's a
known race with closes that will be corrected for all the drivers that
do this in a future commit.
Sponsored by: Netflix
Reviewed by: hselasky, jhb
Differential Revision: https://reviews.freebsd.org/D26284
This reverts commit 08e7819153.
Commit message was for a very old version of the patch. Will re-commit
with the right one since it's so bad. There's no locked versions of
it...that code was reworked to use refcnt APIs.
Noticed by: jhb, jtrc27
Sponsored by: Netflix
The vast majority of the busy/unbusy users in the tree don't acquire Giant
before calling device_busy/unbusy. However, if multiple threads are opening a
file, say, that causes the device to busy/unbusy, then we can race to the root
marking things busy. Create a new device_busy_locked and device_unbusy_locked
that are the current implemntations of device_busy and device_unbusy. Make
device_busy and unbusy acquire Giant before calling the _locked versrions. Since
we never sleep in the busy/unbusy path, Giant's single threaded semantics
suffice to keep this safe.
Sponsored by: Netflix
Reviewed by: hselasky, jhb
Differential Revision: https://reviews.freebsd.org/D26284
in sampling mode to workaround firmware bug.
This fixes reboot or poweroff on frame.work laptops after first touch.
Reported by: many
PR: 259230
MFC after: 1 week
Tested by: kevans, markj
This was found while looking for driver_filter_t functions which got the
trap frame from the argument. This particular instance it isn't even
used, so remove now lest someone else get to it first.
Reviewed by: mhorne
NXP FlexSPI is a complex SPI controller which provides
full offload for accessing NOR Flash.
Create a Flash driver which attaches to existing FreeBSD
infrastructure and exports generic READ and WRITE disk commands.
The Flash has to be identified first to configure controller
internals. For now, only one NOR Flash chip is supported.
Future commits shall either increase number of known chips
or implement SFDP mechanism which can be used by other Flash
drivers.
Sponsored by: Alstom
Obtained from: Semihalf
Differential revision: https://reviews.freebsd.org/D33117
HS200 and HS400 speeds can be enabled either with 1.2, or 1.8V signaling voltage.
Because of that we have four cabability flags: MMC_CAP_MMC_HS200_120,
MMC_CAP_MMC_HS200_180, MMC_CAP_MMC_HS400_120, MMC_CAP_MMC_HS400_180.
MMC logic only enables HS200/HS400 mode if both flags are set for the corresponding speed.
Fix that by being more permissive in host timing cap check.
Reviewed by: manu, mw
MFC after: 2 weeks
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D33130
In recent Hyper-V releases on Windows Server 2022, vPCI code does not
initialize the last 4 bit of device bar registers. This behavior change
could result weird problems cuasing PCI code failure when configuring
bars.
Just write all 1's to those bars whose probed values are not the same
as current read ones. This seems to make Hyper-V vPCI and
pci_write_bar() to cooperate correctly on these releases.
Reported by: khng@freebsd.org
Tested by: khng@freebsd.org
MFC after: 2 weeks
Sponsored by: Microsoft
Most prominently, add support for a transfer where a write with no-stop
flag is followed by a write with no-start flag. Logically, it's a
single larger write, but consumers may want to split it like that
because one part can be a register ID and the other part can be data to
be written to (or starting at) that register.
Such a transfer can be created by i2c tool and iic(4) driver, e.g., for
an EEPROM write at specific offset:
i2c -m tr -a 0x50 -d w -w 16 -o 0 -c 8 -v < /dev/random
This should be fixed by new code that handles the end of data transfer
for both reads and writes. It handles two existing conditions and one
new. Namely:
- the last message has been completed -- end of transfer;
- a message has been completed and the next one requires the start
condition;
- a message has been completed and the next one should be sent without
the start condition.
In the last case we simply switch to the next message and start sending
its data. Reads without the start condition are not supported yet,
though. That's because we NACK the last byte of the previous message,
so the device stops sending data. To fix this we will need to add a
look-ahead at the next message when handling the penultimate byte of the
current one.
This change also fixed a bug where msg_idx was not incremented after a
read message. Apparently, typically a read message is a last message in
a transfer, so the bug did not cause much trouble.
PR: 258994
MFC after: 3 weeks
Assert that we are not receiving data beyond the requested length.
Assert that we have not NACK-ed incoming data prematurely.
Abort the current transfer if the incoming data is NACK-ed or not
NACK-ed unexpectedly.
Add debug logging of received data to complement logging of sent data.
MFC after: 3 weeks
The write at the end of twsi_intr() already handles all cases, no need
to have another write for TWSI_STATUS_START / TWSI_STATUS_RPTD_START.
MFC after: 3 weeks
Previously the code set TWSI_CONTROL_ACK in twsi_transfer() based on
whether the first message had a length of one. That was done regardless
of whether the message was a read or write and what kind of messages
followed it.
Now the bit is set or cleared while handling TWSI_STATUS_ADDR_R_ACK
state transition based on the current (read) message.
The old code did not correctly work in a scenario where a single byte
was read from an EEPROM device with two byte addressing.
For example:
i2c -m tr -a 0x50 -d r -w 16 -o 0 -c 1 -v
The reason is that the first message (a write) has two bytes, so
TWSI_CONTROL_ACK was set and never cleared.
Since the controller did not send NACK the EEPROM sent more data resulting
in a buffer overrun.
While working on TWSI_STATUS_ADDR_R_ACK I also added support for
the zero-length read access and then I did the same for zero-length write
access.
While rare, those types of I2C transactions are completely valid and are
used by some devices.
PR: 258994
MFC after: 3 weeks
twsi_error() is a new function that stops the current transfer and sets
up softc when an error condition is detected.
TWSI_STATUS_DATA_WR_NACK, TWSI_STATUS_BUS_ERROR and
TWSI_STATUS_ARBITRATION_LOST are now handled explicitly rather than
via the catch-all unknown status.
Also, twsi_intr() now calls wakeup() in a single place when the
transfer is finished.
MFC after: 2 weeks
All accesses to softc are now done under a mutex to prevent data races
between the open context and the interrupt handler.
Additionally, the wait time in twsi_transfer is bounded now.
Previously we could get stuck there forever if an interrupt got lost.
MFC after: 2 weeks
Debug messages can now be enabled per driver instance via a new sysctl.
Also, debug messages in TWSI_READ and TWSI_WRITE require debug level
greater than 1 as they are mostly redundant because callers of those
functions already log most interesting results.
NB: the twsi drivers call their device iichb, so the new sysctl will
appear under dev.iichb.N.
MFC after: 1 week
Add a new ioctl to vt to make it possible to export RGB offsets
set by vt drivers. This is needed to fix colors on X and Mesa
on some machines, especially on modern PowerPC64 BE ones.
With the appropriate changes in SCFB, to use this ioctl to find
out the correct RGB offsets, this fixes wrong colors on Talos II
and Blackbird, when used with their built-in video cards.
Reviewed by: alfredo
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D29000
Currently agp(4) effectively assumes that only one driver instance
exists, as the generic attach routine attempts to create /dev/agpgart
and triggers a panic if it already exists. Instead, handle this
situation by creating /dev/agpgart<unit> and making /dev/agpgart an
alias of /dev/agpgart0 for compatibility.
PR: 187015
Reviewed by: imp, kib
Tested by: Yoshihiro Ota <ota@j.email.ne.jp> (earlier version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D33068
