Re: broken memory chip -> software fix?

From: Dr. Michael Weller (eowmob@exp-math.uni-essen.de)
Date: Fri Aug 17 2001 - 09:46:22 EST


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/



This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:23 EST