Bug 37393

Created attachment 46927 [details]
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).
"""

Created attachment 46928 [details]
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

Created attachment 46929 [details]
dmesg - good

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)

Created attachment 46930 [details]
XorgLog.txt

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

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;

(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.

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.

(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!

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

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

Created attachment 59339 [details] [review]
properly clear SSC1

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

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.

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

commit e77166b5a653728f312d07e60a80819d1c54fca4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Mar 30 22:14:05 2012 +0200

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