slram reserve its memory region?

Ryan Underwood nemesis-lists at icequake.net
Fri Jun 24 21:54:30 EDT 2005


I am having a problem where slram fails to reserve the memory it is
using, allowing a later-loaded PCI driver (yenta_socket) to have PCI
resources mapped in the same area, which results in a non-functional
hardware.  This effect is only possible because mem= kernel parameter is
required to prevent the kernel from using memory that slram will be
using later, but unfortunately device resources can still be mapped
there since the kernel thinks slram's area is not physical RAM and is
thus safe to use.

Is it an easy change to cause slram to reserve the memory area it uses
so that nothing else attempts to use it?

Ryan

----- Forwarded message from Russell King <rmk+pcmcia at arm.linux.org.uk> -----

On Tue, Jun 21, 2005 at 08:58:15PM -0500, Ryan Underwood wrote:
> Ok, this now appears to allow Cardbus cards to work.  Unfortunately the
> 16-bit card doesn't work unless the BIOS is set to PCIC Compatible mode,
> which means I can't use a Cardbus and 16-bit card at the same time as
> with 2.4 and pcmcia-cs.  I also need mem=64M so that I can use uncached
> RAM as slram device.

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.

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.

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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core


----- End forwarded message -----

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




More information about the linux-mtd mailing list