From: paddieobrien@gmail.com (Paddie O'Brien)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Error reading /dev/mem
Date: Mon, 3 Oct 2016 11:00:15 +0100 [thread overview]
Message-ID: <CAOK12DZsAe_+5yvhudZ03MyBQ627jDRTCRNYOZ7MzAVfbXjQug@mail.gmail.com> (raw)
In-Reply-To: <CAGdaadYWufjisgaavHQex3-6QVJBCQZuBLME7-j9JoeRo3N-Sg@mail.gmail.com>
It is a 32-bit system.
I have a C program that puts a number in a variable. I then retrieve
the physical address of that variable using a system call I added to
the kernel. I next seek to that address in /dev/mem and verify that
what I find there matches the contents of the variable in my program.
All works fine i.e. the values match up except when the physical
address returned by the syscall is greater than 935321597. For lower
physical addresses there is no error. Once above the threshold I get a
"bad address" error when attempting the read from /dev/mem after
seeking to the appropriate location.
If I specify 512MB of physical memory on the VM then the problem goes
away since the physical address returned never exceeds the threshold.
So what you are suggesting is that there is a subrange of physical
addresses from which it is illegal to read in /dev/mem?
Thanks.
On 1 October 2016 at 18:45, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
>
>
> On Wed, Sep 28, 2016 at 2:49 AM, Paddie O'Brien <paddieobrien@gmail.com>
> wrote:
>>
>> Hi,
>>
>> I have a system call that maps virtual to physical addresses. I have
>> disabled CONFIG_STRICT_DEVMEM and am reading from /dev/mem to verify
>> that the contents of the syscall-returned physical address match the
>> contents of the virtual address. It works fine up to a point. Reading
>> beyond byte 935321597 in /dev/mem throws a "bad address" error. Not
>> sure it's relevant but I'm running on virtual box and specifying 1GB
>> of RAM. Tried with 2GB of RAM and hit the same problem.
>>
>> Any idea why I can't read beyond the above point?
>>
>> Thanks.
>>
>
> Hi paddie
>
> Is it 32 bit system?
>
> If yes, it seems you are about to exceed boundary of kernel linear addres
> range, which is 0-896 MiB. The upper 896-1024 MiB (1 GiB) is reserved for
> dynamic mapping
>
> CMIIW people.
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
next prev parent reply other threads:[~2016-10-03 10:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-27 19:49 Error reading /dev/mem Paddie O'Brien
2016-10-01 17:45 ` Mulyadi Santosa
2016-10-03 10:00 ` Paddie O'Brien [this message]
2016-10-10 6:55 ` Mulyadi Santosa
2016-10-03 13:00 ` Arun Sudhilal
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=CAOK12DZsAe_+5yvhudZ03MyBQ627jDRTCRNYOZ7MzAVfbXjQug@mail.gmail.com \
--to=paddieobrien@gmail.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/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;
as well as URLs for NNTP newsgroup(s).