[arrandale] external VGA output doesn't output anything (i686)

[Daniel Manrique]

Binary package hint: xorg

Steps to reproduce:

1- Plug a monitor into the VGA output
2- Press the monitor switching key (fn-F5)

Expected result:
- Display appears on external monitor, either mirrored or as additional desktop space.

Actual result:
- The external monitor is shown in the Monitors panel, and gets correctly identified (I see Acer 19" or Dell 22", tested with two different screens)
- However, the monitor itself reports "no signal", and displays nothing.

I went as far back as Lucid and the problem still persists, so at least it doesn't appear to be a regression.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: xorg 1:7.6+4ubuntu3
ProcVersionSignature: Ubuntu 2.6.38-8.41-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic i686
Architecture: i386
CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,grid,imgpng,gnomecompat,wall,ezoom,workarounds,staticswitcher,resize,fade,unitymtgrabhandles,scale,session,unityshell]
CompositorRunning: compiz
DRM.card0.DP.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.DP.2:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.HDMI.A.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.HDMI.A.2:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.LVDS.1:
 status: connected
 enabled: enabled
 dpms: On
 modes: 1366x768
 edid-base64:
DRM.card0.VGA.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
Date: Fri Apr 8 12:43:18 2011
DistUpgraded: Fresh install
DistroCodename: natty
DistroVariant: ubuntu
GdmLog2:

GraphicsCard:
 Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 12) (prog-if 00 [VGA controller])
   Subsystem: Toshiba America Info Systems Device [1179:0002]
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Beta i386 (20110407.1)
MachineType: TOSHIBA TECRA A11
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-8-generic root=UUID=d3171176-99b3-404b-af92-0531218055e3 ro quiet splash vt.handoff=7
Renderer: Unknown
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/13/2009
dmi.bios.vendor: TOSHIBA
dmi.bios.version: Version 1.40
dmi.board.asset.tag: 0000000000
dmi.board.name: Portable PC
dmi.board.vendor: TOSHIBA
dmi.board.version: Version A0
dmi.chassis.asset.tag: 0000000000
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: Version 1.0
dmi.modalias: dmi:bvnTOSHIBA:bvrVersion1.40:bd12/13/2009:svnTOSHIBA:pnTECRAA11:pvrPTSE0C-00N00N:rvnTOSHIBA:rnPortablePC:rvrVersionA0:cvnTOSHIBA:ct10:cvrVersion1.0:
dmi.product.name: TECRA A11
dmi.product.version: PTSE0C-00N00N
dmi.sys.vendor: TOSHIBA
version.compiz: compiz 1:0.9.4+bzr20110406-0ubuntu1
version.libdrm2: libdrm2 2.4.23-1ubuntu6
version.libgl1-mesa-dri: libgl1-mesa-dri 7.10.1-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.1-0ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6+4ubuntu3
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.0-0ubuntu4
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-4ubuntu6
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu6

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 12)
     Subsystem: Toshiba America Info Systems Device [1179:0001]
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 12) (prog-if 00 [VGA controller])
     Subsystem: Toshiba America Info Systems Device [1179:0002]

[Daniel Manrique (roadmr)]

I tried powering on the system with a screen already plugged in. In this case, the BIOS takes the external screen as primary, the boot sequence is visible there, and when starting X, the laptop's internal display becomes the primary, showing the desktop and panel, BUT in this case, the external screen does work as expected. So the issue apparently happens only when plugging in the external display on-the-fly.

[Victor Tuson Palau (vtuson)]

so if it happens in Lucid , does that mean that the original test was wrong?

[Bryce Harrington (bryce)]

Possibly your hotkey is simply not hooked up.

Does it work properly if you run 'xrandr --auto'?

[Daniel Manrique (roadmr)]

Hi Bryce,

The hotkey itself is functional, as in, if I press it, the integrated display does some flickering thing (like other systems do just before sending the display to external), but external still shows nothing.

xrandr --auto doesn't do anything.

xrandr -q shows this with the external display connected:

