On 03/17/2013 06:28 PM, Alex Williamson wrote:
On Sun, 2013-03-17 at 08:33 -0600, Myron Stowe wrote:
On Sun, 2013-03-17 at 07:38 -0600, Alex Williamson wrote:
On Sat, 2013-03-16 at 22:36 -0700, Greg KH wrote:
On Sat, Mar 16, 2013 at 10:11:22PM -0600, Alex Williamson wrote:
On Sat, 2013-03-16
On 02/08/2013 02:28 PM, Yinghai Lu wrote:
iommu irq's irq_desc should be on local node ram.
Fix the return value checking problem.
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
here only check !irq, so need to change it to use create_ir
oblem.
Signed-off-by: Neil Horman
CC: Prarit Bhargava
CC: Don Zickus
CC: Don Dutile
CC: Bjorn Helgaas
CC: Asit Mallick
CC: David Woodhouse
CC: linux-...@vger.kernel.org
---
Change notes:
v2)
* Moved the quirk to the x86 arch, since consensus seems to be that the 55XX
chipset series is x86 only. I de
On 08/23/2012 12:36 PM, Matthew Garrett wrote:
Platforms may provide their own mechanisms for obtaining ROMs. Add support
for using data provided by the platform in that case.
Signed-off-by: Matthew Garrett
---
drivers/pci/rom.c | 11 +--
include/linux/pci.h | 2 ++
2 files change
On 10/02/2012 03:49 AM, Takao Indoh wrote:
These patches reset PCIe devices at boot time to address DMA problem on
kdump with iommu. When "reset_devices" is specified, a hot reset is
triggered on each PCIe root port and downstream port to reset its
downstream endpoint.
Background:
A kdump proble
On 10/03/2012 01:51 PM, Yinghai Lu wrote:
Will use it enable sriov for pci devices.
Signed-off-by: Yinghai Lu
---
include/linux/pci.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index be1de01..7d70a5e 100644
--- a/include/
On 10/03/2012 02:47 PM, Alexander Duyck wrote:
On 10/03/2012 10:51 AM, Yinghai Lu wrote:
Need ixgbe guys to close the loop to use set_max_vfs instead
kernel parameters.
Signed-off-by: Yinghai Lu
Cc: Jeff Kirsher
Cc: Jesse Brandeburg
Cc: Greg Rose
Cc: "David S. Miller"
Cc: John Fastabend
Cc: e10
On 10/03/2012 04:41 PM, Yinghai Lu wrote:
On Wed, Oct 3, 2012 at 11:55 AM, Don Dutile wrote:
On 10/03/2012 01:51 PM, Yinghai Lu wrote:
Will use it enable sriov for pci devices.
Signed-off-by: Yinghai Lu
---
include/linux/pci.h |1 +
1 files changed, 1 insertions(+), 0 deletions
On 07/27/2012 04:07 AM, Huang Ying wrote:
This patch adds ABI document for the following sysfs file:
/sys/bus/pci/devices/.../d3cold_allowed
Signed-off-by: Huang Ying
---
Documentation/ABI/testing/sysfs-bus-pci | 12
1 file changed, 12 insertions(+)
--- a/Documentation/ABI/te
On 07/30/2012 11:12 PM, Huang Ying wrote:
Hi, Don,
Thanks for your comments.
On Mon, 2012-07-30 at 14:03 -0400, Don Dutile wrote:
On 07/27/2012 04:07 AM, Huang Ying wrote:
This patch adds ABI document for the following sysfs file:
/sys/bus/pci/devices/.../d3cold_allowed
Signed-off-by
On 09/21/2012 02:22 AM, Yinghai Lu wrote:
On Thu, Sep 20, 2012 at 7:56 PM, Bjorn Helgaas wrote:
This is another thing I'm curious about. How do you handle this
situation today (before host bridge hot-add)?
The DMAR I'm not so worried about because as far as I know, there's no
such thing as a
On 09/14/2012 04:03 PM, Konrad Rzeszutek Wilk wrote:
As to the boot parameter to enable this function, you suggested using
reset_devices. I found that on a certain platform resetting devices
caused PCIe error due to a hardware bug. Therefore I think we need
new parameter apart from reset_devices
early quirk so that the chip devices/revisions
specified in the above update are also covered in the same way:
Signed-off-by: Neil Horman
Reviewed-by: Jan Beulich
CC: Jan Beulich
CC: Joerg Roedel
CC: Andrew Cooper
CC: Malcolm Crossley
CC: Prarit Bhargava
CC: Don Zickus
CC: Don Dutile
CC: Thomas
On 07/11/2013 05:43 AM, Yijing Wang wrote:
Introduce PCIe Ext Capability Device Serial Number support,
so we can use the unique device serial number to identify
the physical device. During system suspend, if the PCIe
device was removed and inserted a new same device, after
system resume there is
Sorry, did a 'reply' instead of 'reply all' on first reply to this patch...
excuse any repeat...
- Don
On 07/11/2013 05:43 AM, Yijing Wang wrote:
If device was removed from slot and reinsert a new device during
suspend, pciehp can not identify the physical device change now.
So the old driver .r
On 07/11/2013 04:09 PM, Bjorn Helgaas wrote:
On Thu, Jul 11, 2013 at 3:51 AM, Don Dutile wrote:
On 07/11/2013 05:43 AM, Yijing Wang wrote:
Introduce PCIe Ext Capability Device Serial Number support,
so we can use the unique device serial number to identify
the physical device. During system
On 07/11/2013 09:38 PM, Yijing Wang wrote:
Hi Don,
Thanks for your review and comments very much!
+dev->sn = pci_device_serial_number(dev);
+
Finally, 'the comment below':
I know you were following Bjorn's suggestion, which I thought
was an improvement, but why not do above assignment
On 07/08/2013 12:17 PM, Alex Williamson wrote:
Ping. Comments?
As I read the PCIe & SRIOV specs wrt ACS, this patch set appears
to fix the nuances we have learned about whether a device (MFD or bridge)
implements (the equiv. of) ACS, or not, as required (for secure, device
assignment).
Like t
On 10/09/2012 05:03 AM, Takao Indoh wrote:
(2012/10/03 22:23), Don Dutile wrote:
On 10/02/2012 03:49 AM, Takao Indoh wrote:
These patches reset PCIe devices at boot time to address DMA problem on
kdump with iommu. When "reset_devices" is specified, a hot reset is
triggered on each
On 11/09/2012 10:26 AM, Bjorn Helgaas wrote:
[+ linux-pci, Yinghai]
On Thu, Nov 8, 2012 at 8:59 PM, Jason Gao wrote:
The BIOS in your machine doesn't support SR-IOV. You'll need to ask the
manufacturer for a BIOS upgrade, if in fact one is available. Sometimes
they're not.
very thanks Gr
On 11/12/2012 04:26 AM, Doug Goldstein wrote:
On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
wrote:
System boots with vt-d disabled in bios. Otherwise I get the errors in
the attached log. I can do whatever testing you need as this system is
not in production yet. gonna paste the important p
On 11/13/2012 11:04 AM, Li, Sibai wrote:
-Original Message-
From: Jason Gao [mailto:pkill.2...@gmail.com]
Sent: Tuesday, November 13, 2012 5:38 AM
To: bhelg...@google.com; Rose, Gregory V; Li, Sibai
Cc: ddut...@redhat.com; Kirsher, Jeffrey T; linux-kernel; netdev; kvm; e1000-
de...@lis
On 11/13/2012 10:38 AM, Alex Williamson wrote:
On Mon, 2012-11-12 at 15:05 -0600, Matthew Thode wrote:
On 11/12/2012 01:57 PM, Don Dutile wrote:
On 11/12/2012 04:26 AM, Doug Goldstein wrote:
On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
wrote:
System boots with vt-d disabled in bios
lease see:
https://bugzilla.redhat.com/show_bug.cgi?id=887006
Signed-off-by: Neil Horman
CC: Prarit Bhargava
CC: Don Zickus
CC: Don Dutile
CC: Bjorn Helgaas
CC: Asit Mallick
CC: David Woodhouse
CC: linux-...@vger.kernel.org
CC: Joerg Roedel
CC: Konrad Rzeszutek Wilk
CC: Arkadiusz Miśkiewicz
---
C
On 04/18/2013 12:28 PM, Joerg Roedel wrote:
On Thu, Apr 18, 2013 at 11:13:19AM -0500, Suravee Suthikulanit wrote:
This workaround is required for both event log and ppr log. Your
patch is only taking care of the event log.
Right, thanks for the notice. Here is the updated patch.
From cebe04
On 06/11/2013 07:19 PM, Sumner, William wrote:
(2013/06/11 11:20), Bjorn Helgaas wrote:
On Fri, Jun 7, 2013 at 2:46 AM, Takao Indoh wrote:
(2013/06/07 13:14), Bjorn Helgaas wrote:
One thing I'm not sure about is that you are only resetting PCIe
devices, but I don't think the problem is ac
On 05/23/2013 08:35 PM, Li, Zhen-Hua wrote:
In Intel Vt-D specs, Chapter 9.3 Page-Table Entry,
The size of ADDR(address) field is 12:51, but the function dma_pte_addr
treats it as 12:63.
Signed-off-by: Li, Zhen-Hua
---
drivers/iommu/intel-iommu.c |4 ++--
include/linux/dma_remapping.h
On 05/30/2013 02:40 PM, Alex Williamson wrote:
PCIe ACS (Access Control Services) is the PCIe 2.0+ feature that
allows us to control whether transactions are allowed to be redirected
in various subnodes of a PCIe topology. For instance, if two
endpoints are below a root port or downsteam switch
On 06/17/2013 04:20 PM, Bjorn Helgaas wrote:
On Sun, May 26, 2013 at 11:53:14PM +0800, Jiang Liu wrote:
Enhance iommu drviers to use hotplug-safe iterators to walk
PCI buses.
Signed-off-by: Jiang Liu
Cc: Joerg Roedel
Cc: Ingo Molnar
Cc: Donald Dutile
Cc: Hannes Reinecke
Cc: "Li, Zhen-Hua"
Cc: i
On 06/18/2013 06:22 PM, Alex Williamson wrote:
On Tue, 2013-06-18 at 15:31 -0600, Bjorn Helgaas wrote:
On Tue, Jun 18, 2013 at 12:20 PM, Alex Williamson
wrote:
On Tue, 2013-06-18 at 11:28 -0600, Bjorn Helgaas wrote:
On Thu, May 30, 2013 at 12:40:19PM -0600, Alex Williamson wrote:
PCIe ACS (
On 06/18/2013 10:52 PM, Bjorn Helgaas wrote:
On Tue, Jun 18, 2013 at 5:03 PM, Don Dutile wrote:
On 06/18/2013 06:22 PM, Alex Williamson wrote:
On Tue, 2013-06-18 at 15:31 -0600, Bjorn Helgaas wrote:
On Tue, Jun 18, 2013 at 12:20 PM, Alex Williamson
wrote:
On Tue, 2013-06-18 at 11:28
On 05/30/2013 02:37 PM, Alex Williamson wrote:
Downstream ports support for all ACS flags supercedes multifunction
exclusion of some flags. The PCIe spec also fully specifies which
PCIe types are subject to the multifunction rules and excludes event
collectors and PCIe-to-PCI bridges entirely.
On 03/25/2013 10:28 AM, Alex Williamson wrote:
On Mon, 2013-03-25 at 10:23 +1100, Alexey Kardashevskiy wrote:
As IOMMU groups are exposed to the user space by their numbers,
the user space can use them in various kernel APIs so the kernel
might need an API to find a group by its ID.
As an examp
early quirk so that the chip devices/revisions
specified in the above update are also covered in the same way:
Signed-off-by: Neil Horman
Reviewed-by: Jan Beulich
CC: Jan Beulich
CC: Joerg Roedel
CC: Andrew Cooper
CC: Malcolm Crossley
CC: Prarit Bhargava
CC: Don Zickus
CC: Don Dutile
CC: Thomas
On 08/01/2013 12:55 PM, Alex Williamson wrote:
Only cosmetic changes to existing paths.
Signed-off-by: Alex Williamson
---
drivers/pci/pci.c | 52 +++-
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers
On 08/01/2013 12:55 PM, Alex Williamson wrote:
Sometimes pci_reset_function is not sufficient. We have cases where
devices do not support any kind of reset, but there might be multiple
functions on the bus preventing pci_reset_function from doing a
secondary bus reset. We also have cases where
On 08/01/2013 12:55 PM, Alex Williamson wrote:
The PCI spec indicates that with stable power, reset needs to be
asserted for a minimum of 1ms (Trst). Seems like we should be able
to assume power is stable for a runtime secondary bus reset. The
current code has always used 100ms with no explanat
On 08/01/2013 05:41 PM, Alex Williamson wrote:
On Thu, 2013-08-01 at 17:29 -0400, Don Dutile wrote:
On 08/01/2013 12:55 PM, Alex Williamson wrote:
The PCI spec indicates that with stable power, reset needs to be
asserted for a minimum of 1ms (Trst). Seems like we should be able
to assume
On 06/26/2013 03:03 PM, Alex Williamson wrote:
On Mon, 2013-06-24 at 11:43 -0600, Bjorn Helgaas wrote:
On Wed, Jun 19, 2013 at 6:43 AM, Don Dutile wrote:
On 06/18/2013 10:52 PM, Bjorn Helgaas wrote:
On Tue, Jun 18, 2013 at 5:03 PM, Don Dutile wrote:
On 06/18/2013 06:22 PM, Alex
On 03/02/2013 10:59 AM, Andreas Mohr wrote:
Hi,
if ((revision == 0x13)&& irq_remapping_enabled) {
+ pr_warn("WARNING WARNING WARNING WARNING WARNING
WARNING\n"
+ "This system BIOS has enabled interrupt
remapping\n"
+ "on a chipset that
On 03/03/2013 07:56 PM, Takao Indoh wrote:
(2013/01/23 9:47), Thomas Renninger wrote:
On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
(2013/01/08 4:09), Thomas Renninger wrote:
...
I tried the provided patches first on 2.6.32, then I verfied with 3.8-rc2
and in both cases the disk
On 05/14/2013 12:52 PM, Jiang Liu wrote:
Enhance iommu drviers to use hotplug-safe iterators to walk
PCI buses.
Signed-off-by: Jiang Liu
Cc: Joerg Roedel
Cc: Ingo Molnar
Cc: Donald Dutile
Cc: Hannes Reinecke
Cc: "Li, Zhen-Hua"
Cc: io...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
On 04/05/2013 09:55 PM, Bjorn Helgaas wrote:
On Fri, Apr 5, 2013 at 1:31 PM, Neil Horman wrote:
A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
For the 5520 and 5500 chipsets which cont
On 04/30/2013 10:49 AM, Suravee Suthikulanit wrote:
On 4/29/2013 3:10 PM, Don Dutile wrote:
On 04/29/2013 03:45 PM, Suravee Suthikulanit wrote:
Joerg,
We are in the process of implementing AMD IOMMU error handling, and I would
like some comments from you and the community.
Currently, the
On 04/30/2013 10:56 AM, Suravee Suthikulanit wrote:
On 4/29/2013 4:42 PM, Don Dutile wrote:
On 04/29/2013 04:34 PM, Duran, Leo wrote:
I'm wondering if resetting the IOMMU at init-time (once) would clear any BIOS
induced noise.
Leo
Well, depends what you mean by 'reset'
(a
hat adding some of the steps from this algorithm to one of the already proposed patches
would avoid the hang that I saw on two platforms.
Bill Sumner
-Original Message-
From: kexec [mailto:kexec-boun...@lists.infradead.org] On Behalf Of Don Dutile
Sent: Friday, April 26, 2013
ep(1000);
As Linus pointed out in an earlier patch, msleep() after each device
is s-l-o-w and unnecessary; should do a single msleep(1000) after
*all* the command registers are written. That way, the added delay is 1sec,
not 1sec*ndevs.
q: is this turning off command register for only PCI(e) endpoints?
On 05/07/2013 12:39 PM, Alex Williamson wrote:
On Wed, 2013-04-24 at 13:58 +0900, Takao Indoh wrote:
This patch resets PCIe devices on boot to stop ongoing DMA. When
"pci=pcie_reset_devices" is specified, a hot reset is triggered on each
PCIe root port and downstream port to reset its downstream
On 05/07/2013 10:57 PM, Alex Williamson wrote:
Move the secondary bus reset code from pci_parent_bus_reset() into its own
function. Export it as we'll later be calling it from hotplug controllers.
Signed-off-by: Alex Williamson
---
drivers/pci/pci.c | 32 +++-
On 04/24/2013 06:46 AM, Joerg Roedel wrote:
On Tue, Apr 23, 2013 at 09:22:45AM -0400, Don Dutile wrote:
Given other threads on this mail list (and I've seen crashes with same problem)
where this type of logging during a flood of IOMMU errors will lock up the
machine,
is there something
On 04/24/2013 12:58 AM, Takao Indoh wrote:
This patch resets PCIe devices on boot to stop ongoing DMA. When
"pci=pcie_reset_devices" is specified, a hot reset is triggered on each
PCIe root port and downstream port to reset its downstream endpoint.
Problem:
This patch solves the problem that kdu
On 04/25/2013 01:11 AM, Takao Indoh wrote:
> (2013/04/25 4:59), Don Dutile wrote:
>> On 04/24/2013 12:58 AM, Takao Indoh wrote:
>>> This patch resets PCIe devices on boot to stop ongoing DMA. When
>>> "pci=pcie_reset_devices" is specified, a hot reset is tri
On 04/25/2013 11:10 PM, Takao Indoh wrote:
> (2013/04/26 3:01), Don Dutile wrote:
>> On 04/25/2013 01:11 AM, Takao Indoh wrote:
>>> (2013/04/25 4:59), Don Dutile wrote:
>>>> On 04/24/2013 12:58 AM, Takao Indoh wrote:
>>>>> This patch resets PCIe devices
On 04/29/2013 03:45 PM, Suravee Suthikulanit wrote:
Joerg,
We are in the process of implementing AMD IOMMU error handling, and I would
like some comments from you and the community.
Currently, the AMD IOMMU driver only reports events from the event log in the
dmesg, and does not try to handle
mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Don Dutile
Sent: Monday, April 29, 2013 3:10 PM
To: Suthikulpanit, Suravee
Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org
Subject: Re: RFC: IOMMU/AMD: Error Handling
On 04/29/2013 03:45 PM, Suravee Suthikulanit wrote
On 05/14/2013 05:39 PM, Alexander Duyck wrote:
On 05/14/2013 12:59 PM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 12:45 PM, Alexander Duyck
wrote:
On 05/14/2013 11:44 AM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 9:00 AM, Alexander Duyck
wrote:
I'm sorry, but what is the point of this patc
On 05/21/2013 05:30 PM, Don Dutile wrote:
On 05/14/2013 05:39 PM, Alexander Duyck wrote:
On 05/14/2013 12:59 PM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 12:45 PM, Alexander Duyck
wrote:
On 05/14/2013 11:44 AM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 9:00 AM, Alexander Duyck
wrote:
I&#
On 05/21/2013 05:58 PM, Alexander Duyck wrote:
On 05/21/2013 02:31 PM, Don Dutile wrote:
On 05/21/2013 05:30 PM, Don Dutile wrote:
On 05/14/2013 05:39 PM, Alexander Duyck wrote:
On 05/14/2013 12:59 PM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 12:45 PM, Alexander Duyck
wrote:
On 05/14
:30:32PM -0400, Don Dutile wrote:
On 05/14/2013 05:39 PM, Alexander Duyck wrote:
On 05/14/2013 12:59 PM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 12:45 PM, Alexander Duyck
wrote:
On 05/14/2013 11:44 AM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 9:00 AM, Alexander Duyck
wrote:
I'm
cc-ing the upstream iommu-list
On 03/05/2013 09:43 PM, Li, Zhen-Hua wrote:
The number of dma fault reasons in intel's document are from 1 to 0xD, but in
dmar.c I cannot find fault reason 0xD.
In this document:
Intel Virtualization Technology for Directed I/O Architecture Specification
http://d
On 03/07/2013 01:31 PM, Don Dutile wrote:
cc-ing the upstream iommu-list
On 03/05/2013 09:43 PM, Li, Zhen-Hua wrote:
The number of dma fault reasons in intel's document are from 1 to 0xD, but in
dmar.c I cannot find fault reason 0xD.
In this document:
Intel Virtualization Technolog
hem a reminder that their systems are vulnurable to this problem.
Signed-off-by: Neil Horman
CC: Prarit Bhargava
CC: Don Zickus
CC: Don Dutile
CC: Bjorn Helgaas
CC: Asit Mallick
CC: linux-...@vger.kernel.org
Ping, anyone want to Ack/Nack this?
Don's comment earlier seems to imply that this
On 08/01/2012 02:37 AM, Feng Tang wrote:
This is a preparation for removing the acpi_get_table_with_size(), as this
function could be well covered by acpi_get_table(), and there is no need
to have both of them to exist.
v2: As reminded by Yinghai, apply the replacment to
drivers/iommu/amd_iommu
On 08/03/2012 07:24 AM, Takao Indoh wrote:
> Hi all,
>
> This patch adds kernel parameter "reset_pcie_devices" which resets PCIe
> devices at boot time to address DMA problem on kdump with iommu. When
> this parameter is specified, a hot reset is triggered on each PCIe root
> port and downstream p
On 08/22/2012 12:28 PM, Bjorn Helgaas wrote:
On Mon, Aug 20, 2012 at 9:40 PM, Cui, Dexuan wrote:
Bjorn Helgaas wrote on 2012-08-21:
I am still concerned about reset_intel_82599_sfp_virtfn(). It looks
wrong and possibly unnecessary. It looks wrong because it sets
PCI_EXP_DEVCTL_BCR_FLR and
On 08/07/2012 12:10 PM, Jiang Liu wrote:
From: Jiang Liu
This is the second take to resolve race conditions when hot-plugging PCI
devices/host bridges. Instead of using a globla lock to serialize all hotplug
operations as in previous version, now we introduce a state machine and bit
lock mechani
On 08/06/2012 04:47 PM, Bjorn Helgaas wrote:
On Sun, Aug 5, 2012 at 11:55 PM, Alex Williamson
wrote:
On Sun, 2012-08-05 at 23:30 -0600, Bjorn Helgaas wrote:
On Sat, Aug 4, 2012 at 12:19 PM, Alex Williamson
wrote:
It's possible to have buses without an associated bridge
(bus->self == NULL).
On 08/08/2012 11:24 AM, Alex Williamson wrote:
On Tue, 2012-08-07 at 23:00 -0700, Bjorn Helgaas wrote:
On Tue, Aug 7, 2012 at 2:50 PM, Don Dutile wrote:
On 08/06/2012 04:47 PM, Bjorn Helgaas wrote:
On Sun, Aug 5, 2012 at 11:55 PM, Alex Williamson
wrote:
On Sun, 2012-08-05 at 23:30
On 07/24/2012 12:31 PM, Jiang Liu wrote:
From: Jiang Liu
As suggested by Bjorn Helgaas and Don Dutile in threads
http://www.spinics.net/lists/linux-pci/msg15663.html, we could improve access
to PCIe capabilities register in to way:
1) cache content of PCIe Capabilities Register into struct
On 07/24/2012 12:31 PM, Jiang Liu wrote:
From: Jiang Liu
Introduce five configuration access functions for PCIe capabilities registers
to hide differences among PCIe Base Spec versions.
Function pci_pcie_capability_read_word/dword() stores the PCIe Capabilities
register value by the passed para
resending since i did a reply vs reply-all last time...
On 07/24/2012 12:31 PM, Jiang Liu wrote:
From: Yijing Wang
From: Yijing Wang
Since PCI Express Capabilities Register is read only, cache its value
into struct pci_dev to avoid repeatedly calling pci_read_config_*().
Signed-off-by: Yijing
sorry for delay... i thought i had sent it out yesterday,
but found it today when cleaning up/out the multiple of
windows/xterms on my desktop.
On 07/24/2012 12:31 PM, Jiang Liu wrote:
From: Jiang Liu
Use PCIe capabilities access functions to simplify PCI core implementation.
Signed-off-by: J
On 11/20/2012 02:43 PM, Tom Mingarelli wrote:
This patch is to prevent non-USB devices that have RMRRs associated with them
from
being placed into the SI Domain during init. This fixes the issue where the
RMRR info
for devices being placed in and out of the SI Domain gets lost.
Signed-off-by:
On 12/13/2012 04:50 AM, Jason Gao wrote:
Dear List:
Description of problem:
After installed Centos 6.3(RHEL6.3) on my Dell R710(lastest
bios:Version: 6.3.0,Release Date: 07/24/2012) server,and updated
lastest kernel "2.6.32-279.14.1.el6.x86_64",I want to use the Intel
82576 ET Dual Port nic's SR
On 12/13/2012 09:01 PM, Jason Gao wrote:
On Fri, Dec 14, 2012 at 12:23 AM, Alex Williamson
wrote:
Device 03:00.0 is your raid controller:
03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev
04)
For some reason it's trying to read from ffe65000, ffe8a000, ffe89000,
On 12/13/2012 09:01 PM, Jason Gao wrote:
On Fri, Dec 14, 2012 at 12:23 AM, Alex Williamson
wrote:
Device 03:00.0 is your raid controller:
03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev
04)
For some reason it's trying to read from ffe65000, ffe8a000, ffe89000,
On 12/15/2012 05:16 PM, Robert Hancock wrote:
On 12/14/2012 03:32 PM, Don Dutile wrote:
On 12/13/2012 04:50 AM, Jason Gao wrote:
Dear List:
Description of problem:
After installed Centos 6.3(RHEL6.3) on my Dell R710(lastest
bios:Version: 6.3.0,Release Date: 07/24/2012) server,and updated
On 01/18/2013 06:42 AM, Konstantin Khlebnikov wrote:
comment in commit b566a22c23327f18ce941ffad0ca907e50a53d41
("PCI: disable Bus Master on PCI device shutdown") says:
| Disable Bus Master bit on the device in pci_device_shutdown() to ensure PCI
| devices do not continue to DMA data after shutd
On 01/08/2013 09:32 AM, tadeusz.st...@intel.com wrote:
pci_find_upstream_pcie_bridge() doesn't handle well non PCIE VFs
that are part of a PCIE PF device.
Signed-off-by: Tadeusz Struk
---
drivers/pci/search.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/driver
On 01/09/2013 05:27 AM, Tadeusz Struk wrote:
On 01/08/2013 05:05 PM, Don Dutile wrote:
(a) no such thing as a non-PCIe VF -- all VFs
are PCIe-based.
The sriov spec says that a VF doesn't necessarily has to have PCIE cap:
"3.5 PCI Express Capability:
...
PFs and VFs ar
On 03/01/2018 03:22 PM, Alex Williamson wrote:
On Wed, 28 Feb 2018 16:36:38 -0800
Alexander Duyck wrote:
On Wed, Feb 28, 2018 at 2:59 PM, Alex Williamson
wrote:
On Wed, 28 Feb 2018 09:49:21 -0800
Alexander Duyck wrote:
On Tue, Feb 27, 2018 at 2:25 PM, Alexander Duyck
wrote:
On Tue, Fe
On 03/05/2018 04:41 PM, Alexander Duyck wrote:
On Mon, Mar 5, 2018 at 12:57 PM, Don Dutile wrote:
On 03/01/2018 03:22 PM, Alex Williamson wrote:
On Wed, 28 Feb 2018 16:36:38 -0800
Alexander Duyck wrote:
On Wed, Feb 28, 2018 at 2:59 PM, Alex Williamson
wrote:
On Wed, 28 Feb 2018 09:49
On 03/13/2018 11:04 AM, David Woodhouse wrote:
On Tue, 2018-03-13 at 07:51 -0700, Alexander Duyck wrote:
Actually the suggestion I had from Don Dutile was that we should be
looking at creating a pci-stub like driver specifically for those type
of devices, but without the ability to arbitrarily
On 01/13/2015 07:47 PM, Jon Masters wrote:
Hi Folks,
TLDR: I would like to consider the value of adding something like
"cluster_siblings" or similar in sysfs to describe ARM topology.
A quick question on intended data representation in /sysfs topology
before I ask the team on this end to go dow
On 01/14/2015 06:24 AM, Arnd Bergmann wrote:
On Tuesday 13 January 2015 19:47:00 Jon Masters wrote:
Hi Folks,
TLDR: I would like to consider the value of adding something like
"cluster_siblings" or similar in sysfs to describe ARM topology.
A quick question on intended data representation in /
Vlasenko
Cc: Marek Szyprowski
Cc: Konrad Rzeszutek Wilk
Cc: David Woodhouse
Cc: Don Dutile
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andi Kleen
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
Changes in v2: added EXPORT_SYMBOL()
Changes in v3: adde
On 04/06/2015 11:46 PM, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some possibilities that the old iommu data is corrupted by
some other modules. Currently we do not hav
On 07/16/2012 01:29 PM, Bjorn Helgaas wrote:
On Sun, Jul 15, 2012 at 10:47 AM, Jiang Liu wrote:
On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
Hi Bjorn,
It's a little risk to change these PCIe capabilities access
functions as void. On some platform with hardware error detecting/correcti
On 05/26/2015 05:11 PM, Alex Williamson wrote:
v2: don't modify entry->id.device
In most cases we only use ARI with SR-IOV VFs, which do not support
INTx and therefore never hit this problem. However, some non-SR-IOV
implementations create multiple PFs, extending beyond the standard
3-bit funct
On 01/10/2014 05:07 PM, Bill Sumner wrote:
v2->v3:
1. Commented-out "#define DEBUG 1" to eliminate debug messages
2. Updated the comments about changes in each version in all patches in the set.
3. Fixed: one-line added to Copy-Translations" patch to initialize the iovad
struct as reco
On 04/28/2014 05:51 AM, AKASHI Takahiro wrote:
Hi Don,
Sorry for not responding to you soon:
been there, done that! .. no problem..
On 04/12/2014 06:37 AM, Don Dutile wrote:
On 03/15/2014 01:49 AM, AKASHI Takahiro wrote:
(Please apply this patch after my ftrace patch to resolve some
On 04/08/2014 12:14 PM, David Woodhouse wrote:
On Mon, 2014-04-07 at 16:43 -0400, Don Dutile wrote:
Additionally, a tidbit of information like "some servers force NMI's
on DMAR faults,
and cause a system reset, thereby, preventing a kdump to occur"
should have been included a
On 03/15/2014 01:49 AM, AKASHI Takahiro wrote:
(Please apply this patch after my ftrace patch to resolve some conflict
on arm64/kernel/ptrace.c, functionally it doesn't depend on ftrace though)
This patchset adds system call audit support on arm64.
Both 32-bit (AUDIT_ARCH_ARM) and 64-bit tasks (
On 05/28/2014 04:14 PM, Bjorn Helgaas wrote:
On Wed, May 28, 2014 at 10:39 AM, Alexander Duyck
wrote:
On 05/27/2014 09:12 PM, Alex Williamson wrote:
On Tue, 2014-05-27 at 19:19 -0600, Bjorn Helgaas wrote:
Maybe resetting the PF should just fail if there's an active VF. If
you need to reset
On 01/20/2014 11:21 AM, Alex Williamson wrote:
On Mon, 2014-01-20 at 14:45 +, Varun Sethi wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Saturday, January 18, 2014 2:06 AM
To: Sethi Varun-B16395
Cc: io...@lists.linux-foundation.org; linux-
On 11/21/2013 03:21 AM, Yijing Wang wrote:
This is the v2 patch, the v1 link:
http://marc.info/?l=linux-pci&m=138364004628824&w=2
v1->v2: keep (pci_dev *) pointer array in dmar_drhd_uni, only use pci device id
to update pci_dev * pointer info during device hotplug in intel
iomm
On 04/29/2016 11:37 AM, Richard W.M. Jones wrote:
On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote:
On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote:
On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones w
On 05/26/2015 01:54 PM, Alex Williamson wrote:
The PCIe specification, rev 3.0, section 2.2.8.1, contains the
following implementation note:
Virtual Wire Mapping for INTx Interrupts From ARI Devices
The implied Device Number for an ARI Device is 0. When ARI-aware
software (includ
On 05/26/2015 04:42 PM, Alex Williamson wrote:
On Tue, 2015-05-26 at 16:06 -0400, Don Dutile wrote:
On 05/26/2015 01:54 PM, Alex Williamson wrote:
The PCIe specification, rev 3.0, section 2.2.8.1, contains the
following implementation note:
Virtual Wire Mapping for INTx Interrupts From
On 05/07/2015 10:00 AM, Dave Young wrote:
On 04/07/15 at 10:12am, Don Dutile wrote:
On 04/06/2015 11:46 PM, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some
1 - 100 of 136 matches
Mail list logo
