lkml.org 
[lkml]   [2001]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: broken memory chip -> software fix?
On Fri, 17 Aug 2001, Richard B. Johnson wrote:

> mmap(0x04d5a000, PAGE_SIZE, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_FIXED, fd,
> ^^^^ page boundary
> 0);
>
> 'MAP_FIXED' is your friend. This will take the offending page size
> (0x1000) on x86, out of use and give it to you. 'fd' is initialized
> by opening /dev/mem.

Sorry, you are completely confusing things. MAP_FIXED in conjunction
with 0x04d5a000 will (attempt to) map to address 0x04d5a000 in the virtual
address space of the calling process. This has no relation what so ever to
the physical memory addressed. Rather than that, use the 0x04d5a000 as the
last argument to mmap (where we have the 0 above), the so called offset
in the file (/dev/mem). You don't need to fiddle with MAP_FIXED or the
first argument. It shouldn't matter to your program where the bad bit
shows up in it's address space (as long as it knows the actual address
chosen, cf. return value of mmap).

While this gives your program access to the physical memory, it doesn't
keep the kernel from using it as well. Use /dev/mem to access physical
memory, not to reserve it. For that use the other hints given on the list
aka mem= boot arg or kernel patch.

Michael.

--

Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de,
or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on
any machine in the net, it's very likely it's me.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:57    [W:0.060 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site