Bug 86951
Summary: | iommu regression | ||
---|---|---|---|
Product: | Drivers | Reporter: | Will (nodenet) |
Component: | PCI | Assignee: | drivers_pci (drivers_pci) |
Status: | RESOLVED WILL_NOT_FIX | ||
Severity: | normal | CC: | alex.williamson, bjorn, dave |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.13 | Subsystem: | |
Regression: | Yes | Bisected commit-id: |
Description
Will
2014-10-26 13:56:08 UTC
AFAIK vboxpci is a closed source kernel module. If you'd like to try with KVM/VFIO we might be able to help you. Will, is there any chance you can reproduce this problem with an upstream kernel, i.e., without vboxpci? It's hard for us to identify the source code for the combination of Linux + vbox that you're running (and I know nothing about vbox anyway), so I don't think we can make much progress here. Another possibility is for you to bisect to identify the commit that broke things. That might be enough to help figure out a fix. A bisect sounds like a sensible way to find the problem. My issue is that the machine is a production machine so it limits what I can do easily. I just booted an old kernel that was left there from updates to see if it would work which it did, but there is no Ethernet driver for my card in that kernel and I thought it would be better to go forwards rather than backwards hence stopping off here. When I get some spare time associated with this machine or some equivalent hardware to test on I will investigate further and see if I can provide some more useful information. I am getting the same kind of DMAR fault messages from unpatched kernel.org kernels when trying to use a PCI sound card without bounce buffers (no virtualization, just intel_iommu=on), but reverting to git tag v3.2 or v3.1 did not fix it. It only triggered the other problem to appear (warning at pci_find_upstream_pcie_bridge). Dec 17 19:36:41 lava64 kernel: dmar: DRHD: handling fault status reg 3 Dec 17 19:36:41 lava64 kernel: dmar: DMAR:[DMA Read] Request device [05:00.0] fault addr 7fff0000 Dec 17 19:36:41 lava64 kernel: DMAR:[fault reason 06] PTE Read access is not set Gigabyte GA-Z97-HD3 rev. 2.0 with F6 BIOS (new PC, new problem) Sound card: VIA Technologies Inc. ICE1712 [Envy24] PCI, module snd_ice1712 I gathered from searching that lots of people have had this problem since the IOMMU first appeared, but it is usually blamed on faulty BIOS with no workaround except to disable the IOMMU ("don't do that then"). (In reply to David Flater from comment #4) > I am getting the same kind of DMAR fault messages from unpatched kernel.org > kernels when trying to use a PCI sound card without bounce buffers (no > virtualization, just intel_iommu=on), but reverting to git tag v3.2 or v3.1 > did not fix it. It only triggered the other problem to appear (warning at > pci_find_upstream_pcie_bridge). > > Dec 17 19:36:41 lava64 kernel: dmar: DRHD: handling fault status reg 3 > Dec 17 19:36:41 lava64 kernel: dmar: DMAR:[DMA Read] Request device > [05:00.0] fault addr 7fff0000 > Dec 17 19:36:41 lava64 kernel: DMAR:[fault reason 06] PTE Read access is not > set > > Gigabyte GA-Z97-HD3 rev. 2.0 with F6 BIOS (new PC, new problem) > Sound card: VIA Technologies Inc. ICE1712 [Envy24] PCI, module snd_ice1712 > > I gathered from searching that lots of people have had this problem since > the IOMMU first appeared, but it is usually blamed on faulty BIOS with no > workaround except to disable the IOMMU ("don't do that then"). Sounds like a different problem, please file a new bug instead of cluttering this one. My guess would be that the device is trying to flush DMA writes with a DMA read, but the driver hasn't properly mapped anything to the flush address. Since it has never worked as far as we know, it's not a regression. Potentially a driver bug, maybe a hardware bug. This bug seems stale. I'm closing it because I don't think we're making any progress on it. If it's still a problem, please reopen and we'll try again. |