8086:0046 [arrandale] X freezes after plugging in external monitor and selecting System>Preferences>Monitors

Could also be related to bug #596082

Bonne, this bug is probably not related to any bug reports which is not for the Arrandale processor family.

In tests 1a and 1b, can you replace using gnome display manager by running the command `xrandr -q`? (The answer is probably yes, but I would like it confirmed.) Can you run the command `xrandr -q --verbose > ~/xrandr.txt` after connecting the external monitor (which will probably freeze your computer). Then next time you boot the computer, check if there is anything in the file xrandr.txt in your home directory. If there is, upload it here.

There has been some progress upstream with respect to GPU hangs after Lucid was released. We would like to find out if this is one of those bugs or if it is still present in the latest code. In the former case we may test patches and see if it is possible to find one or more that fixes the problem. In the latter case, we will report the problem to the intel developers.

In order to test the newer code, please add the xorg-edgers PPA [1] and the newest 2.6.35-rcX mainline kernel from [2] (see also [3]). Note that since this is very recent code it may contain other bugs. Install the package ppa-purge from xorg-edgers PPA to remove it again with the command `sudo ppa-purge -p xorg-edgers`.

If the computer still freezes with the newest code, please install the openssh-server package which enables ssh login. Add the kernel parameter drm.debug=0x02 [4]. When the computer freezes, ssh in from another computer and run the following commands (copy and paste if you want):
datestr=$(date +%Y%m%d)
mkdir dri_debug-$datestr
cd dri_debug-$datestr
intel_error_decode >intel_error_decode.txt
dmesg > dmesg.txt
cp /var/log/Xorg.0.log .

Then attach the files in dri_debug_2010MMDD (where MM and DD are month and date) to this bug report.

In Maverick we will hopefully start generating bug reports with this information automatically soon. There is some general information about this kind of bugs at [5].

[1]: https://launchpad.net/~xorg-edgers/+archive/ppa
[2]: http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D
[3]: https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[4]: You can bring up the boot menu by holding shift during boot. Select the kernel and press 'e' to edit the kernel command line and Ctrl+X to boot with that command line. Another way is to add it in /etc/default/grub, add it to GRUB_CMDLINE_LINUX_DEFAULT and run `sudo update grub`.
[5]: https://wiki.ubuntu.com/X/Troubleshooting/Freeze

This is the output of xrandr -q --verbose from a repeat of test 2 (where the laptop display is not detected at all, but no freeze occurs).

I repeated test 1 using xrandr -q --verbose > xrandr.txt however no output was recorded in the output file.
The ssh session I had open with the machine froze after running the above command, and no new ssh sessions would connect.

I also repeated test 3 and again no ssh session could be made with the machine. After leaving it for a while an error came up on the screen:
BUG: soft lockup - CPU#0 stuck for 61s! [plymouthd:409]

I have attached the output of xrandr -q --verbose when there is no external monitor plugged in (i.e. only the laptop screen is being used).

I have installed the xorg-edgers ppa and did a full upgrade to pull in all of those packages, and I've installed the v2.6.35-rc1-lucid mainline kernel packages.

uname -a
Linux bonne-laptop 2.6.35-020635rc1-generic #020635rc1 SMP Tue Jun 1 17:27:30 UTC 2010 x86_64 GNU/Linux

Repeating test 1 again which yields the same results (freeze) and again no results in the output file. I made sure the disks were flushed with the magic SysRq key.

I'll try again with the debug option you mentioned.

I did test 1 again with the kernel option drm.debug=0x02 as suggested. The first time the ssh session froze and so I couldn't run the commands, but it worked the second time. I have attached the output files from these commands.

I'm not sure how useful the debug information is. If there are any other tests I can run, please let me know.

Bonne, what exactly do you mean by "it worked the second time"? Do you mean that there was no freeze or that it froze but did not bring the network down? If it froze, the logs show that this is not a GPU hang as I first suspected.

Do you connect to the computer via wireless? The wireless networking is started from X, so if X goes down it may take the wireless connection with it. For debugging X issues it is better to be connected via an ethernet cable.

What you write in commen #6:
BUG: soft lockup - CPU#0 stuck for 61s! [plymouthd:409]
indicates that this may have something to do with plymouth. Could you remove the boot option "splash" (in the same way as you added drm.debug=0x02) and see if that changes the result of any of the tests?

Geir, the first time I attempted to run the commands you mentioned the computer froze and the ssh session froze so I couldn't do it. The second time the computer froze, but the ssh session remained open. I did the same thing both times and I was connected via ethernet both times. I'm not sure what, if anything, was different.

I will try removing the "splash" option as you suggested and try again.

Is there any point trying older kernels, as the problem does not exist using the LiveCD, so presumably we could try to narrow it down by trying either older kernels or older X drivers, right?

I repeated test 3 with boot options changed to remove "quiet" and "splash" and add "drm.debug=0x02". The result was that kernel messages ran across the laptop screen at some low resolution until reaching the error "ureadahead main process (381) failed with status 5" then the screen went blank. The system didn't continue on any further. I didn't see the message about plymouthd.

I repeated test 1 with the same boot options as above. The result was that kernel messages ran across the laptop screen at some low resolution until reaching the error "ureadahead main process (381) failed with status 5", then the screen switched to a higher resolution and a few more kernel messages ran across the screen. Then X started. After I plugged in the screen and ran xrandr -q the screen went blank and the ssh session stopped working shortly after. There wasn't enough time to get any debugging info.

It seems that the splash option makes no difference.

I tested booting up using the 2.6.32-21-generic kernel (which is the same as the version on the LiveCD) but it gives exactly the same results.

What is the best way to narrow down the problem? Should I try reverting packages back to the versions used on the LiveCD?

Bonne, try to be very explicit in your comments. When you say in comment #15 "but it gives exactly the same results" I interpret that as "same results as with the current Ubuntu kernel", not "same result as the LiveCD". I hope that is correct.

There have been cases before where a problem does not occur when using a LiveCD simply because it is slower. This happens when one task does not have the time to complete before another task tries to use the result. I am not sure if this is such a problem. You may try a fresh install from the LiveCD without upgrading to check.

There have been similar problems with some Sony Vaio laptops before, but if I remember correctly those computers froze instantly when an external monitor was connected, even if xorg was not running. Since you need to run `xrandr -q` (which is essentially what starting gnome-display-properties does) to trigger the freeze, this is more xorg related.

Nevertheless, the xrandr call triggers the kernel to talk to the monitor and this is probably what causes the freeze. Since this isn't a GPU hang but some other kernel failure, I will move this bug to the kernel where triagers know better how to extract information form various kernel error conditions.

Geir, yes you are correct I meant "same results as with the current Ubuntu kernel". So far only the LiveCD works properly.

Thanks for your help.

Hi all,

I have experiencing the same problem with my E4310.
I have been able to catch some info in /var/log/Xorg.1.log saying that X has experienced a segfault.
This happened when I runned the gnome-display-properties after having connected an external screen on the vga connector.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x4a3248]
1: /usr/bin/X (0x400000+0x655ad) [0x4655ad]
2: /lib/libpthread.so.0 (0x7f8549d06000+0xf8f0) [0x7f8549d158f0]
3: /usr/bin/X (DamageUnregister+0x53) [0x4d72c3]
4: /usr/lib/xorg/modules/libshadow.so (shadowRemove+0x33) [0x7f85466353c3]
5: /usr/lib/xorg/modules/libshadow.so (0x7f8546634000+0x1884) [0x7f8546635884]
6: /usr/bin/X (0x400000+0xa77d9) [0x4a77d9]
7: /usr/bin/X (0x400000+0x1684fc) [0x5684fc]
8: /usr/bin/X (0x400000+0x2624c) [0x42624c]
9: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f85489fdc4d]
10: /usr/bin/X (0x400000+0x25d59) [0x425d59]
Segmentation fault at address (nil)

Caught signal 11 (Segmentation fault). Server aborting

Hopping this may help to solve the problem.

Same problem on Dell E6410.

Installing the kernel 2.6.35 to solved the problem.

I can confirm that with 2.6.35-maverick (from mainline kernels) and xorg-edgers ppa enabled (not sure if this is required) that this problem is gone.
There are still glitches and blank screens occasionally, but the bug as reported originally is not consistently reproducable anymore.

I can switch between single and dual screen using the xrandr tool, and it works some of the time.

I'll give a more detailed report of the original tests when I get a chance.

I had the same problem. Now I found out that besides nothing is shown on the screen when select the second monitor, it fixes when I press ctrl + alt + F7.

As Carlos Parra Camago wrote, this bug is present on a Dell E6410 with an intel i7 processor and thus an intel Graphics HD video card.
The bug is present with ubuntu 10.04 but not Kubuntu10.04 (64 and 32 bit)
The bug is also present with ubuntu 10.10 RC daily build from 06-Oct-2010 (64 bit) running from liveCD.
Thus, is it related to a gnome issue?
As described here: http://www.cs.bham.ac.uk/~axs/laptop/#monitor-problem
The problem can be partially solved by booting into runlevel 3 and launching X manually (the tests where performed using fedora distro).
In my case, I solved it temporarily by using Kubuntu (10.04 installed on the disk) or Linux Mint Debian Edition (tested from liveCD).

O-p

After a new test...it seems to work "some time" with ubuntu 10.10 RC daily build from 06-Oct-2010 (64 bit) running from liveCD.
In that case there is an other bug with extended desktop where panel refuse to "stay" on the laptop lcd (DP1) and is always on the external screen (VGA1)!
Panels and Nautilus are displayed on VGA1
Applications such as Openoffice are displayed on DP1...

I am going to look for this bug in launchpad....

Cheers.

O-p

Finally Ubuntu 10.10 was released yesterday an installed on my Latitude E6410 (64 bit version).

X completely freeze when an external screen is connected.... again :-/

O-p

Back to the future...
This problem was present on ubuntu 10.04 and could be solved by switching to Kubuntu.
Same thing with ubuntu 10.10... I switched to Kubuntu 10.10 64 bit this morning and it works (no problem at all when connecting external screen).
I really think it is a problem related with gnome... (see post #23)

Cheers.

O-p

Hi all

Trying to solve my problem with ubuntu (gnome version), it seems that it can be done by launching Xrandr early in Xsession.

What I did was to create a file called "45custom_xrandr-settings"

what is in this file:
EXTERNAL_OUTPUT="VGA1"
INTERNAL_OUTPUT="DP1"

xrandr --output $INTERNAL_OUTPUT --auto --primary --output $EXTERNAL_OUTPUT --off

Simply copy it to the folder "/etc/X11/Xsession.d/"

I don't know why but after that you can connect an external screen and activate it using System>preference>Monitors without crash.

I have used the "--primary" argument so that gnome panels stay on the laptop screen in extended mode.

I hope it will help someone.

O-p

I currently have the latest maverick packages installed with xserver-xorg-video-intel 2:2.12.0-1ubuntu5.1 kernel 2.6.35-24-generic and xserver-xorg 1:7.5+6ubuntu3

I redid all of the tests I mentioned in post #1 and a few more. I will outline the results below.

1a. PASS Result is that the display switches to dual-screen and works properly afterwards.
If I then unplug the screen under the following three scenarios:
i. Only LCD was enabled beforehand - LCD continues to work after unplugging VGA screen.
ii. Only VGA screen was enabled beforehand - LCD stays blank. Hitting Fn-F8 reverts the display back to the LCD and continues to work
iii. Dual screen enabled beforehand - Dualscreen mode continues, but is disabled after hitting "detect" in gnome-display-properties. LCD continues to work as normal

2. FAIL Result is that the LCD is never detected if the laptop is booted with the lid closed and the VGA screen plugged in. gnome-display-manager never detects it and it is never enabled even if the VGA screen is unplugged. Pressing ctrl-alt-F1 still doesn't enable anything on the display.

3. PASS Result is that the display boots up in dual-screen mode and works properly afterwards. Can be switched to single screen using gnome-display-properties as expected.

4. I didn't retest 4 since the result should still be the same.

Since I now have a dock I did the following tests to check that it works properly. I have a screen (same screen as above) plugged into the dock via a DVI cable.

5. I tested switching on the laptop whilst plugged into the dock with the lid closed.
FAIL Result is that the DVI monitor works fine after bootup, but the laptop monitor is never detected even after it is opened. gnome-display-properties never finds the laptop monitor when hitting detect. Undocking the laptop still produces nothing on the screen. Fn-F8 does nothing. ctl-alt-F1 does nothing. After redocking the laptop and viewing the ctl-alt-F1 terminal the following message is visible repeatedly on the screen:
drm:i915_do_wait_request *ERROR* Hangcheck timer elapsed... GPU hung

6. I tested switching on the laptop whilst plugged into the dock with the lid open.
PASS Result is that the screens are cloned at the login screen, and switches to the last used setting after logging in. Can successfully use gnome-display-properties to switch between the LCD, DVI screen and dual-screen. Undocking works and switches back to just the LCD, and redocking works too.

7. I tested switching on the laptop outside the dock, then docking the laptop.
PASS Result is that the screens revert to the previous setting and gnome-display-properties can be used to switch between LCD, DVI screen and dual-screen. Undocking reverts back to the LCD as expected.

8. I tested switching on the laptop outside the dock with the lid closed.
PASS Result is that when the lid is opened the screen switches on as expected. Can be docked and connected to VGA screen as above.

So basically the bug as originally reported is gone, but there is a new bug whereby the laptop monitor is never detected if the lid is closed and there is a second monitor plugged in at the time of boot. This is the case for both VGA moni...

I'm using Archlinux and suffer for this same bug. I get to, sort of fixed, after I realize the way that gnome screen settings was working. using gnome 3 and plug-in a second monitor it extend. But when I want to use only the external screen it crash the way it's described here. I try many ways to change but it always crash until I realize the representation of the screens in the gnome-settings dialog. It seems that one screen is overlapping the other (only happen when one is turn off), not at the right of it, is like in the middle. I think it was just a bug but after many times i realize that the crashed graphics was cut in the middle. It seem that the screen signal is splited into the two screens and crashed. To fixed, I just grab the screen i want to use to far away from the other (not next to it) and voila! X don't crash. I don't know this could be useful but for me fixed. I hope I made myself clear.

Well, after I restart my machine could't get fix again. It seems that works randomly...

Bonne Eggleston, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in the development release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. As well, please comment on which kernel version specifically you tested.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream', and comment as to why specifically you were unable to test it.

Please let us know your results. Thanks in advance.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

I have this problem.

wheezy 32-bit
Linux 3.2.0-4-686-pae
GNOME 3.4.2

The only way to solve this problem is removing monitors.xml
rm ~/.config/monitors.xml

But this method will cause bug#599628 happen.
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/599628

hayno, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Kernel team article:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports

the Ubuntu Bug Control team and Ubuntu Bug Squad team article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report may delay your problem being addressed as quickly as possible.

Thank you for your understanding.