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 problem
On 10/03/2012 01:51 PM, Yinghai Lu wrote:
Will use it enable sriov for pci devices.
Signed-off-by: Yinghai Luying...@kernel.org
---
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
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 Luying...@kernel.org
Cc: Jeff Kirsherjeffrey.t.kirs...@intel.com
Cc: Jesse
On 10/03/2012 04:41 PM, Yinghai Lu wrote:
On Wed, Oct 3, 2012 at 11:55 AM, Don Dutileddut...@redhat.com wrote:
On 10/03/2012 01:51 PM, Yinghai Lu wrote:
Will use it enable sriov for pci devices.
Signed-off-by: Yinghai Luying...@kernel.org
---
include/linux/pci.h |1 +
1 files
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 PCIe root port
On 11/09/2012 10:26 AM, Bjorn Helgaas wrote:
[+ linux-pci, Yinghai]
On Thu, Nov 8, 2012 at 8:59 PM, Jason Gaopkill.2...@gmail.com 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
On 11/12/2012 04:26 AM, Doug Goldstein wrote:
On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
prometheanf...@gentoo.org 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.
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-
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
prometheanf...@gentoo.org wrote:
System boots
On 07/16/2012 01:29 PM, Bjorn Helgaas wrote:
On Sun, Jul 15, 2012 at 10:47 AM, Jiang Liuliu...@gmail.com 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
to hide the irq_remap_broken variable so we don't need to pull in a
private header file
/me waiting for v11...
/me runs! ;-)
Neil,
Looks good, and kudos on your tenacity through all the revs.
- Don(Dutile)
---
arch/x86/include/asm/irq_remapping.h | 1 +
arch/x86/kernel/early-quirks.c
On 04/04/2013 12:16 PM, Yinghai Lu wrote:
On Thu, Apr 4, 2013 at 8:08 AM, Neil Hormannhor...@tuxdriver.com 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
On 04/05/2013 09:55 PM, Bjorn Helgaas wrote:
On Fri, Apr 5, 2013 at 1:31 PM, Neil Hormannhor...@tuxdriver.com 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
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 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
On 03/09/2013 05:20 PM, Myron Stowe wrote:
On Sat, Mar 9, 2013 at 1:49 PM, Neil Hormannhor...@tuxdriver.com wrote:
On Mon, Mar 04, 2013 at 02:04:19PM -0500, Neil Horman wrote:
A few years back intel published a spec update:
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
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
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 Technology
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
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
On 09/21/2012 02:22 AM, Yinghai Lu wrote:
On Thu, Sep 20, 2012 at 7:56 PM, Bjorn Helgaasbhelg...@google.com 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
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
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 Liujiang@huawei.com
Use PCIe capabilities access functions to simplify PCI core
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 Yingying.hu...@intel.com
---
Documentation/ABI/testing/sysfs-bus-pci | 12
1 file changed, 12 insertions(+)
---
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
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 Garrettm...@redhat.com
---
drivers/pci/rom.c | 11 +--
include/linux/pci.h | 2 ++
On 08/07/2012 12:10 PM, Jiang Liu wrote:
From: Jiang Liuliu...@gmail.com
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
On 08/06/2012 04:47 PM, Bjorn Helgaas wrote:
On Sun, Aug 5, 2012 at 11:55 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Sun, 2012-08-05 at 23:30 -0600, Bjorn Helgaas wrote:
On Sat, Aug 4, 2012 at 12:19 PM, Alex Williamson
alex.william...@redhat.com wrote:
It's possible to have
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 Dutileddut...@redhat.com wrote:
On 08/06/2012 04:47 PM, Bjorn Helgaas wrote:
On Sun, Aug 5, 2012 at 11:55 PM, Alex Williamson
alex.william...@redhat.com
On 08/22/2012 12:28 PM, Bjorn Helgaas wrote:
On Mon, Aug 20, 2012 at 9:40 PM, Cui, Dexuandexuan@intel.com 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
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
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 port to
On 07/24/2012 12:31 PM, Jiang Liu wrote:
From: Jiang Liuliu...@gmail.com
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
On 07/24/2012 12:31 PM, Jiang Liu wrote:
From: Jiang Liujiang@huawei.com
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
resending since i did a reply vs reply-all last time...
On 07/24/2012 12:31 PM, Jiang Liu wrote:
From: Yijing Wangwangyij...@huawei.com
From: Yijing Wangwangyij...@huawei.com
Since PCI Express Capabilities Register is read only, cache its value
into struct pci_dev to avoid repeatedly calling
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
On 12/13/2012 09:01 PM, Jason Gao wrote:
On Fri, Dec 14, 2012 at 12:23 AM, Alex Williamson
alex.william...@redhat.com 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
On 12/13/2012 09:01 PM, Jason Gao wrote:
On Fri, Dec 14, 2012 at 12:23 AM, Alex Williamson
alex.william...@redhat.com 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
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/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 Struktadeusz.st...@intel.com
---
drivers/pci/search.c |6 ++
1 files changed, 6 insertions(+), 0
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 are required
On 07/09/2013 03:11 PM, Neil Horman wrote:
Recently we added an early quirk to detect 5500/5520 chipsets with early
revisions that had problems with irq draining with interrupt remapping enabled:
commit 03bbcb2e7e292838bb0244f5a7816d194c911d62
Author: Neil Hormannhor...@tuxdriver.com
Date:
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
On 07/11/2013 04:09 PM, Bjorn Helgaas wrote:
On Thu, Jul 11, 2013 at 3:51 AM, Don Dutileddut...@redhat.com 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
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
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
alex.william...@redhat.com wrote:
On Tue, 2013-06-18 at 11:28 -0600, Bjorn Helgaas wrote:
On Thu, May 30, 2013 at 12:40:19PM -0600, Alex
On 06/18/2013 10:52 PM, Bjorn Helgaas wrote:
On Tue, Jun 18, 2013 at 5:03 PM, Don Dutileddut...@redhat.com 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
On 07/17/2013 07:13 AM, Neil Horman wrote:
Recently we added an early quirk to detect 5500/5520 chipsets with early
revisions that had problems with irq draining with interrupt remapping enabled:
commit 03bbcb2e7e292838bb0244f5a7816d194c911d62
Author: Neil Hormannhor...@tuxdriver.com
Date:
On 08/01/2013 12:55 PM, Alex Williamson wrote:
Only cosmetic changes to existing paths.
Signed-off-by: Alex Williamsonalex.william...@redhat.com
---
drivers/pci/pci.c | 52 +++-
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git
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
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 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 Williamsonalex.william...@redhat.com
---
drivers/pci/pci.c | 32
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 Indohindou.ta...@jp.fujitsu.com 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
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-Huazhen-h...@hp.com
---
drivers/iommu/intel-iommu.c |4 ++--
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 Liujiang@huawei.com
Cc: Joerg Roedelj...@8bytes.org
Cc: Ingo Molnarmi...@kernel.org
Cc: Donald
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
] 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:
Joerg,
We are in the process of implementing
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
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) setting it up
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 8:43 AM
To: Takao Indoh
Cc: linux-...@vger.kernel.org; ke...@lists.infradead.org
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 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
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
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 triggered on each
PCIe root port and downstream port
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 boot to stop ongoing DMA. When
pci=pcie_reset_devices
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
alexander.h.du...@intel.com wrote:
On 05/14/2013 11:44 AM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 9:00 AM, Alexander Duyck
alexander.h.du...@intel.com
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
alexander.h.du...@intel.com wrote:
On 05/14/2013 11:44 AM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 9:00 AM
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
alexander.h.du
:
On Tue, May 21, 2013 at 05: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
alexander.h.du...@intel.com wrote:
On 05/14/2013 11:44 AM, Yinghai Lu wrote:
On Tue, May 14
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 Liujiang@huawei.com
Cc: Joerg Roedelj...@8bytes.org
Cc: Ingo Molnarmi...@kernel.org
Cc: Donald Dutileddut...@redhat.com
Cc: Hannes Reineckeh...@suse.de
Cc:
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 Dutileddut...@redhat.com wrote:
On 06/18/2013 10:52 PM, Bjorn Helgaas wrote:
On Tue, Jun 18, 2013 at 5:03 PM, Don Dutileddut...@redhat.com wrote:
On 05/28/2014 04:14 PM, Bjorn Helgaas wrote:
On Wed, May 28, 2014 at 10:39 AM, Alexander Duyck
alexander.h.du...@intel.com 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
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;
On 11/21/2013 03:21 AM, Yijing Wang wrote:
This is the v2 patch, the v1 link:
http://marc.info/?l=linux-pcim=138364004628824w=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
iommu
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 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
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 as one reason to stop
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 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 down
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
On 05/04/2015 07:05 AM, Joerg Roedel wrote:
On Fri, Apr 03, 2015 at 04:40:31PM +0800, Dave Young wrote:
Have not read all the patches, but I have a question, not sure this
has been answered before. Old memory is not reliable, what if the old
memory get corrupted before panic? Is it safe to
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
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
On 05/07/2015 09:21 PM, Dave Young wrote:
On 05/07/15 at 10:25am, Don Dutile wrote:
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
Vlasenko dvlas...@redhat.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: David Woodhouse dw...@infradead.org
Cc: Don Dutile ddut...@redhat.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc
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
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
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
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 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
: "linux-arm-ker...@lists.infradead.org"
<linux-arm-ker...@lists.infradead.org>, "linux-kernel@vger.kernel.org"
<linux-kernel@vger.kernel.org>, Don Dutile <ddut...@redhat.com>
On 01/14/2015 12:00 PM, Mark Rutland wrote:
On Wed, Jan 14, 2015 at 12:47:00AM +
1 - 100 of 264 matches
Mail list logo
