public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ross Biro <ross.biro@gmail.com>
To: root@chaos.analogic.com
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: Kernel writes to RAM it doesn't own on 2.4.24
Date: Fri, 16 Apr 2004 09:09:14 -0700	[thread overview]
Message-ID: <73979326.58EE2AD2@mail.gmail.com> (raw)
In-Reply-To: Pine.LNX.4.53.0404161150450.542@chaos

mem= isn't there to tell the kernel what ram it owns and what ram it
doesn't own.  It's there to tell the kernel what ram is in the system.
 Since you told the system it only has 500m, it assumes the rest of
the 3.5G of address space is available for things like memory mapped
i/o.  If you cat /proc/iomem, you'll probably see something has
reserved the memory range in question.

I added a hack to make the kernel assume the greater of the mem= and
what is passed to in from the BIOS via the e820 maps is where the
unused address space starts.  It seems to eliminate such problems.

    Ross

On Fri, 16 Apr 2004 11:55:28 -0400 (EDT), Richard B. Johnson
<root@chaos.analogic.com> wrote:
> 
> 
> Hello again,
> 
> If I start a system that has 1 Gb of memory with mem=500m,
> the value of the kernel's num_physpages is 0x20000 as would
> be expected. If I multiply that by PAGE_SIZE, I get 0x20000000,
> also as expected. If I observe that memory region, I note
> that somebody has written something there!
> 
> This is not good. The kernel touches RAM it doesn't own. I have
> booted the system with only the internal floppy controller
> and no other modules installed. I see the same thing.
> 
> Script started on Fri Apr 16 11:33:39 2004
> # monitor
>                   TMD Platinum(tm) Control System Version 2.0
>                  Copyright(c) 1999-2003, Analogic Corporation
> 
>   Enter "help" for commands
> 
> PLATINUM> dump=20000000
> 20000000  78 56 34 12 21 43 65 87-FF FF FF FF FF FF FF FF   xV4.!Ce.........
> 20000010  FF FF FF FF FF FF FF FD-FF FF FF FF FF FF FF FF   ................
> 20000020  FF FF FF FF FF FE FF FF-FF FF FE FF FF FF FF FF   ................
> [SNIPPED...]
> 
> My temporary work around for the kernel's destroying a
> precious DMA buffer is to start one page higher. However,
> whomever is writing to that RAM is likely writing other
> places it doesn't belong also. This could lead to some
> very interesting bugs.
> 
> Note that the value written there is 0x12345678, twice, once
> in little endian and another in swap-nibble big endian, like
> a mirror. This is evil.
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.24 on an i686 machine (5596.77 BogoMips).
>             Note 96.31% of all statistics are fiction.
> -
> 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/
>

  reply	other threads:[~2004-04-16 16:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-16 15:55 Kernel writes to RAM it doesn't own on 2.4.24 Richard B. Johnson
2004-04-16 16:09 ` Ross Biro [this message]
2004-04-16 16:55   ` Richard B. Johnson
2004-04-16 17:07     ` Ross Biro
  -- strict thread matches above, loose matches on Subject: below --
2004-04-17  4:40 Ross Dickson
2004-04-17 12:40 ` Ross Biro
2004-04-20 16:46   ` Ross Biro
2004-04-17 20:21 ` H. Peter Anvin

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=73979326.58EE2AD2@mail.gmail.com \
    --to=ross.biro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /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