I've been testing using ulimit -v 4194304 (and various values below it) but it doesn't fix the crashing issue even when combined with mem=3G.If the value is too low, the game will not start at all, or it will crash while loading a save.If it's too high it will crash in the place it normally does without using ulimit -v.It guess it's possible that there is a sweet spot in between these two where it doesn't crash early on but also doesn't use too much virtual memory but I doubt it.Values between 4160000 and 4170000 were about where the two converged, if you want to try yourself.
The only workaround that has worked at all for me is the low memory hack posted here:
http://bugs.winehq.org/attachment.cgi?id=16555
There is a mmap patch that is supposed to fix this issue properly:
http://bugs.winehq.org/attachment.cgi?id=17547
But it causes massive slowdowns when the kernel sees more than 3.16GB of memory and the game(s) still crash when the kernel sees 3.16GB or less of memory.
See these bugs for more discussion of these issue(s):
http://bugs.winehq.org/show_bug.cgi?id=10778
http://bugs.winehq.org/show_bug.cgi?id=13335
http://bugs.winehq.org/show_bug.cgi?id=14657
Last Wine 1.1.10/11 = pulse sound stuttering
The slow down from the second patch is caused by massive visualization.
First patch is altering wine internal reporting to applications. Apparently that is not dynamic as I would have suspected. Oversized when you don't have the ram for it is not good either. Explains why we are forced high with memory sizes to run wine.
Ok how effective has the low memory patch. Did it stable all three. If so we need to take a closer look at those values. Maybe even a windows test case to find out what windows reports. Sorry to say I don't have windows any more.
Without windows test case it cannot be applied to wine. That is the problem with those 2 patches I am not sure really how well both are working.
First patch is altering wine internal reporting to applications. Apparently that is not dynamic as I would have suspected. Oversized when you don't have the ram for it is not good either. Explains why we are forced high with memory sizes to run wine.
Ok how effective has the low memory patch. Did it stable all three. If so we need to take a closer look at those values. Maybe even a windows test case to find out what windows reports. Sorry to say I don't have windows any more.
Without windows test case it cannot be applied to wine. That is the problem with those 2 patches I am not sure really how well both are working.
option.mem=2G line should match up to the cgroup 2G limitation. While allowing all programs out side the cgroup to use all the ram your system has installed.
mmap patch is trying to control pointer allocation. Yes really nasty visualization method. If we really have to go that far we need to start looking at merging with KVM. They use cpu support to create an completely independent memory zone. Most likely less cost.
Yes I hope we can find some other cause.
mmap patch is trying to control pointer allocation. Yes really nasty visualization method. If we really have to go that far we need to start looking at merging with KVM. They use cpu support to create an completely independent memory zone. Most likely less cost.
Yes I hope we can find some other cause.
It works pretty well.Oblivion only crashes occasionally now (with high settings), Bioshock crashes a lot less but still crashes at the start of the second level unless you set everything to low.Fallout 3 crashes are reduced but still occur sometimes.oiaohm wrote:Ok how effective has the low memory patch. Did it stable all three. If so we need to take a closer look at those values. Maybe even a windows test case to find out what windows reports. Sorry to say I don't have windows any more.
One issue of testing is that when running into this bug, the error messages are not always consistent and could be caused by the bug or a bug in the game itself.
