Bug 82837 - /dev/mem mlock physical virtual memory program error
Summary: /dev/mem mlock physical virtual memory program error
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-27 16:36 UTC by Stefano Righi
Modified: 2007-03-27 04:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-30 15:40:28 UTC

Attachments (Terms of Use)
testcase (1.07 KB, text/plain)
2003-01-28 15:32 UTC, Stefano Righi
no flags Details
result of the run on FreeBSD (2.20 KB, text/plain)
2003-01-29 19:00 UTC, Stefano Righi
no flags Details
Results of the run on Linux (1.75 KB, text/plain)
2003-01-29 19:01 UTC, Stefano Righi
no flags Details

Description Stefano Righi 2003-01-27 16:36:22 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)

Description of problem:
I have created an utility for updating AMIBIOS. It works on all system tested 
till now except with Red Hat 8.0 2.4.18-14smp with 1GB of memory or more.
The root cause is the folowing:
The program allocate memory using calloc and call mlock to avoid swapping (I 
want to be sure that what the program has written stay in physical memory).
Then I read through /dev/mem scanning all memory location to search for the 
pattern written in the calloc'ed and mlock'ed. (I use read because with mmap I 
cannot access memory above 256MB).
In all other test cases I find the pattern, in the above test case I do not 
find the pattern.
This cause my application to NOT work.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. have 1GB of memory installed in the system or more
2. use kernel
3. run my test application with debug printf on the screen

Actual Results:  My program do not read the right information through /dev/mem

Expected Results:  My program should read expected information from /dev/mem

Additional info:

Comment 1 Arjan van de Ven 2003-01-27 16:42:39 UTC
What is the purpose of the /dev/mem sweep?
Please be aware that mlock() is no guarantee that the physical address of a page
doesn't change, just that it doesn't get swapped out
Also memory can be in the > 4Gb area if a machine has > 4Gb ram... 

Comment 2 Stefano Righi 2003-01-27 16:56:35 UTC
The reason of the sweep is to find the physical address where the buffer is 
It is weird that with less memory I can find it and not with more memory: it is 
stated that it is not guaranteed to stay in same location but I would expect 
the location to change more easily in case of less memory, instead it is 
happening with more memory...
What is the "best practice" way to obtain a buffer in a locked physical 
location? I cannot use a driver because I cannot rebuild the utility for every 
different distribution...
Now documentation mention that the reason of mlock is for "Real-time 
applications require deterministic timing, and, like scheduling, paging is one 
major cause of unexpected program execution delays". Now if the physical 
location changes this requisite for mlock is NOT satisfied: also moving among 
different memory location cause non-deterministic timing...
I really think that the problem is not that the information is moved in memory 
but one of the two:
- the locking does not work and the info is paged out
- through /dev/mem I cannot access the entire physical memory
I think more at the second case because when I read /dev/mem I can read only up 
to 0x38000000 in a 1GB system: this mean I am unable to read the last 128MB.
By the way I have tryed also with shared object without any meaningful change 
and with mmap, but in this case I can access only the first 256MB of memory.

Comment 3 Arjan van de Ven 2003-01-27 17:00:02 UTC
you are correct that the moving thing is not the cause of the problem you see:
the fact that /dev/mem only gives back kernel memory and not high memory is. I
just wanted to point out that it was likely that for what you tried to solve
/dev/mem might be the wrong interface.
It sounds like you actually want a kernel driver. If the driver is GPL I'm sure
Red Hat and all other distros would be more than happy to include it by default....

Comment 4 Stefano Righi 2003-01-27 17:06:57 UTC
I do NOT want to write a driver for this. 
You state that /dev/mem is not the right interface but accordign to the 
documentation it is the "physical memory". Does it means that the documentation 
is wrong?
I have tryed also /proc/kcore with same results.
What is the "right" interface according to Red Hat? Please do not answer a 
driver, for the official documentation this is not needed.
Don't you think it is a but of /dev/mem? Which means we need a patch?

Comment 5 Stefano Righi 2003-01-27 19:54:24 UTC
Just a quick note. Before I stated something regarding usage of mmap that is 
not correct. Using mmap I do not get any error from mmap on all the 4GB address 
space: a pointer is always returned, but this does not mean I find the 
information I need to find in memory... I am still thinking to some kernel 

Comment 6 Stefano Righi 2003-01-28 15:32:30 UTC
Created attachment 89647 [details]

OK, here is a quick test. This code in FreeBSD always report the same value
from read and the value obtained using the pointer returned by mmap, while in
Linux the result is very odd.
Do you have an explanation for it?

Comment 7 Stefano Righi 2003-01-29 19:00:30 UTC
Created attachment 89687 [details]
result of the run on FreeBSD

Comment 8 Stefano Righi 2003-01-29 19:01:22 UTC
Created attachment 89688 [details]
Results of the run on Linux

Comment 9 Bugzilla owner 2004-09-30 15:40:28 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.