Re: [Xen-devel] "lshw" seems to get stuck at the "DMI" stage with 4.x

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2011-08-15 at 08:32 +0100, Jan Beulich wrote:
> >>> On 15.08.11 at 04:09, Andy Smith <andy@xxxxxxxxxxxxxx> wrote:
> > I just noticed that the "lshw" command gets stuck at the "DMI" stage
> > for me on all (three of) my Xen 4.x installs. Meanwhile the Xen
> > dmesg is filling with:
> > 
> > (XEN) mm.c:860:d0 Error getting mfn 1592 (pfn 601f) from L1 entry 
> > 8000000001592625 for l1e_owner=0, pg_owner=32753
> > (XEN) mm.c:860:d0 Error getting mfn 1592 (pfn 601f) from L1 entry 
> > 8000000001592625 for l1e_owner=0, pg_owner=32753
> 
> Hmm, 32753 is DOM_IO, and Dom0 is generally allowed to access DOM_IO
> pages. But the MFN's value as well as it having a valid PFN suggests
> that this is actually a RAM page (we'd know for sure only if you provided
> the memory map of the machine(s)), which certainly isn't valid to be
> accessed in the context of a DMI table access (or any mapping with the
> owner set to DOM_IO).
> 
> Also you don't state what kernel you use in Dom0.
> 
> > until I ctrl-c the lshw.
> > 
> > lshw works fine on my Xen 3.x installs.
> 
> Quite possible that the tighter checking in newer Xen is responsible
> for this, so you may want to add some further debugging code to
> the code paths involved. But it's also possible that there was a bug
> in 3.x accidentally letting the access go through.

It may also matter which kernel Andy is combining with his 3.x and 4.x
installs. Konrad did some work on improving the handling of identity
mapped regions of the p2m space which could be related to something like
this.

Ian.

> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel