Bug 863653
| Summary: | ahci_stop_engine: BUG: unable to handle kernel paging request at ffffc90005337018 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Sanne Bregman <sanne> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | acooks, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, sanne |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | abrt_hash:dc7866292b3e388707aa8d573697da4e662c5a1b | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-11-27 16:02:37 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Sanne Bregman
2012-10-06 10:03:07 UTC
After removing the PCIe bridges (the PLX technology devices from above) I can try to start the VM, but it gives me an error that the USB and SATA devices are not assignable. So my best guess is that there might be an error in the redirection of PCIe bridges, or that I just did something very stupid :P *** Bug 863652 has been marked as a duplicate of this bug. *** Are you still able to recreate this with 3.6.6 or newer? Tested this, but couldn't reproduce it. virt-manager now tells me that I can't assign the whole PCIe switch to a VM. So I guess this is "fixed", but at a higher level than the kernel I guess? (In reply to comment #3) > Are you still able to recreate this with 3.6.6 or newer? No fix/quirk has been added to enable DMAR with Marvell 88SE91xx SATA controllers as of 3.6.6. See also bug 757166. What I also noticed, that the card (Asus U3S6) stopped complaining a LOT during bootup (it delayed bootup for ~30 seconds). So I don't know what happened, but it was something good! Patrick, the delay may be gone, but I expected the DMAR errors to continue up to at least 3.9-rc1. Can you confirm whether you can use a drive attached to this controller with the iommu enabled? I could use it, just not in a virtual machine. I've been running ZFS on Linux on that card for a little while, but I've recently replaced the card with a more suitable one. I could try it again, but I won't have a chance for that before next weekend I'm afraid. A bit late, but I had some hardware issues. Anyway. I installed the card again, and I get the boot slowdown again (see log below). In the virtual machine I ran GParted to check it, and I get a few FIS resets and after that I can't actually use it. I connected a 80GB disk to it, but GParted doesn't see the disk. It does see the controller, and I can see the controller BIOS running in the VM. Long story short, I don't see attached storage in the VM but I do see the cards BIOS loading in the VM. The log (with a bit of explanation): --- This is the initial start of the host (running Fedora 18), same as before [ 0.023657] dmar: Host address width 36 [ 0.023659] dmar: DRHD base: 0x000000fed90000 flags: 0x0 [ 0.023666] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a [ 0.023667] dmar: DRHD base: 0x000000fed91000 flags: 0x1 [ 0.023671] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a [ 0.023672] dmar: RMRR base: 0x000000da23e000 end: 0x000000da24bfff [ 0.023673] dmar: RMRR base: 0x000000db800000 end: 0x000000df9fffff [ 0.023744] IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 --- --- This is upon starting the VM, requests coming from a subdevice??? [ 911.428243] pci-stub 0000:03:00.0: claimed by stub [ 911.429493] pci-stub 0000:04:00.0: claimed by stub [ 911.960154] device vnet0 entered promiscuous mode [ 911.971229] br0: port 2(vnet0) entered forwarding state [ 911.971252] br0: port 2(vnet0) entered forwarding state [ 912.070976] br0: port 2(vnet0) entered forwarding state [ 912.803708] assign device 0:3:0.0 [ 912.826069] assign device 0:4:0.0 [ 1018.553004] kvm [6637]: vcpu0 unhandled rdmsr: 0x345 [ 1018.555037] kvm_set_msr_common: 22 callbacks suppressed [ 1018.555039] kvm [6637]: vcpu0 unhandled wrmsr: 0x680 data 0 [ 1018.555042] kvm [6637]: vcpu0 unhandled wrmsr: 0x6c0 data 0 [ 1018.555043] kvm [6637]: vcpu0 unhandled wrmsr: 0x681 data 0 [ 1018.555045] kvm [6637]: vcpu0 unhandled wrmsr: 0x6c1 data 0 [ 1018.555047] kvm [6637]: vcpu0 unhandled wrmsr: 0x682 data 0 [ 1018.555049] kvm [6637]: vcpu0 unhandled wrmsr: 0x6c2 data 0 [ 1018.555051] kvm [6637]: vcpu0 unhandled wrmsr: 0x683 data 0 [ 1018.555052] kvm [6637]: vcpu0 unhandled wrmsr: 0x6c3 data 0 [ 1018.555054] kvm [6637]: vcpu0 unhandled wrmsr: 0x684 data 0 [ 1018.555056] kvm [6637]: vcpu0 unhandled wrmsr: 0x6c4 data 0 [ 1020.535437] pci-stub 0000:03:00.0: irq 49 for MSI/MSI-X [ 1020.572358] pci-stub 0000:03:00.0: irq 49 for MSI/MSI-X [ 1020.572368] pci-stub 0000:03:00.0: irq 51 for MSI/MSI-X [ 1020.608267] pci-stub 0000:04:00.0: irq 52 for MSI/MSI-X [ 1020.640122] dmar: DRHD: handling fault status reg 2 [ 1020.640132] dmar: DMAR:[DMA Write] Request device [04:00.1] fault addr 37240000 DMAR:[fault reason 02] Present bit in context entry is clear [ 1030.623429] dmar: DRHD: handling fault status reg 2 [ 1030.623438] dmar: DMAR:[DMA Write] Request device [04:00.1] fault addr 37240000 DMAR:[fault reason 02] Present bit in context entry is clear [ 1040.610126] dmar: DRHD: handling fault status reg 2 [ 1040.610134] dmar: DMAR:[DMA Write] Request device [04:00.1] fault addr 37240000 DMAR:[fault reason 02] Present bit in context entry is clear [ 1075.563641] dmar: DRHD: handling fault status reg 2 [ 1075.563650] dmar: DMAR:[DMA Write] Request device [04:00.1] fault addr 37240000 DMAR:[fault reason 02] Present bit in context entry is clear --- lspci for completeness: 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/Ivy Bridge DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/Ivy Bridge Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.7 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 8 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation H77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 01:00.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) 02:01.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) 02:05.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) 02:07.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) 02:09.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) 03:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) 04:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9120 SATA 6Gb/s Controller (rev 12) 08:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01) As lspci shows, there is no PCIe device 04:00.1... I find this kinda weird, why is a non-existing device sending messages? Hope this helps, if you need more information, just give me a shout! *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. It has been over a month since we asked you to test the 3.11 kernel updates and let us know if your issue has been resolved or is still a problem. When this happened, the bug was set to needinfo. Because the needinfo is still set, we assume either this is no longer a problem, or you cannot provide additional information to help us resolve the issue. As a result we are closing with insufficient data. If this is still a problem, we apologize, feel free to reopen the bug and provide more information so that we can work towards a resolution If you experience different issues, please open a new bug report for those. This is a comment to stop getting weekly mails about this old bug. Sorry to bump it! |