broken memory chip -> software fix?

broken memory chip -> software fix?

[David Madore]

Hi all.

I have a broken bit in my memory - at address 0x04d5ae38 if you want
to know the details (bit 29 of the double word there sometimes reads
as 1 when it was written as 0, in particular if bit 15 is at 1).  I
discovered this by observing a one-bit corruption of some files, and
diagnosed it by running memtest86.

Now that I know the address, is there a way I can prevent Linux from
using that region of memory in any way?  The simplest and cleanest
way, would be, I guess, for a userland process I would write to ask of
the kernel to map permanently and unswappably the page at physical
location 0x04d5a000 to its virtual address space.  (Besides, that
would let me play with that broken bit.)

So: is there a way for a userland process (running at euid 0) to
request of the kernel an explicit physical address to virtual address
translation?  If so, how?  I would prefer not to have to patch the
kernel, if at all possible.

Thanks,

-- 
     David A. Madore
    (david.madore@ens.fr,
     http://www.eleves.ens.fr:8080/home/madore/ )

Re: broken memory chip -> software fix?

[John Levon]

On Fri, Aug 17, 2001 at 04:15:05PM +0200, David Madore wrote:

> Hi all.
> 
> I have a broken bit in my memory - at address 0x04d5ae38 if you want
> to know the details (bit 29 of the double word there sometimes reads
> as 1 when it was written as 0, in particular if bit 15 is at 1).  I
> discovered this by observing a one-bit corruption of some files, and
> diagnosed it by running memtest86.

badRAM patch linked from kernelnewbies.org/patches (please check there first
in the future, most things should be listed).

> translation?  If so, how?  I would prefer not to have to patch the
> kernel, if at all possible.

it's not

regards
john

-- 
"This bulletin discusses three security vulnerabilities that are
 unrelated except in the sense that both affect ISA Server 2000"
	- Microsoft Product Security

Re: broken memory chip -> software fix?

[Alan Cox]

> I have a broken bit in my memory - at address 0x04d5ae38 if you want
> to know the details (bit 29 of the double word there sometimes reads
> as 1 when it was written as 0, in particular if bit 15 is at 1).  I
> discovered this by observing a one-bit corruption of some files, and
> diagnosed it by running memtest86.
> 
> Now that I know the address, is there a way I can prevent Linux from
> using that region of memory in any way?  The simplest and cleanest

Yep. The mem= option can exclude stuff. Alternatively you can
patch arch/i386/kernel/mm/init.c:mem_init() to skip that page. 

Re: broken memory chip -> software fix?

[David Madore]

On Fri, Aug 17, 2001 at 03:25:15PM +0100, Alan Cox wrote:
> > Now that I know the address, is there a way I can prevent Linux from
> > using that region of memory in any way?  The simplest and cleanest
> 
> Yep. The mem= option can exclude stuff. Alternatively you can
> patch arch/i386/kernel/mm/init.c:mem_init() to skip that page. 

Thanks.  The mem= option works perfectly:

	mem=78184k@1024k mem=313988k@79212k

will avoid the incriminated page.

Thanks also to those who pointed out the mmap() procedure: that will
let toy with the page in question - after all, a defective memory chip
is a fun thing to play with.

-- 
     David A. Madore
    (david.madore@ens.fr,
     http://www.eleves.ens.fr:8080/home/madore/ )

Re: broken memory chip -> software fix?

[Richard B. Johnson]

On Fri, 17 Aug 2001, David Madore wrote:

> Hi all.
> 
> I have a broken bit in my memory - at address 0x04d5ae38 if you want
> to know the details (bit 29 of the double word there sometimes reads
> as 1 when it was written as 0, in particular if bit 15 is at 1).  I
> discovered this by observing a one-bit corruption of some files, and
> diagnosed it by running memtest86.
> 
> Now that I know the address, is there a way I can prevent Linux from
> using that region of memory in any way?  The simplest and cleanest
> way, would be, I guess, for a userland process I would write to ask of
> the kernel to map permanently and unswappably the page at physical
> location 0x04d5a000 to its virtual address space.  (Besides, that
> would let me play with that broken bit.)
> 
> So: is there a way for a userland process (running at euid 0) to
> request of the kernel an explicit physical address to virtual address
> translation?  If so, how?  I would prefer not to have to patch the
> kernel, if at all possible.
> 
> Thanks,
> 

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.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: broken memory chip -> software fix?

[Dr. Michael Weller]

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.