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):
Steps to Reproduce:
1. have 1GB of memory installed in the system or more
2. use kernel 18.104.22.168-smp
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
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...
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
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.
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....
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
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?
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
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?
Created attachment 89687 [details]
result of the run on FreeBSD
Created attachment 89688 [details]
Results of the run on Linux
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/