Bug 880051
| Summary: | dmar-disable-when-ricoh-multifunction.patch prevents PCI passthrough | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrew Gunnerson <accounts+fedora> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | acooks, gansalmon, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-03-11 01:22:33 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Andrew Gunnerson
2012-11-26 05:56:00 UTC
The Ricoh problem was fixed in commit 783f157bc5a7fa30ee17b4099b27146bd1b68af4 and should be in kernels from 3.5 onward afaik. The only patch called "dmar-disable-when-ricoh-multifunction.patch" that I could find is from October 2010. Is this what you're referring to? If you're still having problems with a Ricoh device, it might just be a new device id that needs to be included in the quirk. Please post the output of dmesg and 'lspci -vvnnk'. Hi Andrew,
I have no problem with Ricoh, but I thought that other people did. My problem is that the "dmar-disable-when-ricoh-multifunction.patch" patch prevents PCI passthrough on my computer because it contains a supposedly broken Ricoh device.
The patch is included in the Fedora packaging:
----
$ git remote show origin | grep Fetch
Fetch URL: git://pkgs.fedoraproject.org/kernel
$ git log -1 dmar-disable-when-ricoh-multifunction.patch
commit 1d0a7626b17ff7ac7dea19d939a8b6bdcbc0b8c9
Author: Justin M. Forbes <jforbes>
Date: Fri Jan 18 14:47:39 2013 -0600
Linux v3.8-rc4
----
Link: http://pkgs.fedoraproject.org/cgit/kernel.git/tree/dmar-disable-when-ricoh-multifunction.patch
Regarding the upstream kernel and the Ricoh bug, commit 783f157bc5a7fa30ee17b4099b27146bd1b68af4 that I mentioned above is not entirely correct. But, commit 12ea6cad1c7d046e21decc18b0e2170c6794dc51 should make the patch obsolete.
--snip--
commit 12ea6cad1c7d046e21decc18b0e2170c6794dc51
Author: Alex Williamson <alex.williamson>
Date: Mon Jun 11 05:26:55 2012 +0000
PCI: add PCI DMA source ID quirk
DMA transactions are tagged with the source ID of the device making
the request. Occasionally hardware screws this up and uses the
source ID of a different device (often the wrong function number of
a multifunction device). A specific Ricoh multifunction device is
a prime example of this problem and included in this patch.
Given a pci_dev, this function returns the pci_dev to use as the
source ID for DMA. When hardware works correctly, this returns
the input device. For the components of the Ricoh multifunction
device, it returns the pci_dev for function 0.
This will be used by IOMMU drivers for determining the boundaries
of IOMMU groups as multiple devices using the same source ID must
be contained within the same group. This can also be used by
existing streaming DMA paths for the same purpose.
[bhelgaas: fold in pci_dev_get() for !CONFIG_PCI]
Signed-off-by: Alex Williamson <alex.williamson>
Signed-off-by: Bjorn Helgaas <bhelgaas>
--snip--
This will make the next round of updates. kernel-3.8.2-206.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.8.2-206.fc18 kernel-3.8.2-105.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/kernel-3.8.2-105.fc17 Package kernel-3.8.2-206.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.8.2-206.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-3630/kernel-3.8.2-206.fc18 then log in and leave karma (feedback). kernel-3.8.2-206.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. kernel-3.8.2-105.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2013-3638/kernel-3.8.2-105.fc17 kernel-3.8.3-101.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/kernel-3.8.3-101.fc17 kernel-3.8.3-103.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. Xiao-Long Chen, please test the updated kernel and report your results. There has been a report that the problem that commit 12ea6cad1c tries to fix may still be present [1]. Assuming it is, then these recently released Fedora kernels may fail to boot on affected systems. https://lkml.org/lkml/2013/4/5/21 Andrew, I have never been affected by that problem. My only complaint was that dmar-disable-when-ricoh-multifunction.patch disabled DMAR on my computer, even when my computer isn't affected (breaks IOMMU for virtualization). Xiao-Long Chen If your computer has one of these Ricoh devices, but doesn't have the DMAR problem, then some of the assumptions that were made when the quirk was created are wrong. So it's important that we understand why one person needs the patch and another doesn't. Does your computer have a firewire port? Have you disabled it? Could you attach the output of 'lspci -vvnnk' to this bug report, please? Andrew, You're right, I did disable the Firewire port in the BIOS, although I don't remember why. I unfortunately can't give you the output of "lspci -vvnnk" right now because my BIOS chip is fried. I'll post more info when (if) I can get my Thinkpad to boot again. |