public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Ryan Underwood <nemesis-lists@icequake.net>
To: linux-mtd@lists.infradead.org
Cc: rmk+pcmcia@arm.linux.org.uk
Subject: Re: Toshiba 64M limit and slram (was Toshiba ToPIC developer info)
Date: Wed, 22 Jun 2005 14:55:57 -0500	[thread overview]
Message-ID: <20050622195557.GA25758@dbz.icequake.net> (raw)
In-Reply-To: <20050622101621.B28181@flint.arm.linux.org.uk>


On Wed, Jun 22, 2005 at 10:16:21AM +0100, Russell King wrote:
> 
> Unfortunately, the kernel needs to know how much RAM you really have so
> it can properly allocate memory resources.  Lying to it (by passing mem=)
> is generally a recipe for disaster.

I was under the impression that using the mem= parameter simply
truncated the high memory area, so the kernel would behave as if you
only had that amount of memory installed.

> However, if slram is making use of some area of memory, it really should
> reserve it.  That's a slram bug - please report it to the mtd mailing
> list.

I will do so.  However, it seems impossible for slram to reserve i.e.
64M-160M area unless the kernel is disallowed from using it for other
reasons.  Surely something would be allocated there already by the
time slram was activated.

> Even with slram fixed, there remains the danger of something trying to
> allocate a resource _before_ slram claims its resource...  I just hate
> the entire mem= mess entirely for this very reason.  It's completely
> unsafe.

What is the best thing to do then?  Ever since slram was designed, it
has assumed that the user would set the mem= option appropriately.  I've
had the 'reserve' option pointed to me but not tried it yet.

-- 
Ryan Underwood, <nemesis@icequake.net>

       reply	other threads:[~2005-06-22 19:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050613182441.GC23036@dbz.icequake.net>
     [not found] ` <20050613104838.GA23036@dbz.icequake.net>
     [not found]   ` <20050611231733.GA10349@dbz.icequake.net>
     [not found]     ` <1251495.1118575059614.komurojun-mbn@nifty.com>
     [not found]       ` <2687305.1118667124185.komurojun-mbn@nifty.com>
     [not found]         ` <4050205.1118836800033.komurojun-mbn@nifty.com>
     [not found]           ` <8247339.1118928170515.komurojun-mbn@nifty.com>
     [not found]             ` <5186040.1119048110920.komurojun-mbn@nifty.com>
     [not found]               ` <20050622015815.GA22559@dbz.icequake.net>
     [not found]                 ` <20050622101621.B28181@flint.arm.linux.org.uk>
2005-06-22 19:55                   ` Ryan Underwood [this message]
2005-06-22 20:10                     ` Toshiba 64M limit and slram (was Toshiba ToPIC developer info) Russell King
2005-06-22 21:21                       ` Jörn Engel
2005-06-22 22:27                       ` Ryan Underwood

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=20050622195557.GA25758@dbz.icequake.net \
    --to=nemesis-lists@icequake.net \
    --cc=linux-mtd@lists.infradead.org \
    --cc=rmk+pcmcia@arm.linux.org.uk \
    /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