Bug#735927: general: X *always* crashes when ram is full
On 2014-01-18 23:56, moli wrote:
> ok, another way to reproduce without chrome or flash or youtube:
>
> reboot to a clean system, dont run anything, only an X and a console
> # mkdir /tmp/foo
> # mount -t tmpfs none /tmp/foo -o size=900m
> # dd if=/dev/zero of=/tmp/foo/bar
> (a message comes with device full)
> (now you cannot give any new command in bash as there is no memory to
> start a new shell for you command: error message: "bash: fork: cannot
> allocate memory")
> now wait a few seconds, move your mouse, etc, boom, the x crashes:
> /var/log/Xorg.0.log.old
> (EE) intel(0): Failed to submit batch buffer, expect rendering
> corruption or even a frozen display: No space left on device.
> note: this time i've set the bios parameters to the *MAXIMUM* values:
> DVMT MODE: FIXED
> IGD DVMT MEMORY: 128MB
> IGD APERTURE SIZE: 256MB
> so there should be plenty of video memory and note that i didnt run
> much program that needs video memory.
I don't think its running out of *video memory*. It's just running out
of normal RAM. What else do you expect after putting the system under
extreme memory pressure (either by sucking it into a tmpfs or by running
google-memory-hog)?
The famous last words from your Xorg.log are from
xserver-xorg-video-intel-2.19.0 src/intel_batchbuffer.c (removed
irrelevant parts):
ret = dri_bo_subdata(intel->batch_bo, 0, intel->batch_used*4,
intel->batch_ptr);
if (ret != 0) {
if (ret == -EIO) {
} else {
xf86DrvMsg(scrn->scrnIndex, X_ERROR,
"Failed to submit batch buffer,
expect rendering corruption "
"or even a frozen display: %s.\n",
strerror(-ret));
}
}
To me this looks like the intel driver cannot do a task because it
cannot allocate memory (this does not neccessarily trigger the kernel's
OOM killer) and shortly afterwards X crashes - maybe the intel driver
corrupted something on the way. The ret value is not returned to the
caller (X), so that does not know about the failure.
Look here for instructions for debugging X crashes:
https://wiki.debian.org/XStrikeForce/XserverDebugging
Good luck that anything here works if the system is out of memory.
> btw i ran the same tests on the same computer but with ubuntu 11.04
> kernel 2.6.38 , no crashes!! Same shared video memory, same intel
> hardware, different kernel (drivers?).
Compare the versions of xserver-xorg-core and xserver-xorg-video-intel
between the Ubuntu version and the Debian version you used.
Could you try the vesa (xserver-xorg-video-vesa) driver instead and see
what happens under extreme memory pressure?
Andreas
PS: and you would be perfectly fine if X wouldn't crash but would be
killed by the oomkiller - with the same situation afterwards ?
Reply to: