Lenovo Thinkpad x100e System freeze during X start-up and while X is running, but only on battery.

Just tried a new scenario:
- Boot up in text mode without AC power
- Login in text mode
- Connect AC power
- start gdm

Result: no crash. I'd guess that means that no other program that might be run automatically by Ubuntu when the AC power is disconnected can be responsible for the crash. Consequently, the error has to be with the X server ...

Just got my X100e in the mail. Installed alpha3 from CD, this happens to me. Did full package upgrade as of 2010-03-12, it still happens. As long as AC power is plugged in and the laptop is actively used, it's fine. Removing AC power causes a hard lock. Not touching the machine for several minutes causes a hard lock (I didn't time it, but probably whatever the default screen power save timeout is). The only solution is a cold reset.

Hi Robert,
avivotool can be used to assist in debugging this issue. avivotool is provided with the radeontool package, so to install it run:

    sudo apt-get install radeontool

After installing it, you run it like this:

    avivotool regs all > regdump_good.txt
    avivotool regs all > regdump_broke.txt

Run it two times. Once when you have a working screen (for any driver), and once in the broken case (either from the tty console or logged into the sick box remotely). Attach both of those to this bug report, and we can then forward this issue upstream. Thanks ahead of time!

Ran latest updates as of now. Tried using the avivotool and it segfaults:

alex@axu:~$ sudo aptitude search radeontool
i radeontool - utility to control ATI Radeon backlight fu
alex@axu:~$ avivotool regs all > regdump_good.txt
mapping ctrl region
Segmentation fault (core dumped)
alex@axu:~$ cat regdump_good.txt
alex@axu:~$

Ran it as root (with sudo) and that worked.

Can't really get the regdump_broke.txt because the machine hard-locks. Not just X, but the whole machine (I logged in via SSH). Suggestions?

Right sorry yes now with KMS this has to be done as root.

On Thu, Apr 01, 2010 at 01:48:43AM -0000, Alex Chekholko wrote:
> Ran latest updates as of now. Tried using the avivotool and it
> segfaults:
>
> alex@axu:~$ sudo aptitude search radeontool
> i radeontool - utility to control ATI Radeon backlight fu
> alex@axu:~$ avivotool regs all > regdump_good.txt
> mapping ctrl region
> Segmentation fault (core dumped)
> alex@axu:~$ cat regdump_good.txt
> alex@axu:~$
>
> Ran it as root (with sudo) and that worked.
>
> ** Attachment added: "regdump_good.txt"
> http://launchpadlibrarian.net/42740003/regdump_good.txt
>
> --
> 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-X,
> which is subscribed to xserver-xorg-video-ati in ubuntu.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ubuntu-x-swat
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~ubuntu-x-swat
> More help : https://help.launchpad.net/ListHelp

On Thu, Apr 01, 2010 at 01:53:52AM -0000, Alex Chekholko wrote:
> Can't really get the regdump_broke.txt because the machine hard-locks.
> Not just X, but the whole machine (I logged in via SSH). Suggestions?

Hmm, that is starting to sound less like an X bug and more like a kernel
bug. Check your kernel log files for a kernel OOPS, BUG, or other sort
of lockup. You may need to tail -f those while ssh'd in to catch them
before the system locks.

Thing is, it only hard-locks if X is running, as Robert indicates above. Nothing in the logs.

Can start the machine is text mode on battery, but as soon as you start gdm, it hard-locks silently.

Suggestions?

Alright I'm going to go ahead and guess that something is busted with your power management stuff, which causes a kernel lockup of some sort. The reason it doesn't lock until X starts may have more to do with some client app kicking in after being triggered by the desktop startup processes.

Anyway, so no real evidence so far that it's actually X.org faulting here. If you can't get into the system via ssh or anything then it really must be a kernel bug of some sort.

In my dmesg output, there is a line like "thinkpad_acpi: Not yet supported ThinkPad detected!"

I found this one-line patch: http://<email address hidden>/msg02222.html

I rebuilt the thinkpad_acpi kernel module with that patch and loaded it and it gives me:

[ 285.118037] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[ 285.118046] thinkpad_acpi: http://ibm-acpi.sf.net/
[ 285.118052] thinkpad_acpi: ThinkPad BIOS 6XET31WW (1.10a), EC 6XHT30WW-1.170000
[ 285.118059] thinkpad_acpi: Lenovo ThinkPad X100e, model 350828U
[ 285.118460] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode
[ 285.143867] thinkpad_acpi: asked for hotkey mask 0x040988fc, but firmware forced it to 0x000988fc
[ 285.156673] Registered led device: tpacpi::thinklight
[ 285.159100] Registered led device: tpacpi::power
[ 285.162067] Registered led device: tpacpi::standby
[ 285.164386] Registered led device: tpacpi::thinkvantage
[ 285.202047] thinkpad_acpi: Console audio control enabled, mode: monitor (read only)
[ 285.245139] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input10

However, that does not fix the problem.

upgrading to the latest X100e BIOS also does not fix the problem.

using 'acpi=off' _does_ solve the problem for me, but introduces some others (e.g. boot takes _much_ longer)

I have the same problem and exhibit the same exact issue. How can we fix it. This is a big deal.

 Has anyone tired the fglrx driver (ati proprietary driver) ? Do you see the same behavior.

It is sounding though there may be some bios issues here. But first need this info.

