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>
next parent 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