Dell Sputnik

Bug #1167624
Comment #109

Comment 109 for bug 1167624

Revision history for this message

Ryan Riegel (rriegs) wrote on 2013-09-23:

#109

I just wanted to add my two cents regarding this problem. In summary, I suspect the problem at hand is caused by the device running out of video memory, which in my case may be caused by using an external monitor. This leads to X crashing with no pathway for recovery. I've reduced the resolution of my external monitor and the crash seems to have been resolved. My observations are as follows:

I started experiencing crashes shortly after obtaining my XPS 13. I do not use nor have I installed Chrome/Chromium or Spotify, which seem to be the leading culprits above, but I do have an external monitor with equal resolution to the built-in screen (1920x1080). Otherwise, I have current updates, both 64-bit and 32-bit versions of both openjdk-6 and 7, and a handful of other tools I use for development such as emacs. I have not installed a more recent kernel (currently 3.2.0-53), nor have I updated the BIOS (though dmidecode reports it as A09).

The context of the first crashes I saw were situations where I ran out of *system* memory. While failure in this circumstance is understandable, the failure was complete: the mouse wouldn't move, I couldn't switch to other ttys, etc. Later, however, I noticed crashes occuring when the system shouldn't have been burdened. I installed indicator-multiload to keep an eye on my system memory and observed a crash (which conveniently froze the system monitor history) that occured at a time of minimal CPU usage, normal memory load, and no noticeable disk activity (at the time, I wasn't monitoring network, swap space, or "system load").

I observed several further similar crashes, some of which occured even when I was AFK, with no activity other than running remote tasks via ssh (and thankfully a remote screen). I mentioned the problem to my resident hardware expert and, after noticing X failures in my system log, his instinct was that I was running out of video memory. I don't have a means of monitoring video memory (any recommendations?), though with two 1920x1080 displays plus compiz (default installation plus compizconfig-settings-manager, with a few tweaks), firefox, and half a dozen terminal/emacs/etc. windows open this seemed at least plausible.

I've since reduced the resolution of my external monitor to 1440x900, and I've seen no further crashes. I would *like* to instead reduce the resolution of my laptop monitor, but it seems I cannot, at least not through Ubuntu system settings. Alternately, I wouldn't mind increasing the amount of system memory allocated to my Intel HD Graphics processor, but I cannot find any way to do so through the BIOS or otherwise. Right now it seems to be using around half a gigabyte (my system reports 640MB less than the 8GB it actually has); I'd be happy to let it use twice as much if it means I can run my external monitor at its full resolution.

I just wanted to add my two cents regarding this problem.  In summary, I suspect the problem at hand is caused by the device running out of video memory, which in my case may be caused by using an external monitor.  This leads to X crashing with no pathway for recovery.  I've reduced the resolution of my external monitor and the crash seems to have been resolved.  My observations are as follows:

I started experiencing crashes shortly after obtaining my XPS 13.  I do not use nor have I installed Chrome/Chromium or Spotify, which seem to be the leading culprits above, but I do have an external monitor with equal resolution to the built-in screen (1920x1080).  Otherwise, I have current updates, both 64-bit and 32-bit versions of both openjdk-6 and 7, and a handful of other tools I use for development such as emacs.  I have not installed a more recent kernel (currently 3.2.0-53), nor have I updated the BIOS (though dmidecode reports it as A09).

The context of the first crashes I saw were situations where I ran out of *system* memory.  While failure in this circumstance is understandable, the failure was complete: the mouse wouldn't move, I couldn't switch to other ttys, etc.  Later, however, I noticed crashes occuring when the system shouldn't have been burdened.  I installed indicator-multiload to keep an eye on my system memory and observed a crash (which conveniently froze the system monitor history) that occured at a time of minimal CPU usage, normal memory load, and no noticeable disk activity (at the time, I wasn't monitoring network, swap space, or "system load").

I observed several further similar crashes, some of which occured even when I was AFK, with no activity other than running remote tasks via ssh (and thankfully a remote screen).  I mentioned the problem to my resident hardware expert and, after noticing X failures in my system log, his instinct was that I was running out of video memory.  I don't have a means of monitoring video memory (any recommendations?), though with two 1920x1080 displays plus compiz (default installation plus compizconfig-settings-manager, with a few tweaks), firefox, and half a dozen terminal/emacs/etc. windows open this seemed at least plausible.

I've since reduced the resolution of my external monitor to 1440x900, and I've seen no further crashes.  I would *like* to instead reduce the resolution of my laptop monitor, but it seems I cannot, at least not through Ubuntu system settings.  Alternately, I wouldn't mind increasing the amount of system memory allocated to my Intel HD Graphics processor, but I cannot find any way to do so through the BIOS or otherwise.  Right now it seems to be using around half a gigabyte (my system reports 640MB less than the 8GB it actually has); I'd be happy to let it use twice as much if it means I can run my external monitor at its full resolution.