Screen 0: minimum 320 x 200, current 2646 x 1024, maximum 8192 x 8192
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1366x768 60.2*+
   1360x768 59.8 60.0
   1024x768 60.0
   800x600 60.3 56.2
   640x480 59.9
VGA1 connected 1280x1024+1366+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024 60.0*+ 76.0 75.0 72.0
   1152x864 75.0
   1024x768 75.1 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3
   640x480 72.8 75.0 66.7 60.0
   720x400 70.1
   640x350 70.1
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)

So it's very weird because the system *is* detecting the display but nothing gets sent to it somehow.

[Bryce Harrington (bryce)]

Ok, thanks for testing that. Sounds like we can rule out a simple hotkey issue. So it must be a modesetting issue of some sort, either within the kernel's modesetting code itself, or in the driver wrapping the functionality that XRANDR uses. Given that it works when booted with the monitor attached, the latter may be more likely. In either case, we need more detailed logs to do further analysis.

1. Please install 'xdiagnose' and check the checkbox for turning on debugging messages. Reboot your system so this takes effect.

2. Boot first with the monitor disconnected. Once it's up, attach the monitor and run these commands:

xrandr --auto --verbose > xrandr_bad.txt
dmesg > dmesg_bad.txt

3. Reboot leaving the monitor attached. Verify it comes up good. Now run these commands again:

xrandr --auto --verbose > xrandr_good.txt
dmesg > dmesg_good.txt

Attach all four files here (separately, not in a zip file or anything), and we'll see if we can spot the difference.

[Daniel Manrique (roadmr)]

Hi, I ran the requested tests and here are the results.

xrandr --auto --verbose didn't output anything in either case, so I'm ommiting those (no point in attaching an empty file).

[Bryce Harrington (bryce)]

Thanks Daniel,

Would you mind checking if the following command enables the blanked monitor after reproducing the problem?

xset dpms force on

I'm wondering if this is just a dpms setting issue. I have an idea on how we could workaround it if it is.

[Daniel Manrique (roadmr)]

Hi Bryce,

the xset trick doesn't seem to work :( here's what I did:

1- Start up the system without the external monitor plugged in.
2- Plug in the monitor, external display shows nothing, but it's visible gnome-display-properties.
3- issue command xset dpms force on.

