Re: flexible-mmap breaks application
On Tue, 2005-03-15 at 15:55, Uwe Bonnes (bon_at_elektron.ikp.physik.tu-darmstadt.de) wrote: The definition of the task is clear: Have a way to tell the kernel to not mmap memory above 0x7fff However the implementation is unclear to me: - Should this be a new syscall? - Or should we set some kernel parameter? Per task or global? There is a related problem in that Wine's VirtualAlloc won't allocate the full 2GB it should. As I understand it the problem is the different memory ranges that linux and windows allocate from --- the intersection of the two platforms is only 1GB (not the 2GB it should be) from 0x4000, to 0x8000,. Could this patch also include a lower limit, letting linux mmap from addresses in the same range that win32 does? - mo PS: the thread on this issue starts at http://www.winehq.com/hypermail/wine-devel/2005/03/0643.html. It also covers the issue of Wine's lack of mlock/munlock functionality.
Re: flexible-mmap breaks application
Mike == Mike Hearn [EMAIL PROTECTED] writes: Mike On Thu, 10 Mar 2005 19:15:34 +0100, Uwe Bonnes wrote: However nothing seems to have happened with regard to that problem until now. Could we revive that discussion? Mike I think somebody needs to write a patch and send it to the kernel Mike guys. What has to be done is fairly well defined (or at least, Mike seems that way to me). The definition of the task is clear: Have a way to tell the kernel to not mmap memory above 0x7fff However the implementation is unclear to me: - Should this be a new syscall? - Or should we set some kernel parameter? Per task or global? Hints (or patches to test) welcome. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: flexible-mmap breaks application
Uwe Bonnes wrote: The definition of the task is clear: Have a way to tell the kernel to not mmap memory above 0x7fff However the implementation is unclear to me: - Should this be a new syscall? - Or should we set some kernel parameter? Per task or global? Hints (or patches to test) welcome. I would go for a new syscall, but it might be worth asking what the preferred implementation is on lkml. I have a feeling they don't like adding syscalls much.
flexible-mmap breaks application
Hallo, from the XILINX Ise suite (version 6.3 tested), the GUI (_pn.exe) and the web update (webupdate.exe) crash with recent CVS when run on a 2.6 Kernel (Suse 9.2, 2.6.11.1-20050307183958-default, but also the default 2.6 distribution kernel and a Athlon/ Pentium M). Both programs run fine with 2.4 (meeding a step back to Suse 9.0, but the same wine executable, only tested on the Athlon). The problem was hard to pinpoint, but I suspected differences in HeapAlloc() return values to cause the problem, hinted by looking at the disassembly where the error happens. Clearly there is a difference between 2.4 and 2.6 kernels: While mmap2() in kernel 2.4 in map_view() returns values in the 0x4000 range, kernel 2.6 returns values like 0xb7fe9000, 0x5871, 0xa07f and 0x77abf000. A check in RtlAllocateHeap() for return values above 0x8000 also triggers with both programs when run on 2.6 and not with 2.4. Looking deeper, I found http://lwn.net/Articles/92281/ about flexible-mmap-update.patch and the wine-devel discussion from around new year about Re: ptrace single-stepping change breaks Wine. Setting /proc/sys/vm/legacy_va_layout, like proposed by Ingo, lets the app finally run. Alexandre finally concluded the discussion by Probably the easiest would be to have a way for an app to specify the mmap range it wants. So instead of having the kernel try to guess from brk and stack ulimit, both of which are meaningless for Win32 apps, we could set the range from end of win32 exe to 0x7ff. This would also avoid the need to preallocate everything above 0x8000 that we currently do and that plays havoc with address space limits. However nothing seems to have happened with regard to that problem until now. Could we revive that discussion? Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: flexible-mmap breaks application
On Thu, 10 Mar 2005, Uwe Bonnes wrote: Setting /proc/sys/vm/legacy_va_layout, like proposed by Ingo, lets the app finally run. To Mark Knecht: If you have a copy of jack_fst without the special memory allocation hack, you might try it and see if this suggestion makes any difference. Maybe this is the same memory allocation issue. - Walter
Re: flexible-mmap breaks application
Walt Ogburn wrote: On Thu, 10 Mar 2005, Uwe Bonnes wrote: Setting /proc/sys/vm/legacy_va_layout, like proposed by Ingo, lets the app finally run. To Mark Knecht: If you have a copy of jack_fst without the special memory allocation hack, you might try it and see if this suggestion makes any difference. Maybe this is the same memory allocation issue. I don't think it is the same problem. Jack_fst had the problem on my RH9, kernel 2.4 system.
Re: flexible-mmap breaks application
On Thu, 10 Mar 2005 19:15:34 +0100, Uwe Bonnes wrote: However nothing seems to have happened with regard to that problem until now. Could we revive that discussion? I think somebody needs to write a patch and send it to the kernel guys. What has to be done is fairly well defined (or at least, seems that way to me). thanks -mike
Re: flexible-mmap breaks application
Mike Hearn wrote: On Thu, 10 Mar 2005 19:15:34 +0100, Uwe Bonnes wrote: However nothing seems to have happened with regard to that problem until now. Could we revive that discussion? I think somebody needs to write a patch and send it to the kernel guys. What has to be done is fairly well defined (or at least, seems that way to me). Actually that is what Uwe did. I supplied a test to him demonstrating the problem, and he found the bug in the kernel, and sent the patch to fix it. By the way, this is related to http://www.winehq.org/hypermail/wine-devel/2003/08/0522.html
Re: flexible-mmap breaks application
Duane Clark wrote: Mike Hearn wrote: On Thu, 10 Mar 2005 19:15:34 +0100, Uwe Bonnes wrote: However nothing seems to have happened with regard to that problem until now. Could we revive that discussion? I think somebody needs to write a patch and send it to the kernel guys. What has to be done is fairly well defined (or at least, seems that way to me). Actually that is what Uwe did. I supplied a test to him demonstrating the problem, and he found the bug in the kernel, and sent the patch to fix it. By the way, this is related to http://www.winehq.org/hypermail/wine-devel/2003/08/0522.html Ugg, sorry. I was responding to the wrong thing. Please ignore this really dumb comment.
