public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Xen-ia64-devel] Re: ia64 kexec: xen -> linux
Date: Thu, 05 Oct 2006 16:52:58 +0000	[thread overview]
Message-ID: <200610051052.59117.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <200609271152.12393.Tristan.Gingold@bull.net>

On Wednesday 04 October 2006 20:53, Horms wrote:
> On Fri, Sep 29, 2006 at 12:48:19PM +0900, Horms wrote:
> > On Wed, Sep 27, 2006 at 11:52:12AM +0200, Tristan Gingold wrote:
> > > Linux and xen call efi in real mode if set_virtual_address_map fails.
> > > You may add an option in both xen and linux to force calling efi in real mode.
> > > This should be really simple and you will be able to make progress.
> > 
> > I took a stab at forcing the call to stay in real mode, 
> > by simply replacing the call to set_virtual_address_map with
> > a return. This should both prevent the mapping from occuring,
> > and force the kernel to use the real mode variants of the calls.
> > 
> > Unfortunately, the boot fails with the following log.
> > A bit of investigation has found that is it dying in
> > 
> >    SAL_CALL()
> >    called by: ia64_sal_cache_flush()
> >    called by: ia64_sal_cache_flush()
> >    called by: ia64_sal_init()
> > 
> > Well, when I say dying in, its probably more accurate to say,
> > never returning from.

I haven't been following this thread and don't know whether
this is related, but someone here is seeing an MCA in this
early SAL_CACHE_FLUSH call.  I haven't looked at it in detail
yet, but apparently it happens because we're making the call
in virtual mode before we have completely set up the TLB and VHPT.

> > I'm a bit of a loss to know why this is occuring. Though
> > I do wonder if SAL (and in this case indrectly PAL) calls are
> > are running into trouble by runing in real mode without
> > set_virtual_address_map() having being called.

SAL_CACHE_FLUSH is one of a few SAL calls that invoke PAL
procedures, and they can't be used in virtual mode until the
OS registers the virtual address of PAL (see SAL spec section
9.1.1).

> It turns out that this was indeed the case, and running SAL calls
> in physical mode (regardless of if EFI is making physical or virtual
> mode calls) seems to fix this boot failure. Though I am yet to determin
> it it solves the xen->linux, linux->xen kexec problem.

In general (I'm not speaking to xen or kexec), I think we want
to run SAL calls in virtual mode.  It looks like we have a problem
with the specific SAL_CACHE_FLUSH call above, but we should be able
to fix that specific problem without changing how we do other SAL
calls.

Bjorn

  parent reply	other threads:[~2006-10-05 16:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-27  9:52 [Xen-ia64-devel] Re: ia64 kexec: xen -> linux Tristan Gingold
2006-09-28  1:27 ` Horms
2006-09-28  6:55 ` Tristan Gingold
2006-09-28  7:00 ` Horms
2006-09-28 12:33 ` Magnus Damm
2006-09-28 12:34 ` Magnus Damm
2006-09-28 12:47 ` Tristan Gingold
2006-09-29  2:21 ` Zou, Nanhai
2006-09-29  3:03 ` Horms
2006-09-29  3:48 ` Horms
2006-09-29  5:13 ` Zou, Nanhai
2006-09-29  5:37 ` Horms
2006-10-05  2:53 ` Horms
2006-10-05 16:52 ` Bjorn Helgaas [this message]
2006-10-06  1:44 ` Horms

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200610051052.59117.bjorn.helgaas@hp.com \
    --to=bjorn.helgaas@hp.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox