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 ? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52dc31dd.7020...@debian.org