I'm try to install fedora 15 and 16 in a computer with a sata III marvell 88SEXXX controller, however both fedora 15 and 16 do not locale the sata III drives. The system installer return the message: There is no disk to install. And the installation fault. The unbelievable is that the scientific linux (based on fedora) works with sata III marvell controller. Thanks. Fernando.
Please attach /tmp/syslog and /tmp/storage.log from the failed installation to this bug report. Thanks.
Created attachment 537504 [details] storage log. please, find attached the file storage.log
Created attachment 537508 [details] find attached syslog. please attention to lines 989: That error below appears after I enable the sata III at motherboard bios. 11:55:38,401 ERR kernel:[ 2.305657] DRHD: handling fault status reg 2 11:55:38,401 ERR kernel:[ 2.305721] DMAR:[DMA Write] Request device [02:00.1] fault addr fff00000 11:55:38,401 ERR kernel:[ 2.305723] DMAR:[fault reason 02] Present bit in context entry is clear
Created attachment 537509 [details] Anaconda log. Find attached log from anaconda.
My system have two HD's samsung HD204UI 2.0Tb at a sata III marvel 88SE91XX adapter. My motherboard is an Intel DX580G extreme series. thanks.
(In reply to comment #3) > > 11:55:38,401 ERR kernel:[ 2.305657] DRHD: handling fault status reg 2 > 11:55:38,401 ERR kernel:[ 2.305721] DMAR:[DMA Write] Request device > [02:00.1] fault addr fff00000 > 11:55:38,401 ERR kernel:[ 2.305723] DMAR:[fault reason 02] Present bit in > context entry is clear This is a problem in the Intel DMAR driver. Try adding: intel_iommu=off to the kernel boot options. (Or disable VT-d in the machine's BIOS settings.)
(In reply to comment #6) > This is a problem in the Intel DMAR driver. Try adding: > > intel_iommu=off > > to the kernel boot options. (Or disable VT-d in the machine's BIOS settings.) SOLVED: After I disable VT-d in the machine's BIOS, Fedora 15 and 16 works with sata III drives. Thanks.
(In reply to comment #6) > This is a problem in the Intel DMAR driver. Try adding: > > intel_iommu=off Can you explain why you believe that to be the case? The message 'Present bit in context entry is clear' seems to indicate that *no* DMA mappings have been set up for this device (02:00.1) at all. In fact, the AHCI device is 02:00.0, isn't it? Not 02:00.1? So the problem here seems to be that the Marvell hardware is buggy, and does its DMA with the wrong source-address? We probably need a quirk to make the code handle that, like we {have,need} for the broken Ricoh devices that do something similar. Chuck, is that why you said the problem is in the Intel DMAR driver? Had you already worked that out and sent a new quirk upstream? Or was your comment just the same as when you get a SEGV in a userspace program, and say "The problem is in the MMU. Run on ucLinux and your program won't segfault"? :)
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.
I still have this problem on 3.3.1 from kernel.org. If there is a separate patch that's been applied to the Fedora kernel I'd be happy to test it (the patch). I haven't seen any patch on lkml yet, but there's a short description of how a quirk might be implemented at https://lkml.org/lkml/2011/12/1/461
I think this is the same bug as 42679 on bugzilla.kernel.org. (https://bugzilla.kernel.org/show_bug.cgi?id=42679)
# Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
With no response, we are closing this bug under the assumption that it is no longer an issue. If you still experience this bug, please feel free to reopen the bug report.
I found an approach to workaround the issue but still I have no idea who trigger the DMA READ/WRITE to an existed function (e.g 02:00.1 or any other under _ANY_ Marvell Magni series). For more details, I captured the PCIe trace and there was no _ANY_ TLP transactions related to 02:00.1. The workaround idea is simple, since The bridge refused the DMA access to/from 02:00.1, and I set the 02:00.1 as present in context entry and point it to the same domain as 02:00.0 does. Then it works well. It's tricky and I'm not sure if it _MAY_ corrupt the memory as I still can not explain who trigger the un-existed DMA access. Patch is as following and against 3.7 kernel. diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index d4a4cd4..188390f 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -1542,7 +1542,7 @@ static void domain_exit(struct dmar_domain *domain) free_domain_mem(domain); } -static int domain_context_mapping_one(struct dmar_domain *domain, int segment, +static int domain_context_mapping_one(struct dmar_domain *domain, struct pci_dev *pdev, int segment, u8 bus, u8 devfn, int translation) { struct context_entry *context; @@ -1555,6 +1555,7 @@ static int domain_context_mapping_one(struct dmar_domain *domain, int segment, int agaw; struct device_domain_info *info = NULL; +set: pr_debug("Set context mapping for %02x:%02x.%d\n", bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); @@ -1669,6 +1670,13 @@ static int domain_context_mapping_one(struct dmar_domain *domain, int segment, domain_update_iommu_cap(domain); } spin_unlock_irqrestore(&domain->iommu_lock, flags); + + if (pdev->vendor == 0x1b4b && + (pdev->device == 0x9125 || pdev->device == 0x9123) && + devfn == 0) { + devfn = 1; + goto set; + } return 0; } @@ -1679,7 +1687,7 @@ domain_context_mapping(struct dmar_domain *domain, struct pci_dev *pdev, int ret; struct pci_dev *tmp, *parent; - ret = domain_context_mapping_one(domain, pci_domain_nr(pdev->bus), + ret = domain_context_mapping_one(domain, pdev, pci_domain_nr(pdev->bus), pdev->bus->number, pdev->devfn, translation); if (ret) @@ -1692,7 +1700,7 @@ domain_context_mapping(struct dmar_domain *domain, struct pci_dev *pdev, /* Secondary interface's bus number and devfn 0 */ parent = pdev->bus->self; while (parent != tmp) { - ret = domain_context_mapping_one(domain, + ret = domain_context_mapping_one(domain, parent, pci_domain_nr(parent->bus), parent->bus->number, parent->devfn, translation); @@ -1701,12 +1709,12 @@ domain_context_mapping(struct dmar_domain *domain, struct pci_dev *pdev, parent = parent->bus->self; } if (pci_is_pcie(tmp)) /* this is a PCIe-to-PCI bridge */ - return domain_context_mapping_one(domain, + return domain_context_mapping_one(domain, tmp, pci_domain_nr(tmp->subordinate), tmp->subordinate->number, 0, translation); else /* this is a legacy PCI bridge */ - return domain_context_mapping_one(domain, + return domain_context_mapping_one(domain, tmp, pci_domain_nr(tmp->bus), tmp->bus->number, tmp->devfn,
Unfortunately this Bug is still there with Kernel 3.7.2 (strange enough everything works for me with the 3.6 kernel) I have the same Symptoms: Messages on boot: DRHD: handling fault status reg 2 DMAR:[DMA Write] Request device [02:00.1] fault addr fff00000 DMAR:[fault reason 02] Present bit in context entry is clear While running: SATA3 devices not recognized. everything works after adding to kernel commandline: intel_iommu=off The only thing that is new I guess is that it worked with all the other kernels just the 3.7 line has some problems. What would be the next step in this procedure?
(In reply to comment #17) > Unfortunately this Bug is still there with Kernel 3.7.2 (strange enough > everything works for me with the 3.6 kernel) > > I have the same Symptoms: > Messages on boot: > DRHD: handling fault status reg 2 > DMAR:[DMA Write] Request device [02:00.1] fault addr fff00000 > DMAR:[fault reason 02] Present bit in context entry is clear > > While running: > SATA3 devices not recognized. > > everything works after adding to kernel commandline: > intel_iommu=off > > The only thing that is new I guess is that it worked with all the other > kernels just the 3.7 line has some problems. > > What would be the next step in this procedure? Your specific issue is caused by the intel IOMMU being enabled by default in the -201 kernel. The -204 kernel has this disabled again and should work fine for you. We'll leave this disabled going forward.