[PATCH] Re: [Xen-ia64-devel] vcpu_translate: bad physical address: a000f00100cf0000

[Matthew Chapman <matthewc@xxxxxx>]

I've tracked this down...

Recent versions of the GNU assembler break old versions of Linux
(such as 2.6.12, which Xen is still stuck on :().  This has since
been fixed in Linux:

http://www.kernel.org/hg/linux-2.6/?cs=566cb6bb9a1f

We're also missing the following related changesets:

http://www.kernel.org/hg/linux-2.6/?cs=03d3983a2532
http://www.kernel.org/hg/linux-2.6/?cs=28141b613101

Patches are attached:

* ia64-new-as*.patch are the raw Linux patches for patch.c and
  entry.h.  These go in patches/linux-2.6.12/ in the Xen source
  tree.

* sparse-new-as.patch is the patch to entry.S, which currently
  lives in the sparse tree.  (Though IMHO, for ease of porting to
  a new kernel, it would be better if all of the entry.S changes
  were a patch and not a whole file... I'll do that if there's no
  objections?)

* xen-new-as.patch is the same as ia64-new-as1.patch, but
  relocated to apply to xen/arch/ia64/linux (the other patches
  are already present, since the Xen sources are based on 2.6.13
  and not 2.6.12).

  I've patched xen/arch/ia64/linux/patch.c directly, because it's
  not a Xen-specific change, and *should* be clobbered by more
  recent Linux sources when they are imported in the future.

Matt

Signed-off-by: Matthew Chapman <matthewc@xxxxxx>


On Fri, Jan 20, 2006 at 12:33:05AM +1100, Matthew Chapman wrote:
> The current Xen/ia64 tree doesn't work for me, Dom0 dies here:
> 
> Memory: 491056k/523264k available (11335k code, 31600k reserved, 4831k data, 
> 304k init)
> (XEN) vcpu_translate: bad physical address: a000f00100cf0000 @ 
> a0000001000080d0 (kr7=000000000ccec000)
> [machine check]
> 
> The erroneous fault is in vhpt_miss while handling a region 5
> miss (the first, from ia64_patch_gate).  The address comes from:
> 
>   LOAD_PHYSICAL(p6, r19, swapper_pg_dir)
> 
> which is a movl which is patched into a physical address by
> ia64_patch_vtop.
> 
> The unpatched value is 0xa000000100cf0000, and it should have
> been patched to 0xccf0000.  Having added some debug output to
> ia64_patch_imm64, it seems that tpa produces the right value, and
> it tries to patch it.
> 
> However, something obviously goes wrong, since the address above
> is neither the unpatched address nor the intended physical
> address.
> 
> Anyone seen this before?
> 
> Matt
> 
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel

Attachment: ia64-new-as1.patch
Description: Text document

Attachment: ia64-new-as2.patch
Description: Text document

Attachment: sparse-new-as.patch
Description: Text document

Attachment: xen-new-as.patch
Description: Text document

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