[arrandale] VGA port not working on Dell Latitude E6510

[Corona]

Binary package hint: xserver-xorg-video-intel

I cannot hook up an external monitor or beamer to my Dell Latitude E6510 using the VGA port. When I open the "monitors" dialogue, the screen goes black if there is a VGA cable plugged in. Only alt-sysrq-REISUB works to restart the computer.
The chip is an intel one (intel core i5), not nvidia.
I tried the xorg-edgers PPA to see if newer packages fix the problem, but that is not the case.

Using netconsole, these messages are shown on the console when the monitor goes black:
[ 117.623294] dell-wmi: Received unknown WMI event (0x11)
[ 117.686469] dell-wmi: Received unknown WMI event (0x11)

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: xserver-xorg-video-intel 2:2.9.1-3ubuntu5
ProcVersionSignature: Ubuntu 2.6.35-7.11~lucid1-generic 2.6.35-rc4
Uname: Linux 2.6.35-7-generic i686
Architecture: i386
CheckboxSubmission: 9f21fd2185c4c78c7747514ec103f65b
CheckboxSystem: d00f84de8a555815fa1c4660280da308
Date: Tue Jul 20 15:58:38 2010
DkmsStatus: Error: [Errno 2] No such file or directory
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
MachineType: Dell Inc. Latitude E6510
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-7-generic root=UUID=c17d1179-45a9-4a75-99f5-b85563d6f6c8 ro splash quiet quiet splash i915.modeset=1 acpi_sleep=s3_bios
SourcePackage: xserver-xorg-video-intel
dmi.bios.date: 05/28/2010
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A03
dmi.board.name: 02K3Y4
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA03:bd05/28/2010:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn02K3Y4:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.name: Latitude E6510
dmi.product.version: 0001
dmi.sys.vendor: Dell Inc.
glxinfo: Error: [Errno 2] No such file or directory
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.35-7-generic

[Corona (stefaniefauconnier)]

Funny thing is, this does not happen when using the livecd (lucid or maverick), only when booting from the HDD...

[Geir Ove Myhr (gomyhr)]

In addition to bug 596082, there is also bug 599626 which is very similar. In that case I gave up and moved to the linux package, since I couldn't find a way to extract relevant logs. That hasn't been touched for the last two weeks, though, but I'm afraid this may go the same way eventually. Here are a few things you may try:
- The things I asked for in the other two bug reports, in case it actually works for you.
- If you can trigger the bug using `xrandr -q` instead of opening the monitor dialog, could you try if you get any messages on-screen by running `sleep 5; xrandr -q` and switching to VT1 with Ctrl-Alt-F1 before 5 seconds? Maybe some messages will show up on screen then.

[Chris Wilson (ickle)]

On Tue, 20 Jul 2010 15:39:33 -0000, Geir Ove Myhr <email address hidden> wrote:
> In addition to bug 596082, there is also bug 599626 which is very similar. In that case I gave up and moved to the linux package, since I couldn't find a way to extract relevant logs. That hasn't been touched for the last two weeks, though, but I'm afraid this may go the same way eventually.

Geir, it hasn't been touched because we have a surfeit of Arrandale bugs
and lots of patches which may or may not fix the issue -- it is just a
matter of workload currently.

But I do now have an Arrandale laptop (at last!) and lots of bugs to try and
reproduce.

--
Chris Wilson, Intel Open Source Technology Centre

[Geir Ove Myhr (gomyhr)]

Chris, good to see that this is on your radar. I wasn't aware that you were also following Ubuntu bug reports. I was simply hoping that the kernel triagers would know better how to extract some useful information about the black screen (which takes down the ssh connection) before forwarding it upstream to you guys.

[Corona (stefaniefauconnier)]

Thanks for looking into this, guys. This is what I found:

- When I plug in the VGA cable and switch to VT1, the screen goes black, even when I don't run `xrandr -q` first, so that doesn't give any additional info.

- Running `xrandr -q --verbose > ~/xrandr.txt` (with cable plugged in) without switching to VT1: system freezes, bottom part of the screen goes black, on the upper part of the screen I see my scrambled wallpaper and the (frozen) mouse pointer. No image on the external monitor. When I reboot using sysrq-reisub xrandr.txt is empty

- Running udevadm monitor --property > ~/udevadm.log before opening the monitors dialogue: system freezes, screen goes black, file is empty when I reboot.

Let me know if there's anything else I can try.

[Geir Ove Myhr (gomyhr)]

> - When I plug in the VGA cable and switch to VT1, the screen goes black,
> even when I don't run `xrandr -q` first, so that doesn't give any
> additional info.

What if you switch to VT1 and then plug in the monitor? Possibly it
will hang when you switch back to X. If that is the case, what if you
do `sleep 30; xrandr -q` and then switch to VT1 and plug in the
monitor and wait until the sleep times out? It may be a long shot, but
it is possible that the kernel will print some panic messages on VT1.

Otherwise, I saw that Jeremy Foshee just wrote a wiki page with how to
setup Netconsole. You may be able to capture some panic information by
using that.

http://wiki.ubuntu.com/Kernel/Netconsole

[Corona (stefaniefauconnier)]

I tried both suggestions:

1) Plugging in the cable after switching to VT1: the system freezes and the screen goes black, even without switching back to X
2) Plugging in the cable, running `sleep 30; xrandr -q` and then switching to VT1: screen goes black almost immediately, before the 30 seconds are over.

I guess that's not very helpful, either. I'll try the Netconsole thing this weekend when I have access to my second machine.

[Corona (stefaniefauconnier)]

I got netconsole up and running, I'm attaching the log. I think these might be the most interesting lines:

[ 117.623294] dell-wmi: Received unknown WMI event (0x11)
[ 117.686469] dell-wmi: Received unknown WMI event (0x11)

These were the last messages that were printed when my screen went black. When I hit Sysrq-REISUB, these messages appeared:

[ 181.081618] SysRq : Changing Loglevel
[ 181.081635] Loglevel set to 5
[ 182.536278] BUG: soft lockup - CPU#2 stuck for 61s! [Xorg:1230]

Hope this helps.

[Corona (stefaniefauconnier)]

I noticed that there were a couple of lines in the log containing [UFW BLOCK], so here's a second log with ufw disabled. It doesn't seem to make a big difference though.

[Geir Ove Myhr (gomyhr)]

Great troubleshooting, Corona! I don't know enough kernel stuff to know if this means that the dell-wmi is the troublemaker or it simply needs an update to silence an innocent message. Hopefully the kernel people know that better, so I think it's time that I send this over there. I am not sure if this belong to the intel graphics developers or someone involved with wmi drivers.

Maybe Chris Wilson is still watching and knows what this means.

[Corona (stefaniefauconnier)]

Thanks a lot for your efforts!
I tried blacklisting the dell-wmi module but that didn't help, the error messages about the unkown event are no longer present in the logs but I still get a black screen when I try to use an external monitor.

[Geir Ove Myhr (gomyhr)]

Just to confirm: The dell-wmi messages do not show up when the monitor is plugged in, but only when xrandr is run and the monitor goes black?

If you let it stand for a couple of minutes before hitting Sysrq-REISUB, does the BUG: Soft lockup line show up eventually, without you rebooting?

Otherwise, my knowledge is exhausted on this one, and I hope someone with more kernel knowledge can bring this to the attention of the right upstream.

[Corona (stefaniefauconnier)]

I tried everything again to make sure, here's the new log.
When the laptop was fully booted the last line that was printed was "wlan0: no ipv6 routers present" (see the end of the file). When I plugged in the cable, nothing happened. After running `xrandr -q`, the dell-wmi message appeared and the screen went black. I waited a couple of minutes but no additional messages appeared. When I pressed alt-sysrq and released those keys, I got the messages about the soft lockup and the linked modules. After that I hit sysrq-reisub, as you can see in the file.

