All of lore.kernel.org
 help / color / mirror / Atom feed
From: Horms <horms@verge.net.au>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] ia64, kexec: allow base of crashkernel to be auto-discovered
Date: Fri, 30 Jun 2006 03:56:55 +0000	[thread overview]
Message-ID: <20060630035652.GA18087@verge.net.au> (raw)
In-Reply-To: <20060628110052.GA11751@verge.net.au>

On Thu, Jun 29, 2006 at 02:51:33PM -0700, Luck, Tony wrote:
> > >   Also it is wrong to put TLB map of RAM that does not exist together
> > > with kernel text and data.
> > 
> > Sorry, I don't understand that.
> 
> Here's an example.  Many systems have (for legacy reasons) mapped
> VGA memory at 0xA0000-0xC0000.  This memory is typically uncacheable
> so that when you write to those addresses the bits show up on the
> screen (rather than sitting in the processor cache for some indeterminate
> amount of time).
> 
> Now if Linux is using a 64MB entry to map the kernel, and the kernel
> has been loaded into the bottom 64M of memory, the mapping for the
> kernel (which has a WB attribute) will overlap the VGA memory (which
> doesn't support WB) ... and so you will most probably machine check
> when someone accesses the VGA (or worse if some speculative access or
> prefetch happens to pull from the VGA area).
> 
> So the rule is that Linux must never create TLB mappings for things
> that don't exist, or for blocks of memory with incompatible attributes.

I might be confused, but I'm not exactly sure that my patch would run
into this problem. It only tries to insert the "Crash kernel" resource
as a sub-resource of an existing "System RAM" resource, and does so in
such a way that it should not overlap with any existing sub-resources.
Surely VGA and the like are in completely different resources not
covered by a "System RAM" resource.

-- 
Horms                                           
H: http://www.vergenet.net/~horms/          W: http://www.valinux.co.jp/en/


  parent reply	other threads:[~2006-06-30  3:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-28 11:00 [PATCH] ia64, kexec: allow base of crashkernel to be auto-discovered Horms
2006-06-28 22:38 ` [PATCH] ia64, kexec: allow base of crashkernel to be Zou Nan hai
2006-06-29  0:29 ` Zou Nan hai
2006-06-29  1:44 ` [PATCH] ia64, kexec: allow base of crashkernel to be auto-discovered Horms
2006-06-29  4:23 ` Horms
2006-06-29 21:51 ` Luck, Tony
2006-06-30  3:56 ` Horms [this message]
2006-07-05  0:42 ` Horms
2006-07-05 19:16 ` Luck, Tony
2006-07-06  8:24 ` 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=20060630035652.GA18087@verge.net.au \
    --to=horms@verge.net.au \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.