Even with fglrx, the system hangs. I suspect it does that because of BIOS. And possible lack of acpi. Support. Can somebody point me at the patches from the thinkpad acpi. Project and I can try them on lucid image.

With the latest X100e BIOS and the latest 10.04 packages and the fglrx driver (installed via System -> Administration -> Hardware Drivers), I'm no longer experiencing this issue. I can unplug the AC adapter, I can adjust brightness, I can change cpu frequency.

To confirm, I have also upgraded to latest bios (v1.20a-1.16), beta 2 cd and fglrx drivers. I have no freezes when switching to battery either. This works for both the i686 and AMD64 installs.

My Lenovo x100e seems to lock up on live cd-boot (ubuntu rc +kubuntu rc).
It does not matter if it has battery, direct power or both.
I find it difficult to try anything with fglrx. (The Kubuntu 9.10 CD (final) boots without problems.)

it's bug kms not only Lenovo

https://bugzilla.kernel.org/show_bug.cgi?id=15166

x100e, latest BIOS by Lenovo, 10.04 final release, flgrx. Same issue here.

Can somebody confirm its the KMS issue reported by Alex?

Same problem on my x100e with 10.04 final. I didn't upgrade BIOS nor I tried fglrx though.

And, yes, I provoked the freeze by just changing brightness so it seems it's brightness related like in that kernel bug.

I've been having the same problem here with my x100e. My machine shipped with BIOS 1.21 and EC version 1.17. I have the final release of 10.04 installed (had to install Ubuntu, then KDE separately because Kubuntu hung on Services startup). However, this morning, I ran the update and upgrade, then made sure my fglrx drivers were the latest and greatest, and I can unplug my machine, adjust my brightness, and I am no longer tethered to the AC power. My kernel name is 2.6.32-21-generic and the version is #32-Ubuntu SMP dated Fri. Apr. 16 08:09:38 UTC 2010 if that helps.

Unfortunately the brightness is not only the issue. I can also set brigtness but the system sometimes freezes... :-(

Lukas, I went into system settings > Advanced >Power Management > Edit Profiles and chose the Performance profile (since my ac adapter is usually plugged in). I unchecked the "Suspend after" and "Power off after" selections under the Screen tab for my profile. I think the problem comes when the system attempts to Suspend. So far, even though my screen has gone black when I've left the system alone, I haven't had that hard freeze (knocks on wood).

I have installed Lucid amd64 on a new Thinkpad X100e (model NTS5EUK, dual core Neo L625, BIOS 1.21, 2GB, WLAN and Gobi WWAN). I enabled AMD virtualisation extensions in the BIOS, just because I could :-)

I initially found it crashed on pressing the brightness up/down function keys. As this was during a large apt-get update I reinstalled again from scratch, this time set radeon.modeset=0 in grub config *and* installed the proprietary video driver for good measure, and updated and rebooted.

Now the brightness and volume function keys work, but the machine locks up spontaneously a few minutes after power-up, even if I just leave it on the gdm screen and ssh to it from elsewhere. Mouse cursor won't move, device won't respond to pings over ethernet, needs a hard power-cycle.

I know the modeset flag is working because I get a low-res "Ubuntu o o o o o" instead of a high-res one at startup.

The options I can think of for isolating this are:
* try removing fglrx, rely instead on normal driver and radeon.modeset=0
* try disabling screensaver/auto sleep/power saving
* try without battery (maybe some charging event?)
* try disabling desktop effects
* try compiling new realtek driver
* try disabling virtualisation support in BIOS
* try i386 instead of amd64
* try the memory test, although the laptop appears to work fine with the supplied Windows 7 (32-bit Pro)

Until this is resolved, I have a very unfit-for-purpose laptop. Am wondering now if I should have bought a Macbook instead :-(

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 root@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 sc...

Just to be sure, after getting rid of etckeeper I reinstalled fglrx but removed radeon.modeset=0 and re-ran the test, and it froze again. Then I removed fglrx and added radeon.modeset=0 and re-ran the test, and it froze once more (i.e. dropped off network). Again, moving the cursor made the screen come alive again, but a Ctrl-Alt-F1 locked it up hard.

Attached is Xorg.0.log from this last test (when fglrx was *not* installed)

New experiment: created /etc/X11/xorg.conf with the following:

Sections "ServerFlags"
Option "BlankTime" "1"
Option "StandbyTime" "2"
Option "SuspendTime" "3"
Option "OffTime" "4"
EndSection

with my copy test: after one minute the screen blanked and the network seemed OK, but within 20 seconds it had frozen, and a ctrl-alt-F1 completely locked up the laptop. So at least I can reproduce it much more quickly now :-)

Then I set BlankTime to 0 but left the other settings as they were. Strangely, nothing went wrong after 2, 3 or 4 minutes, but after exactly 30 minutes the machine dropped of the network. Again, moving the pointer brought the gdm screen back. [This time after entering my password it just stayed at the gdm screen - with greyed-out password shown - and wouldn't go further. I've seen that before though]

I'm not sure where the switchoff after 30 minutes came from - gnome perhaps?

Power management settings dialog says to blank screen after 30 minutes when on AC power, so I think that's where the 30 minutes comes from.

I have opened a new bug 591699 with more details and the exact steps to reproduce (this time using i386 instead of amd64, with same results).

The bug I'm observing is definitely connected to X screen idle blanking, and possibly ethernet I/O at same time.

Let's move all activity on this problem to the new bug. Thanks Brian for all your work in narrowing this down!