All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Biro <ross.biro@gmail.com>
To: root@chaos.analogic.com
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: Kernel writes to RAM it doesn't own on 2.4.24
Date: Fri, 16 Apr 2004 10:07:44 -0700	[thread overview]
Message-ID: <73CA03E0.6595EF57@mail.gmail.com> (raw)
In-Reply-To: Pine.LNX.4.53.0404161251570.10809@chaos

On Fri, 16 Apr 2004 12:55:33 -0400 (EDT), Richard B. Johnson
<root@chaos.analogic.com> wrote:
> 
> On Fri, 16 Apr 2004, Ross Biro wrote:
> 
> > mem= isn't there to tell the kernel what ram it owns and what ram it
> > doesn't own.  It's there to tell the kernel what ram is in the system.
> >  Since you told the system it only has 500m, it assumes the rest of
> > the 3.5G of address space is available for things like memory mapped
> > i/o.  If you cat /proc/iomem, you'll probably see something has
> > reserved the memory range in question.
> >
> 
> No!  This is address space, not RAM. Whether or not a PCI device
> or whatever has internal RAM that's mapped makes no difference.
> 
> I told the kernel that it has 500m of RAM. It better not assume
> I don't know what I'm talking about. I might have reserved that
> RAM because it's bad or I may have something else important to
> do with that RAM (which I do).

The problem is that the kernel does assume you know what you are
talking about, and you don't.  You are abusing the mem= parameter. 
That's fine, but then you have to tell the kernel what you really
mean.  What you really want to say is there is memory above 500M and I
don't want you to touch it.  There may be a way to do that via the
fancy mem=@ parameters.

What mem= tells the kernel is that there is RAM in a certain spot an
no where else.  Since you told the kernel there is no ram about 500M,
that means that address space is free to be used for memory mapped
I/O.  Since the kernel trusts you, it started using the memory above
500m for memory mapped i/o.  Since you LIED to the kernel, you are
getting results you do not like.  The solution I settled on was to
tell the kernel that people LIE to it and only use memory for I/O if
both the BIOS and the USER agree that it's available.   You have to
find a way to tell the kernel the TRUTH, or you will never get the
results you want.

  reply	other threads:[~2004-04-16 17:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-16 15:55 Kernel writes to RAM it doesn't own on 2.4.24 Richard B. Johnson
2004-04-16 16:09 ` Ross Biro
2004-04-16 16:55   ` Richard B. Johnson
2004-04-16 17:07     ` Ross Biro [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-04-17  4:40 Ross Dickson
2004-04-17 12:40 ` Ross Biro
2004-04-20 16:46   ` Ross Biro
2004-04-17 20:21 ` H. Peter Anvin

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=73CA03E0.6595EF57@mail.gmail.com \
    --to=ross.biro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /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.