[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7 3770
On Mon, Sep 3, 2012 at 9:30 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: Hi Jan, >>> > [ 0.358278] DMAR:[DMA Read] Request device [00:02.0] fault addr >>> > 9fac7000 >>> > [ 0.358278] DMAR:[fault reason 06] PTE Read access is not set >>> > [ 0.358286] DRHD: handling fault status reg 2 >>> > [ 0.358288] DMAR:[DMA Read] Request device [00:02.0] fault addr >>> > 9fac7000 >>> > [ 0.358288] DMAR:[fault reason 06] PTE Read access is not set >>> > [ 0.358291] DMAR:[DMA Read] Request device [00:02.0] fault addr >>> > 9fac7000 >>> > [ 0.358291] DMAR:[fault reason 06] PTE Read access is not set >>> > [ 0.358307] DRHD: handling fault status reg 3 >>> > >>> > Furthermore, later on, just after enabling the IOMMU, I get this: >>> > >>> > [ 0.328564] DMAR: No ATSR found >>> > [ 0.328580] IOMMU 1 0xfed91000: using Queued invalidation >>> > [ 0.328582] IOMMU: Setting RMRR: >>> > [ 0.328589] IOMMU: Setting identity map for device 0000:00:1d.0 >>> > [0x9de36000 - 0x9de52fff] >>> > [ 0.328606] IOMMU: Setting identity map for device 0000:00:1a.0 >>> > [0x9de36000 - 0x9de52fff] >>> > [ 0.328617] IOMMU: Setting identity map for device 0000:00:14.0 >>> > [0x9de36000 - 0x9de52fff] >>> > [ 0.328625] IOMMU: Prepare 0-16MiB unity mapping for LPC >>> > [ 0.328630] IOMMU: Setting identity map for device 0000:00:1f.0 >>> > [0x0 - 0xffffff] >>> >>> All of these messages shouldn't appear when running under Xen, >>> as it's the hypervisor, not the kernel to take care of the IOMMU(s). >>> The logs you had pointers to confirm this - are you sure the above >>> was seen when running under Xen? >> >> I'm sorry I didn't make myself clearer. That dmesg output is when booting >> WITHOUT xen, that is, linux directly over the bare hardware. Under xen >> those errors dissapear. >> >> The big issue I'm having running xen is that I can't use it since xen can't >> get the cpu capabilities. > > What "cpu capabilities"? I just looked at your original mail again, > and I cannot see what failure you're referring to (in fact, I'm not > able to spot any failure in that log at all). And of course you didn't > even attach a hypervisor log. What am I missing? These are all the xen and virt-manager logs: http://dl.dropbox.com/u/12579112/hypervisor.log http://dl.dropbox.com/u/12579112/qemu-dm-Windows7.log http://dl.dropbox.com/u/12579112/virt-manager.log http://dl.dropbox.com/u/12579112/xen-hotplug.log http://dl.dropbox.com/u/12579112/xend.log http://dl.dropbox.com/u/12579112/xend-debug.log http://dl.dropbox.com/u/12579112/xenstored-trace.log.gz In the virt-manager logs you can see an instance of kvm and an instance of xen. See the difference in the cpu capabilities detected. As far as the hypervisor goes, the only error logged is: (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of mfn xxxxxx: c=c000000000000002 t=7400000000000001 If I can provide any other useful info please ask. -- Javier Marcet <jmarcet@xxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |