Bug 35634

Boot into what? VT console, X + gnome/metacity, X + gnome/compiz/mutter, X + kwin? What do you mean by "Don't switch to it"? Does fbcon not attach itself to the external display? When do you unplug the monitor, during kernel booting, userspace initialisation or after X starting?

(Presuming the external monitor is VGA since PineView is involved.)

Can you please attach a drm.debug=0xe dmesg and Xorg.log for the boot process?

This is booting into X + gnome/compiz without a console.   No automatic switching to VGA (in both cases) is done.  The monitor is unplugged after user space initialization and X is running.   I will grab the logs now.

Created attachment 44797 [details]
Dmesg output with drm.debug=0xe and a marker indicating where the unplug occurred

Created attachment 44798 [details]
X log

Created attachment 44799 [details]
intel_reg_dump before unplugging

Created attachment 44800 [details]
intel_reg_dump after unplugging

Ok, the kernel looks to have sanely handed the hotplug event and torn down the crtc attached to the VGA connector. So the question is why didn't userspace handle it? Similarly X seems to have changed modes correctly. The only thing missing in this chain of events is the desktop.

Anything in ~/.xsession-errors?

Still checking on the ~/.xsession-errors content (file did not exist I need to track down if there is some option needed to turn this on).


Debugging that has been done so far has found the following:

Values of DSPASTRIDE(0x70188) and DSPABASE(0x70184) after boot with external monitor connected.

sh-4.0# ./iotools mmio_read32 0x561f0188
0x00001000
sh-4.0# ./iotools mmio_read32 0x561f0184
0x00800000

Unplug external monitor cable. After a second you only see mouse on a blank screen with backlight on. 

Values of DSPASTRIDE(0x70188) and DSPABASE(0x70184): 

sh-4.0# ./iotools mmio_read32 0x561f0188
0x00001680
sh-4.0# ./iotools mmio_read32 0x561f0184
0x00030000

Setting these registers back to their initial values restores screen output.

sh-4.0# ./iotools mmio_write32 0x561f0188 0x00001000
sh-4.0# ./iotools mmio_write32 0x561f0184 0x00800000

Any thoughts about the register results?

Sure. They just indicate that userspace changed the mode configuration and we have not yet replaced the old fb in the GTT with anything else.

Hi Chris,

We are seeing one more issue (see description below) and we think the root cause is same as this bug:

Issue#2-

Boot to Quickweb- Put system to sleep and resume --> 2 out of 8 attempts the system shows Black screen with backlight.

Workaround- Do another sleep/resume cycle and system will resume up fine next time.

(In reply to comment #11) 
> Boot to Quickweb- Put system to sleep and resume --> 2 out of 8 attempts the
> system shows Black screen with backlight.
> 
> Workaround- Do another sleep/resume cycle and system will resume up fine next
> time.

What's the exact state of the output after the resume? Only if it shows the symptom of only showing a cursor I'd classify it as the same bug. Otherwise, we have another fickle s&r bug.

Once in the black screen of boredom, can you switch VT (or ssh in) and start an xterm? etc.

We've worked around this with a couple of different changes (one having to do with the hotplug interrupt handling) and a change to do an xset dpms force off in the resume path.

I am pulling together a more coherent list of what we did so you can take a look and see if there is a better way to accomplish what we are doing.

Rick, if you can provide details on the workaround, that would be useful.

The DPMS/hotplug is very reminiscent of https://bugzilla.kernel.org/show_bug.cgi?id=24982

Hi Chris, it looks like the workaround was for drm_fb_helper_hotplug_event() to always set fb_helper->delayed_hotplug to true and return false!   There were some xset dpms calls changed at the same time but they appear to be for a different issue specific to pinetrail.

Is this still valid with 3.1 kernel by a chance?

Hm, sounds like fbcon is too eager to show it's framebuffer. Please test the patch at:

http://permalink.gmane.org/gmane.comp.video.dri.devel/70460

Bug reporter seems to have disappeared, bug itself presumably fixed with the linked patch.