Is there another possible workaround for the dmar issues with the Ricoh media card readers? Right now, the patch completely disables dmar when the hardware is present, which prevents PCI passthrough to virtual machines from working on any Lenovo laptop. Here are some ideas (none of them ideal): 1. Do not enable IOMMU by default (ie. boot with intel_iommu=on when it's needed). This way, users who don't use PCI passthrough won't run into this issue. 2. Have users disable the firewire port in the BIOS. This is a workaround from the bug report that introduced the patch: 605888. I can confirm that this works. 3. Write another patch to deal with the problematic ricoh hardware without completely disabling dmar.
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.