History log of /freebsd/sys/dev/pci/pci.c (Results 51 – 75 of 1162)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


12345678910>>...47