[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.