#
17996960 |
| 31-Jul-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r363583 through r363738.
|
#
855e49f3 |
| 27-Jul-2020 |
Alexander Motin <mav@FreeBSD.org> |
Add initial driver for ACPI Platform Error Interfaces.
APEI allows platform to report different kinds of errors to OS in several ways. We've found that Supermicro X10/X11 motherboards report PCIe e
Add initial driver for ACPI Platform Error Interfaces.
APEI allows platform to report different kinds of errors to OS in several ways. We've found that Supermicro X10/X11 motherboards report PCIe errors appearing on hot-unplug via this interface using NMI. Without respective driver it ended up in kernel panic without any additional information.
This driver introduces support for the APEI Generic Hardware Error Source reporting via NMI, SCI or polling. It decodes the reported errors and either pass them to pci(4) for processing or just logs otherwise. Errors marked as fatal still end up in kernel panic, but some more informative.
When somebody get to native PCIe AER support implementation both of the reporting mechanisms should get common error recovery code. Since in our case errors happen when the device is already gone, there is nothing to recover, so the code just clears the error statuses, practically ignoring the otherwise destructive NMIs in nicer way.
MFC after: 2 weeks Relnotes: yes Sponsored by: iXsystems, Inc.
show more ...
|
#
4cee4598 |
| 26-Jun-2020 |
Alexander Motin <mav@FreeBSD.org> |
Add mostly dummy hw.pci.enable_aspm tunable.
The only thing this tunable enables now is reporting to ACPI _OSC that Active State Power Management and Clock Power Management Capability are "supported
Add mostly dummy hw.pci.enable_aspm tunable.
The only thing this tunable enables now is reporting to ACPI _OSC that Active State Power Management and Clock Power Management Capability are "supported" by the OS.
I've found that at least some Supermicro server boards do not allow OS to support native PCIe hot-plug unless it reports those capabilities. After spending significant time in PCIe specs I have found very little motivation for that, and none of it applies to those motherboards, not enabling ASPM themselves. So unless OS explicitly wants to save power, I see nothing for it to do there actually.
I guess it may get sense to support ASPM when we get Thunderbolt support. Otherwise I have no system with PCIe hot-plug where power saving matters.
It would be nice to enable this by default, but I worry that it affect power saving of some laptops, even though I haven't noticed that myself.
show more ...
|
Revision tags: release/11.4.0 |
|
#
cffd37da |
| 29-May-2020 |
Andriy Gapon <avg@FreeBSD.org> |
do not enable pci bridge decoding on resume until I/O windows are restored
PCI bus driver restores most but not all of a child PCI-PCI bridge configuration. The bridge's I/O windows are restored by
do not enable pci bridge decoding on resume until I/O windows are restored
PCI bus driver restores most but not all of a child PCI-PCI bridge configuration. The bridge's I/O windows are restored by pcib driver and that happens later in time. This can be problematic because the Command register is restored before the windows are restored. If the firmware programs the windows incorrectly or even does not program them at all, then the bridge can start claiming I/O cycles that are not intended for it. This will continue until the correct windows are restored.
I have observed this problem with a buggy BIOS where after resuming from S3 an I/O port window of a PCI-PCI bridge was configured with zero base and limit causing the bridge to claim 0x0 - 0xFFF port range. That interfered with ACPI port access including ACPI PM Timer at port 0x808, thus wreaking havoc in the time keeping.
The solution is to restore the Command register of PCI-PCI bridges after the windows are restored in pcib driver. While here, I decided that for other PCI device types (normal and cardbus) it's better to restore the Command register after their BARs are restored.
To do: per jhb's suggestion, move the window handling to pci driver.
Reviewed by: imp, jhb, kib MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D25028
show more ...
|
#
43843cc2 |
| 26-May-2020 |
Ruslan Bukin <br@FreeBSD.org> |
Rename dmar_get_dma_tag() to acpi_iommu_get_dma_tag(). This is needed for a new IOMMU controller support.
Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D24943
|
#
a8f48cf8 |
| 18-Mar-2020 |
Navdeep Parhar <np@FreeBSD.org> |
Remove spurious warning about invalid VPD data.
The warning used to be displayed for valid VPDs about 512B or above in size. Fix the size check and add a break while here so that the routine stops
Remove spurious warning about invalid VPD data.
The warning used to be displayed for valid VPDs about 512B or above in size. Fix the size check and add a break while here so that the routine stops if if detects any problem.
Tested with "pciconf -lV"
Reviewed by: kib@, jhb@ MFC after: 1 week Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D23679
show more ...
|
#
3c4ad300 |
| 17-Feb-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r358000 through r358048.
|
#
59e4be22 |
| 16-Feb-2020 |
Pawel Biernacki <kaktus@FreeBSD.org> |
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (5 of many)
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marke
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (5 of many)
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags.
Reviewed by: imp, kib Approved by: kib (mentor) Differential Revision: https://reviews.freebsd.org/D23633
show more ...
|
#
484651cd |
| 19-Dec-2019 |
Mark Peek <mp@FreeBSD.org> |
Remove VMware MSI-X from the PCI blacklist.
First reported against ESXi 5.0, PCI passthrough was not working due to MSI-X issues. However, this issue was fixed via patch releases against ESXi 5.5 an
Remove VMware MSI-X from the PCI blacklist.
First reported against ESXi 5.0, PCI passthrough was not working due to MSI-X issues. However, this issue was fixed via patch releases against ESXi 5.5 and 6.0 in 2016. Given ESXi 5.5 and earlier have been EOL, this patch removes the VMware MSI-X blacklist entries in the quirk table.
PR: 203874 Reviewed by: imp, jhb MFC after: 1 month Sponsored by: VMware Differential Revision: https://reviews.freebsd.org/D22819
show more ...
|
#
96b506a5 |
| 24-Nov-2019 |
Warner Losh <imp@FreeBSD.org> |
Hoist locking giant back up into the ioctl handler
Move the locking back into the ioctl handler. This "fixes" the race where we hve a hot plug event just after the dropping of Giant in pci_find_dbsf
Hoist locking giant back up into the ioctl handler
Move the locking back into the ioctl handler. This "fixes" the race where we hve a hot plug event just after the dropping of Giant in pci_find_dbsf, assuming the driver doesn't then call anything that drops and picks up Giant again... It's a little safer since don't think it doesn't, but we lack the tools to know for sure.
show more ...
|
#
dd615d09 |
| 24-Nov-2019 |
Warner Losh <imp@FreeBSD.org> |
Push Giant down one layer
The /dev/pci device doesn't need GIANT, per se. However, one routine that it calls, pci_find_dbsf implicitly does. It walks a list that can change when PCI scans a new bus.
Push Giant down one layer
The /dev/pci device doesn't need GIANT, per se. However, one routine that it calls, pci_find_dbsf implicitly does. It walks a list that can change when PCI scans a new bus. With hotplug, this means we could have a race with that scanning. To prevent that, take out Giant around scanning the list.
However, given that we have places in the tree that drop giant, if held when we call into them, the whole use of Giant to protect newbus may be less effective that we desire, so add a comment about why we're talking it out, and we'll address the issue when we lock newbus with something other than Giant.
show more ...
|
Revision tags: release/12.1.0 |
|
#
21d31962 |
| 15-Oct-2019 |
John Baldwin <jhb@FreeBSD.org> |
Export pci_attach() and pci_detach().
Reviewed by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D21948
|
#
a63915c2 |
| 28-Jul-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @r350386
Sponsored by: The FreeBSD Foundation
|
#
e64f3dee |
| 08-Jul-2019 |
Warner Losh <imp@FreeBSD.org> |
Work around devices which return all zeros for reads of existing MSI-X table VCTRL registers.
Unconditionally program the MSI-X vector control Mask field for MSI-X table entries without regarud for
Work around devices which return all zeros for reads of existing MSI-X table VCTRL registers.
Unconditionally program the MSI-X vector control Mask field for MSI-X table entries without regarud for Mask's previous value. Some devices return all zeros on reads of the VCTRL registers, which would cause us to skip disabling interrupts. This fixes the Samsung SM961/PM961 SSDs which are return zero starting from offset 0x3084 within the memory region specified by BAR0, even when they are active MSI-X vectors.
The Illumos kernel writes these unconditionally to 0 or 1. However, section 6.8.2.9 of the PCI Local Bus 3.0 spec (dated Feb 3, 2004) states for bits 31::01: After reset, the state of these bits must be 0. However, for potential future use, software must preserve the value of these reserved bits when modifying the value of other Vector Control bits. If software modifies the value of these reserved bits, the result is undefined." so we always set or clear the Mask bit, but otherwise preserves the old value.
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211713 Reviewed By: imp, jhb Submitted by: Ka Ho Ng MFC After: 1 week Differential Revision: https://reviews.freebsd.org/D20873
show more ...
|
Revision tags: release/11.3.0 |
|
#
0269ae4c |
| 06-Jun-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @348740
Sponsored by: The FreeBSD Foundation
|
#
e2e050c8 |
| 20-May-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Extract eventfilter declarations to sys/_eventfilter.h
This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h" in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces hea
Extract eventfilter declarations to sys/_eventfilter.h
This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h" in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces header pollution substantially.
EVENTHANDLER_DECLARE and EVENTHANDLER_LIST_DECLAREs were moved out of .c files into appropriate headers (e.g., sys/proc.h, powernv/opal.h).
As a side effect of reduced header pollution, many .c files and headers no longer contain needed definitions. The remainder of the patch addresses adding appropriate includes to fix those files.
LOCK_DEBUG and LOCK_FILE_LINE_ARG are moved to sys/_lock.h, as required by sys/mutex.h since r326106 (but silently protected by header pollution prior to this change).
No functional change (intended). Of course, any out of tree modules that relied on header pollution for sys/eventhandler.h, sys/lock.h, or sys/mutex.h inclusion need to be fixed. __FreeBSD_version has been bumped.
show more ...
|
#
7648bc9f |
| 13-May-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @347527
Sponsored by: The FreeBSD Foundation
|
#
96ca24dc |
| 19-Apr-2019 |
Tycho Nightingale <tychon@FreeBSD.org> |
remove the 4GB boundary requirement on PCI DMA segments
Reviewed by: kib Discussed with: jhb Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D19867
|
#
ca19084f |
| 07-Apr-2019 |
Konstantin Belousov <kib@FreeBSD.org> |
Give new home to the comment from ppt_pci_reset(), explaining a nuance of power reset.
Noted by: soralx@cydem.org Sponsored by: Mellanox Technologies MFC after: 12 days
|
#
5db2a4a8 |
| 05-Apr-2019 |
Konstantin Belousov <kib@FreeBSD.org> |
Implement resets for PCI buses and PCIe bridges.
For PCI device (i.e. child of a PCI bus), reset tries FLR if implemented and worked, and falls to power reset otherwise.
For PCIe bus (child of a PC
Implement resets for PCI buses and PCIe bridges.
For PCI device (i.e. child of a PCI bus), reset tries FLR if implemented and worked, and falls to power reset otherwise.
For PCIe bus (child of a PCIe bridge or root port), reset disables PCIe link and then re-trains it, performing what is known as link-level reset.
Reviewed by: imp (previous version), jhb (previous version) Sponsored by: Mellanox Technologies MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D19646
show more ...
|
#
9a696dc6 |
| 04-Apr-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead@r345880
|
#
b2bbb744 |
| 01-Apr-2019 |
Tycho Nightingale <tychon@FreeBSD.org> |
Devices behind downstream bridges should still get DMAR protection.
Reviewed by: kib Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D19717
|
#
c981cbbd |
| 15-Feb-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r343956 through r344177.
|
#
967b2dce |
| 11-Feb-2019 |
John Baldwin <jhb@FreeBSD.org> |
Enable PCI BAR reallocation by default.
When pci_realloc_bars was first added, the intention was to eventually enable it by default, but it was left disabled to preserve existing behavior. The sett
Enable PCI BAR reallocation by default.
When pci_realloc_bars was first added, the intention was to eventually enable it by default, but it was left disabled to preserve existing behavior. The setting is pretty conservative in that it does not attempt to allocate resources for BARs that the BIOS/firmware leaves disabled. It only attempts to reallocate resources for a BAR that the firmware programmed during boot but that conflicts with another resource during the kernel's device scan.
PR 221350 is an example of a machine that this knob fixes.
Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D18965
show more ...
|
#
82a5a275 |
| 17-Dec-2018 |
Andriy Gapon <avg@FreeBSD.org> |
add support for marking interrupt handlers as suspended
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 t
add support for marking interrupt handlers as suspended
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
show more ...
|