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: Always Steps to Reproduce: 1. have 1GB of memory installed in the system or more 2. use kernel 2.4.18.14-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 Additional info:
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 allocated. 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.
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....
Again, 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?
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 problem...
Created attachment 89647 [details] testcase 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 persists. 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/