Fortunately this freezing problem is reproducible, even if it takes a
little while.
My test setup: an ethernet LAN with my new laptop (x100e), old laptop
(x30), and desktop (zino HD)
On the desktop I monitor the new laptop's health like this, so I can get
notified shortly after it drops off the network:
while date && ssh x.x.x.x cat /proc/acpi/thermal_zone/TZ00/temperature; do
sleep 9; done
And on the old laptop I am copying across files to the new laptop:
(sudo tar --exclude 'lost+found' -cf - /u /v) | ssh r...@x.x.x.x 'tar -C /
-xvf -'
Twice last night I ran this copy and the new laptop froze at more or
less the same time. Now I am repeating these tests observing the
devices, I see the following:
* the x100e is just at its GDM login screen, I am not touching it
* copying is going fine. The temperature on the laptop starts at 49C and goes
up to 57-59C where it stabilises
* the x100e blanks its screen. This is typically 10 minutes after starting the
copy.
* immediately the x100e drops off the network: that is, I see
ssh: connect to host x.x.x.x port 22: Connection timed out
(and it no longer responds to pings from either the old laptop or the desktop)
Strangely, if I move the mouse pointer on the new laptop, it's still
alive. Once I tried pressing Ctrl-Alt-F1 and that froze it. Normally I
can login via gdm, and bring up a terminal window. 'ifconfig eth0' shows
the original IP. But a ping to my default gateway sometimes freezes the
whole machine, or else just hangs and ^C or ^Z won't stop it. On the
most recent failure I did "sudo ifdown -a" which was OK until ^C, then
"sudo stop NetworkManager" and a second or two later the whole machine
froze.
Now some more data:
* it fails in the above way if I have fglrx driver loaded (and also has
radeon.modeset=0 in grub config, although I don't suppose that makes a
difference)
* it DOESN'T crash if I leave the screen on a text console using Ctrl-
Alt-F1 first. This is despite the fact that the text console also
blanks.
* it fails in the above way if I have uninstalled the fglrx driver
(leaving radeon.modeset=0 in grub config)
(Aside: I got "System error: InstallArchives() failed" when using the
Admin > Hardware Drivers tool. I finished removing the fglrx-* packages
using apt-get, and then rebooted. UPDATE: this may be a side-effect of
etckeeper, which I notice giving an error about a corrupt git object
when doing apt-get. I've now removed etckeeper, I didn't realise it
hooked itself in in this way)
* it still fails if I forcibly turn off modeset on the module like this
before starting the test, following instructions from
https://wiki.ubuntu.com/X/KernelModeSetting
Ctrl-Alt-F1, login as root
stop gdm
modprobe -r radeon drm
modprobe radeon modeset=0
start gdm
-- and switch back to graphical display
(although I don't think this will make a difference, given the
radeon.modeset=0 in grub config)
* it DOESN'T crash if I force the vesa display driver in
/etc/X11/xorg.conf as per https://wiki.ubuntu.com/X/KernelModeSetting -
however the screen doesn't blank either. Also, the screen display is
poor as it is stretched out horizontally. /var/log/Xorg.0.log says it's
using 1024x768, and the screen is actually 1366x768.
* choosing fbdev in xorg.conf doesn't work at all: I get an error saying
"Ubuntu is running in low-graphics mode ... (EE) FBDEV(0): EGA/VGA
planes are not yet supported by the fbdev driver"
So what it seems to be is something to do with screen blanking when
using either the radeon or fglrx drivers [although I hadn't confirmed
from Xorg.0.log that actually the fglrx driver was being used in place
of the radeon driver, this is something I still need to do]
This suggests a potential workaround of disabling screen blanking
entirely (say in xorg.conf, although I don't know if gnome settings
override that). I'd still like to get to the bottom of what's happening
to have more confidence in the reliability of my system.
--
Lenovo Thinkpad x100e System freeze during X start-up and while X is running,
but only on battery.
https://bugs.launchpad.net/bugs/535653
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