Nothing happens :( the external display still thinks the VGA cable is not connected, BUT the computer thinks the display is connected. Actually I launched a few terminal windows and they all went to the external display (which isn't showing anything so I thought they were failing to start). If I press the terminal icon in the Unity bar, I get an overview of the windows that were sent to the external display but I still can't see them.

Thanks for suggesting this test!

[Bryce Harrington (bryce)]

Daniel, thanks for your quick feedback.

Ok one more test along these lines. This time we have the video driver itself try to force DPMS on. Please install this PPA and restart X, and then try reproducing the bug:

https://launchpad.net/~bryce/+archive/elderberry

[Daniel Manrique (roadmr)]

Hi Bryce,

I tried the -debug version of xserver-xorg-video-intel:

- Boot the system
- Install the .deb
- restart X (sudo gdm stop; sudo gdm start from the console)

Behavior is still the same :( I tried with the gnome-display-properties applet, xrandr --auto, and the machine's hotkey (which still causes some flickering like things are being set up) but nothing actually comes up on the external display :(

Let me know if you want to see the Xorg.log files, but I didn't see anything interesting in them.

Thanks for the quick test!

[Bryce Harrington (bryce)]

@Daniel, thanks for testing that.

[Bryce Harrington (bryce)]

Alright, one last thing to try before we send this upstream. Here is a pre-built snapshot of Intel's experimental kernel tree:

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next-proposed/

Please install it and see if you can reproduce the problem, collect dmesg, and report back here.

[Daniel Manrique (roadmr)]

Hi Bryce,

I'm attaching the dmesg with the experimental kernel :

Linux ubuntu 2.6.39-994-generic #201104200727 SMP Wed Apr 20 07:52:44 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

I did a full amd64 install, installed this kernel, booted with it, plugged in the external monitor, and pressed the hotkey a few times. Display flickers as usual, but the external display shows nothing, even insisting that "vga cable has no signal".

Thanks!

[Bryce Harrington (bryce)]

Daniel, again please do your testing using xrandr, not with the hotkey. That is a more direct interface to the RANDR functionality, whereas using the hotkey has dependencies/interactions with other non-X stuff that could give false test results.

[Bryce Harrington (bryce)]

Looking at your dmesg anyway, this pops out as interesting:

[ 135.356761] [drm] GMBUS timed out, falling back to bit banging on pin 2 [i915 gmbus vga]

Can you do a fresh boot and look at dmesg before and then after reproducing the problem. Does the printing of this line correlate to the issue occurring? If so, that's a strong clue...

[Daniel Manrique (roadmr)]

Oops, sorry, you're right about the hotkey, I'm repeating the test with xrandr this time.

I'm running the same experimental kernel:

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next-proposed/current/linux-image-2.6.39-994-generic_2.6.39-994.201104200727_amd64.deb

On booting I see the following references to the "GMBUS timed out, falling back to bit banging" message:

[ 14.327182] [drm] GMBUS timed out, falling back to bit banging on pin 3 [i915 gmbus panel]
[ 15.375376] [drm] GMBUS timed out, falling back to bit banging on pin 4 [i915 gmbus dpc]

I then tailed both /var/log/syslog and /var/log/Xorg.0.log, then plugged in the external display (no key presses, no xrandr yet). Here's what happens right when I plug it in (you're right, the GMBUS message appears right when I plug the external display):

==> /var/log/syslog <==
Apr 27 15:14:49 201002-5345 kernel: [ 530.567145] [drm] GMBUS timed out, falling back to bit banging on pin 2 [i915 gmbus vga]

==> /var/log/Xorg.0.log <==
[ 531.748] (II) intel(0): Allocated new frame buffer 3072x1050 stride 12288, tiled

I produced a dmesg file with this experimental kernel and the xdiagnose settings as described on #6. I do see some events when plugging in the external display and also when running xrandr --auto:

- Plugged in the external at [ 96.419325]
- xrandr --auto at [ 198.077408]

I'm attaching this new dmesg file as it might provide some information. Still, the problem persists and the external display shows nothing, even though it's being detected and used (terminal windows still appear in the external monitor, for instance, and I have to move them to the built-in to be able to use them).

[Bryce Harrington (bryce)]

[I've marked this bug for inclusion in our oneiric bug queue. While technically this bug has not been re-confirmed against oneiric, I feel it is worth continued development attention. We will need to ask that it be re-confirmed once oneiric is further along, perhaps once we get closer to alpha.]

[Lukas (lukas-schloegl)]

Same issue.

To me, it appears to be a regression: I had not problems in Maverick.

Can't confirm that external screen is detected when powering on the system with the screen already plugged in.

[Lukas (lukas-schloegl)]

I am now getting the error message "could not set the configuration for crtc 351", trying to switch monitors via VGA and Fn+F5.
Switching works manually via "Nvidia X Server Settings".
Command "xrandr --auto" in terminal prompts: "Failed to get size of gamma for output default "

[Joachim R. (jro)]

I experiences a different bug that may be linked to this one : when I plug my TV on external VGA display, gnome monitors settings shows only 640x480, 800x600, 1024x768 as possible dimensions for my TV.
It is a regression, because under Maverick, I can set 1366x768 and other 16/9 dimensions. A workaround is using xrandr commands to force a new mode.

Does this interrest you ?

[Bryce Harrington (bryce)]

Forwarding this bug from Ubuntu reporter Daniel Manrique:
http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/754799

[Problem]
xrandr cannot enable the external monitor. According to the log files it should be there, and the screen size is expanded as if it were there, but nothing displays on the monitor. At the point that the external monitor is hotplugged, dmesg shows this error:

[ 135.356761] [drm] GMBUS timed out, falling back to bit banging on pin 2 [i915 gmbus vga]

and this shows up in Xorg.0.log:

[ 531.748] (II) intel(0): Allocated new frame buffer 3072x1050 stride 12288, tile

Problem has been tested with the 11.04 kernel as well as 2.6.39-994.201104200727 and shows same behavior in both cases.

[Original Description]
Steps to reproduce:

1- Plug a monitor into the VGA output
2- Press the monitor switching key (fn-F5)

Expected result:
- Display appears on external monitor, either mirrored or as additional desktop space.

Actual result:
- The external monitor is shown in the Monitors panel, and gets correctly identified (I see Acer 19" or Dell 22", tested with two different screens)
- However, the monitor itself reports "no signal", and displays nothing.

I went as far back as Lucid and the problem still persists, so at least it doesn't appear to be a regression.

Oops, sorry, you're right about the hotkey, I'm repeating the test with xrandr this time.

I'm running the same experimental kernel:

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next-proposed/current/linux-image-2.6.39-994-generic_2.6.39-994.201104200727_amd64.deb

On booting I see the following references to the "GMBUS timed out, falling back to bit banging" message:

[ 14.327182] [drm] GMBUS timed out, falling back to bit banging on pin 3 [i915 gmbus panel]
[ 15.375376] [drm] GMBUS timed out, falling back to bit banging on pin 4 [i915 gmbus dpc]

I then tailed both /var/log/syslog and /var/log/Xorg.0.log, then plugged in the external display (no key presses, no xrandr yet). Here's what happens right when I plug it in (you're right, the GMBUS message appears right when I plug the external display):

==> /var/log/syslog <==
Apr 27 15:14:49 201002-5345 kernel: [ 530.567145] [drm] GMBUS timed out, falling back to bit banging on pin 2 [i915 gmbus vga]

==> /var/log/Xorg.0.log <==
[ 531.748] (II) intel(0): Allocated new frame buffer 3072x1050 stride 12288, tiled

I produced a dmesg file with this experimental kernel and the xdiagnose settings as described on #6. I do see some events when plugging in the external display and also when running xrandr --auto:

- Plugged in the external at [ 96.419325]
- xrandr --auto at [ 198.077408]

I'm attaching this new dmesg file as it might provide some information. Still, the problem persists and the external display shows nothing, even though it's being detected and used (terminal windows still appear in the external monitor, for instance, and I have to move them to the built-in to be able to use them).

DistroRelease: Ubuntu 11.04
Package: xorg 1:7.6+4ubuntu3
ProcVersionSignature: Ubuntu 2.6.38-8.41-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic i686
Architecture: i386
CompizPlugins: [core,bailer,detec...

[Bryce Harrington (bryce)]

Created attachment 46927
dmesg-5345

This is a dmesg against the drm-intel-next kernel with debugging turned on.

"""
I produced a dmesg file with this experimental kernel and the xdiagnose settings as described on #6. I do see some events when plugging in the external display and also when running xrandr --auto:

- Plugged in the external at [ 96.419325]
- xrandr --auto at [ 198.077408]

I'm attaching this new dmesg file as it might provide some information. Still, the problem persists and the external display shows nothing, even though it's being detected and used (terminal windows still appear in the external monitor, for instance, and I have to move them to the built-in to be able to use them).
"""

[Bryce Harrington (bryce)]

Created attachment 46928
dmesg - bad

These two good/bad dmesgs were produced by the following test procedure:

1. Please install 'xdiagnose' and check the checkbox for turning on debugging messages. Reboot your system so this takes effect.

2. Boot first with the monitor disconnected. Once it's up, attach the monitor and run this command:

dmesg > dmesg_bad.txt

3. Reboot leaving the monitor attached. Verify it comes up good. Now run the command again:

dmesg > dmesg_good.txt

[Bryce Harrington (bryce)]

Created attachment 46929
dmesg - good

[Bryce Harrington (bryce)]

xrandr --auto doesn't do anything.

xrandr -q shows this with the external display connected:

Screen 0: minimum 320 x 200, current 2646 x 1024, maximum 8192 x 8192
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1366x768 60.2*+
   1360x768 59.8 60.0
   1024x768 60.0
   800x600 60.3 56.2
   640x480 59.9
VGA1 connected 1280x1024+1366+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024 60.0*+ 76.0 75.0 72.0
   1152x864 75.0
   1024x768 75.1 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3
   640x480 72.8 75.0 66.7 60.0
   720x400 70.1
   640x350 70.1
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)

[Bryce Harrington (bryce)]

Created attachment 46930
XorgLog.txt

[Bryce Harrington (bryce)]

Hi Daniel Manrique, sorry it's taken me a bit to get back to this (UDS, etc.) - Anyway, I've forwarded this bug upstream to http://bugs.freedesktop.org/show_bug.cgi?id=37393 - please subscribe yourself to this bug, in case they need further information or wish you to test something. Thanks ahead of time!

@Lukas, you're not even using the Intel video driver... no chance you have the same bug.
@Joachim, you didn't reveal what video driver you're using but the symptoms you describe are completely different from this bug report.

[Daniel Manrique (roadmr)]

Thanks Bryce, I'm subscribed to the freedesktop.org bug and will be alert for any requests they make.

Thanks for your help!

[Luke-hutchison (luke-hutchison)]

I have had exactly the same symptoms on my Toshiba Satellite Pro S300M with Intel GM45 video, and the problem has existed from at least Fedora 12 to 15 inclusive, so since I'm not on Ubuntu it's definitely an upstream bug.

If I boot with the external monitor plugged in, boot messages are shown on both screens, and dual-monitor support in X works fine. If I don't boot with the external monitor plugged in, but latter plug in a VGA monitor, xrandr detects the monitor fine and says it's connected, but the monitor continues to cycle between blank and an error message screen saying that it has no signal. Manually switching the xrandr setting for the monitor from "--off" to "--auto" does nothing.

As an aside: this bug report describes problems with external monitor support if the external monitor is *not* plugged in during boot. I also reported the following somewhat-related bugs to the Fedora Bugzilla re. problems with suspend/resume and backlight support being flaky if the machine *is* booted with the monitor plugged in:
https://bugzilla.redhat.com/show_bug.cgi?id=692759
https://bugzilla.redhat.com/show_bug.cgi?id=692761

[Daniel Manrique (roadmr)]

Hi Bryce,

We've had a development regarding this bug.

I applied a BIOS update for this Toshiba machine, in connection with bug 719620 which was also affecting this system.

The versions the machine shipped with were:
System BIOS Version: 1.40 (dated 12/13/09)
EC Version: 1.30

I downloaded an update that was published on May 25th, 2011. This bumps the BIOS to the following versions, as can be verified in the setup screen accessible by hitting F2:

System BIOS Version: 3.10
EC Version: 1.90

With this new BIOS, connecting an external screen when the system is up and running works fine and just as expected: the new screen is detected and immediately starts displaying (starts up as additional desktop space to the right of the primary display). Things go back to normal on the primary display when I disconnect the external screen.

This update also made bug 719620 go away, so it looks like the machine, as shipped to us, had quite a buggy BIOS to begin with.

So far I've only tried this with Natty (kernel 2.6.38-8), I'll update in a bit with results from Maverick (2.6.35).

Please let me know if you'd like me to perform other tests to validate this. I won't touch the bug's status as I'm not sure how to proceed when a bug gets "fixed" by a BIOS update.

Also, please let me know if I should update on the upstream bug as well.

[Daniel Manrique (roadmr)]

Removing blocks-hwcert as per new behavior with the updated BIOS.

[Ara Pulido (ara)]

Removing the blocks-cert tag, based on Daniel's comment

[Chris Wilson (ickle)]

The GMBUS warnings are immaterial, the GPIO fallback is working just fine. Interesting that GMBUS should timeout when unplugged though.

More useful would be an intel_reg_dumper with the monitor plugged in on boot (working), and with the monitor plugged in later (blank).

We also need to rule out whether this is just the mishandling of DPMS information between the kernel and X. Normally that can be resolved by e.g. xrandr --output VGA1 --off; xrandr --output VGA1 --mode 800x600; xrandr --output VGA1 --auto;

[Daniel Manrique (roadmr)]

(In reply to comment #7)
> The GMBUS warnings are immaterial, the GPIO fallback is working just fine.
> Interesting that GMBUS should timeout when unplugged though.
>
> More useful would be an intel_reg_dumper with the monitor plugged in on boot
> (working), and with the monitor plugged in later (blank).
>
> We also need to rule out whether this is just the mishandling of DPMS
> information between the kernel and X. Normally that can be resolved by e.g.
> xrandr --output VGA1 --off; xrandr --output VGA1 --mode 800x600; xrandr
> --output VGA1 --auto;

Hi Chris,

I'm the original reporter of this problem and I have access to the hardware in question (Toshiba Tecra A11).

While looking at another, backlight-related problem (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/719620) it was suggested that it might be a BIOS bug. So I updated this machine's BIOS to the latest available from the manufacturer (Toshiba). The new BIOS made the backlight problem go away, and interestingly, it also took care of this problem; so now, with the updated BIOS, I can plug in an external monitor at any moment and everything works just fine.

The versions the machine shipped with were:
System BIOS Version: 1.40 (dated 12/13/09)
EC Version: 1.30

I downloaded an update that was published on May 25th, 2011. New versions are:

System BIOS Version: 3.10
EC Version: 1.90

Please let me know if you're still interested in more information about this machine, or how best to handle this report now.

[Bryce Harrington (bryce)]

At least from the X side I think we could consider a bios fix to be a true fix. Since this system uses KMS, if we were to work around the buggy bios it'd need done in the kernel. So I'll leave the kernel tasks open in case a workaround makes sense, and close out the X tasks.

[Chris Wilson (ickle)]

Daniel, if you do get a chance can you grab an intel_reg_dumper with the old and new BIOSes.

At this point we want to find out what state the BIOS left the registers in that caused us to fail.

[Daniel Manrique (roadmr)]

(In reply to comment #9)
> Daniel, if you do get a chance can you grab an intel_reg_dumper with the old
> and new BIOSes.
>
> At this point we want to find out what state the BIOS left the registers in
> that caused us to fail.

Thanks Chris, I'll attach two text files, one showing the registers after the system has booted, and another one with the registers post-suspend. I diffed the files and here's what changed (- is pre-suspend, + is post-suspend):

- PCH_DREF_CONTROL: 0x00001402 (cpu source disable, ssc_source enable, nonspread_source enable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable)
+ PCH_DREF_CONTROL: 0x00001400 (cpu source disable, ssc_source enable, nonspread_source enable, superspread_source disable, ssc4_mode downspread, ssc1 disable, ssc4 disable)

- HDMIB: 0x0000089c
+ HDMIB: 0x0000001c

I'll try to downgrade the bios to reproduce the original problem and collect the same information with that, though I'm not sure that I'll be able to do so :( If so, I'll report back here.

Thanks so much for following up on this report!

[Daniel Manrique (roadmr)]

Created attachment 49343
intel_reg_dumper output with NEW bios, prior to suspending.

[Daniel Manrique (roadmr)]

Created attachment 49344
intel_reg_dumper output with NEW bios, after suspending and resuming.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel currently in the release pocket than the one you tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help.

[Daniel-ffwll (daniel-ffwll)]

Created attachment 59339
properly clear SSC1

... a patch for you to try. Please test, maybe we're lucky.

[Daniel-ffwll (daniel-ffwll)]

Ping.

If you can't test this any longer because the bios downgrade is a royal pain - no problem, we'll just close this one as fixed.

[Daniel-ffwll (daniel-ffwll)]

So then let's just close this as fixed, proper patch is merged:

commit e77166b5a653728f312d07e60a80819d1c54fca4
Author: Daniel Vetter <email address hidden>
Date: Fri Mar 30 22:14:05 2012 +0200

    drm/i915: properly clear SSC1 bit in the pch refclock init code

[Daniel Manrique (roadmr)]

I'm setting this to Invalid for Ubuntu, since it was fixed by the bios update.