Bug 77156

Summary:

One screen black in Zaphod configuration (regression)

Product:

xorg

Reporter:

Nick Bowler <nbowler>

Component:

Driver/intel

Assignee:

Chris Wilson <chris>

Status:

RESOLVED FIXED

QA Contact:

Intel GFX Bugs mailing list <intel-gfx-bugs>

Severity:

normal

Priority:

medium

Version:

git

Hardware:

Other

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Xorg log	none
Xorg log from previously working version	none

Description Nick Bowler 2014-04-07 19:43:02 UTC

Created attachment 97050 [details]
Xorg log

After updating xf86-video-intel to latest my primary display in a zaphod
configuration shows black.  FWIW, the problematic display is connected via
HDMI; but the VGA display is still working.  The display is "gone" in that I
cannot move the mouse cursor off of the VGA display, although if I run xrandr
it is still there in spirit, but apparently configured to an 8x8 mode.

  % echo $DISPLAY
  :2.1
  % xrandr -display :2.0
  Screen 0: minimum 8 x 8, current 8 x 8, maximum 32767 x 32767
  HDMI1 connected (normal left inverted right x axis y axis)
     1920x1080      59.9 +   60.0     60.0     50.0     59.9  
     1920x1080i     60.1     50.0     60.0  
     1680x1050      59.9  
     1280x1024      75.0     60.0  
     1152x864       75.0  
     1280x720       60.0     50.0     59.9  
     1024x768       75.1     60.0  
     832x624        74.6  
     800x600        75.0     60.3     56.2  
     720x576        50.0  
     720x480        60.0     59.9  
     640x480        75.0     60.0     59.9  
     720x400        70.1  
  VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Bisection pinpoints the following as the problematic commit, and reverting
this commit corrects the issue.

  35b03b3fe6213eb3e08f05efe3428bd6bc5421d2 is the first bad commit
  commit 35b03b3fe6213eb3e08f05efe3428bd6bc5421d2
  Author: Chris Wilson <chris@chris-wilson.co.uk>
  Date:   Fri Mar 28 09:14:59 2014 +0000
  
      sna: Virtual CRTCs are last, so break loops early
      
      We know that all the virtual CRTCs are at the end of the CRTC array, so
      when we see the first one, we can stop the processing of real CRTCs.
      
      Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
  
  :040000 040000 b9e518145aae38b28e7bdd18c72f5d123901424f 2380f4e62562601f678258f4363402b3da9be615 M	src

server 1.15.0
libdrm 2.4.52
linux  3.12.5

Comment 1 Chris Wilson 2014-04-07 20:59:54 UTC

Can you please compile with --enable-debug=full and attach the Xorg.0.log? I'll try to set it up myself tomorrow. The issue I guess is that we end up with unwanted output entries that we mistake for virtual as they have no driver privates.

Comment 2 Chris Wilson 2014-04-08 07:25:20 UTC

In a Zaphod configuration, we should not be creating Outputs or Crtcs for the other heads, so our array should still be intact. Can you please attach the working Xorg.log?

Comment 3 Chris Wilson 2014-04-08 07:47:44 UTC

commit e6b03269d01e61527641639c6fb7b796205e6ed8
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 8 08:44:56 2014 +0100

    sna: Continue to reprobe for ZaphodHeads with a mixed up configuration
    
    Fixes regresion from
    commit 35b03b3fe6213eb3e08f05efe3428bd6bc5421d2
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Fri Mar 28 09:14:59 2014 +0000
    
        sna: Virtual CRTCs are last, so break loops early
    
    as the conflicting Zaphod detection requires on searching all potential
    CRTCs without finding the match. By breaking early on the virtual CRTC,
    we concluded that the setup was actually valid, but disabled.
    
    Reported-by: Nick Bowler <nbowler@draconx.ca>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77156
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Comment 4 Nick Bowler 2014-04-08 14:30:49 UTC

Created attachment 97081 [details]
Xorg log from previously working version

That seems to have fixed it, thanks!

In case you still care I attached the log from the old working version.

Comment 5 Chris Wilson 2014-04-08 15:00:00 UTC

Thanks, the working log and testing confirms that the regression was the initial mode probing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.