When I blacklist the dell-wmi module, everything stays the same except that the message about the wmi event is not printed.

[Corona (stefaniefauconnier)]

I don't know if this helps, but in this thread http://ubuntuforums.org/showthread.php?t=1487531 at ubuntuforums.org, somebody mentions that the patches mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=607864 work for solving this specific problem in Fedora. The issue described there seems different though.

[Geir Ove Myhr (gomyhr)]

The eDP issue should be completely decoupled from this. Howerver, following the redhat bug report to the upstream bug report mentions this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=28911, which is likely to be the same issue. There is an experimental patch at comment #4 in that bug report, and I'm sure it will be useful if you could test that. The patch probably applies to the latest 2.6.35-rcX kernel (if not, drm-intel-next). If you're not up to patching and building yourself (following instructions at [1]) you can ask someone at the IRC channel #ubuntu-kernel on freenode [2] to build a test-kernel with that patch.

[1]: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[2]: https://lists.ubuntu.com/archives/kernel-team/2010-June/011358.html

[Corona (stefaniefauconnier)]

OK, I'll try this next weekend when I have more time. The guy who reported this bug https://bugs.freedesktop.org/show_bug.cgi?id=29005#c4 says that the suggested patches (one of them is the same one you're referring to) don't work for him, though. He has a Latitude E6410 with the same chip as my E6510.
Do you happen to know where I can find instructions for applying a patch against drm-intel-next?

[Geir Ove Myhr (gomyhr)]

To get the drm-intel kernel tree instead of Linus' tree, instead of
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
use
git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git
drm-intel-next is the head of that tree (called master in Linus' tree), i.e. what you get when you clone.
If you have Linus' tree already, it is possible to use that as a reference so that you don't have to download so much. Never tried that, but should be --reference option (see "man git-clone").
You can see all git repositories hosted at git.kernel.org at http://git.kernel.org.

The patch is in mailbox format, and therefore the "git am" command can be used (see "man git-am") to apply the patch.

[Jeremy Foshee (jeremyfoshee)]

Hi Corona,

If you could also please 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 . 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. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Corona (stefaniefauconnier)]

I tested the upstream kernel 2.6.35-020635rc6-generic and the issue is still present, so I'm removing the "needs-upstream-testing" tag.

[Carlos Parra Camargo (carlospc)]

JFYI, I'm having the same problem on a Dell E6410.

[Corona (stefaniefauconnier)]

I applied the patches to drm-intel-next but I couldn't get the kernel to build without errors. I followed the instructions on https://wiki.ubuntu.com/KernelTeam/GitKernelBuild but now I'm pretty much stuck. I'll have a look on irc to see if people can help me there.

[Corona (stefaniefauconnier)]

I managed to compile the kernel using the git repository drm-intel-next, but I got a kernel panic when I tried to boot it, so I guess the patch is not working.

[Corona (stefaniefauconnier)]

Carlos

[Corona (stefaniefauconnier)]

According to Carlos Parra Camargo, the drm-intel-next kernel 2.6.35-997 from the mainline PPA solves this issue. This kernel, however, works only under maverick. Under lucid, it gives a blank screen on boot so I have not been able to test this yet. I might upgrade to Maverick this weekend and I'll report back on this.

(sorry for the double post)

[Corona (stefaniefauconnier)]

I finally got it working :-)
The latest drm-intel-next kernel does solve the issue, but some patch caused the regression which gave me the blank screen on boot. I reverted that patch (see https://bugzilla.kernel.org/show_bug.cgi?id=16496) and compiled the kernel myself. Now I can use my external monitor. The screen gets scrambled for a split second when I open the monitors dialogue, but then I get a fully functional dual-head setup. The only problem is that the option "same image in all monitors" is greyed out, but that issue is probably independent from this one.

I don't know which patch solved the issue, but I'm very happy with it.

[henk (henk1234)]

I can confirm that the external monitor works with the new drm-intel-next kernel and the patch from https://bugzilla.kernel.org/show_bug.cgi?id=16496 reverted.