Bug 53541

Summary: GM45 regression in commit: 0b9f43a drm/i915: allow pipe A for lvds on gen4
Product: Drivers Reporter: Pär Lindfors (paran)
Component: Video(DRI - Intel)Assignee: intel-gfx-bugs (intel-gfx-bugs)
Status: RESOLVED CODE_FIX    
Severity: normal CC: chris, daniel, intel-gfx-bugs
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.6 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: Xorg.0.log when running 3.8.0-rc7 (bad)
dmesg.3.8.0-rc7 (bad)
dmesg.3.8.0-rc7+ (good)
Xorg.0.log with -intel 2.21.0 on 3.8.7-rc7

Description Pär Lindfors 2013-02-10 12:24:07 UTC
With kernel 3.6 and later X is unusable on a Lenovo x200s laptop.

Good kernel versions: 3.5.0, 3.5.7
Bad kernel versions: 3.6.11, 3.7.6, 3.8.0-rc6

Distributions is Ubuntu 12.04. All tested kernels are built from
mainline and stable git.

x200s have an Intel GMA45 GPU:
$ lspci|grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

A rather non-technical description of the bug is that the screen does
not seem to be refreshed as often as it should be. For example when
typing a password into the KDM login window, no * characters are
shown. In konsole (KDEs terminal emulator) the window content
frequently freezes. I can keep on typing and running commands, but
nothing changes on the screen until I change back and forth between
either another konsole tab or another virtual desktop.

I have bisected this and the first bad commit is:

commit 0b9f43a0ee7e89013a3d913ce556715fd8acb674
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   2012-06-05 10:07:11 +0200

    drm/i915: allow pipe A for lvds on gen4
    
    Given the havoc the missing backlight pipe select code might have
    caused, let's try to re-enabled pipe A support for lvds on gen4 hw.
    Just to see what all blows up ...
...snip...

So I guess one thing that blows up is my laptop? Reverting this commit
fix the problem for me, verified on 3.6.11 and 3.8.0-rc6.

Please let me know if I can help debug this further.
Comment 1 Chris Wilson 2013-02-10 12:29:41 UTC
Lack of render cache flushing seems a strange side-effect of enabling that quirk, can you please attach your Xorg.0.log and also check for unusual CPU usage. If you xf86-video-intel driver is much older than 2.15.0 then this is a known bug in that driver.
Comment 2 Pär Lindfors 2013-02-10 19:05:33 UTC
Created attachment 92951 [details]
Xorg.0.log when running 3.8.0-rc7 (bad)
Comment 3 Pär Lindfors 2013-02-10 19:16:37 UTC
Created attachment 92961 [details]
dmesg.3.8.0-rc7 (bad)
Comment 4 Pär Lindfors 2013-02-10 19:16:58 UTC
Created attachment 92971 [details]
dmesg.3.8.0-rc7+ (good)
Comment 5 Pär Lindfors 2013-02-10 19:20:28 UTC
I have attached Xorg.0.log from 3.8.0-rc7 (bad), and dmesg output with
drm.debug=14. I also attached dmesg from 3.8.0-rc7+ (good) where
0b9f43a0 is reverted.

I have not noticed any strange CPU usage. However I have not actually
used the bad kernel versions very much, due to this bug.

The version of xserver-xorg-video-intel is 2:2.17.0-1ubuntu4.3.
Comment 6 Pär Lindfors 2013-02-10 19:26:27 UTC
Forgot to mention this. The reason for not attaching Xorg.0.log from
3.8.0-rc7+ is that it is identical as the one from 3.8.0-rc7.

--- Xorg.0.log.good     2013-02-10 19:10:45.233796374 +0100
+++ Xorg.0.log.bad      2013-02-10 19:10:41.286721791 +0100
@@ -5,4 +5,4 @@
 Build Operating System: Linux 2.6.42-34-generic x86_64 Ubuntu
-Current Operating System: Linux faran 3.8.0-rc7+ #1 SMP Sun Feb 10 14:24:25 CET 2013 x86_64
-Kernel command line: BOOT_IMAGE=/vmlinuz-3.8.0-rc7+ root=/dev/mapper/faranVG-btrfs1 ro rootflags=subvol=root pcie_aspm=force i915.i915_enable_rc6=1 splash vt.handoff=7 drm.debug=14
+Current Operating System: Linux faran 3.8.0-rc7 #1 SMP Sun Feb 10 13:58:28 CET 2013 x86_64
+Kernel command line: BOOT_IMAGE=/vmlinuz-3.8.0-rc7 root=/dev/mapper/faranVG-btrfs1 ro rootflags=subvol=root pcie_aspm=force i915.i915_enable_rc6=1 splash drm.debug=14
 Build Date: 17 January 2013  06:14:10AM
@@ -15,3 +15,3 @@
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Sun Feb 10 19:05:43 2013
+(==) Log file: "/var/log/Xorg.0.log", Time: Sun Feb 10 18:58:43 2013
 (==) Using config file: "/etc/X11/xorg.conf"
@@ -38,3 +38,3 @@
        If no devices become available, reconfigure udev or disable AutoAddDevices.
-(II) Loader magic: 0x7fe4d7474b00
+(II) Loader magic: 0x7f7fc1e64b00
 (II) Module ABI versions:
Comment 7 Chris Wilson 2013-02-10 19:37:02 UTC
Passes the smell test. Is it possible for you to test with a recent -intel to rule out a driver bug there? Would also be useful to compare the approaches taken by UXA vs SNA just in case.

I'm still convinced this is a cache-flushing issue since the symptoms match many earlier reports thereof. As for why it only affects one pipe...

Something else you can try is to switch the pipes using xrandr:

$ xrandr --output LVDS1 --crtc 0 
or
$ xrandr --output LVDS1 --crtc 1
Comment 8 Pär Lindfors 2013-02-10 22:58:51 UTC
Nice trick. Using xrandr I can change from bad to good and back
again. Just had to figure out to add --mode to the xrandr command to
avoid a black screen.

$ uname -r
3.8.0-rc7
$ # bad
$ xrandr --output LVDS1 --crtc 1 --mode 1440x900
$ # good
$ xrandr --output LVDS1 --crtc 0 --mode 1440x900
$ # bad again

Another thing I just discovered is that running some OpenGL
application also seems to fix (or at least hide) the problem as long
as the GL window remains visible on screen. I discovered this by
starting glxgears to see if it would also freeze, but this opposite
result. Various GL screensavers from xscreensaver also seem to work.

All this is still using Ubuntus 2.17.0 -intel. I will try to install a
more recent -intel driver later.
Comment 9 Pär Lindfors 2013-02-11 01:27:48 UTC
I have now enabled the xorg-edgers PPA, which have git versions
of most X packages like xorg core, drivers, libdrm, mesa and so
on.

xserver-xorg-video-intel is now version
2.21.0+git20130204.9640640a

The bug is still present, but seem to trigger slightly less
often. Both workarounds from my last comment (change crtc or run
a GL program) are still working.
Comment 10 Pär Lindfors 2013-02-11 01:41:30 UTC
Created attachment 92991 [details]
Xorg.0.log with -intel 2.21.0 on 3.8.7-rc7
Comment 11 Jani Nikula 2013-04-10 19:04:01 UTC
The old bug about enabling pipe A for lvds was bug 16307.
Comment 12 Pär Lindfors 2013-05-03 23:35:02 UTC
Chris,

I am happy to report that this bug is fixed in Linux 3.9. LVDS1
can use both CRTCs, defaults to CRTC 0 and there are no freezes.

However I could not find anything relevant in the git log, so I
did a bisect. The commit that fixes the bug is:

commit e12a2d53ae45a69aea499b64f75e7222cca0f12f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   2012-11-15 11:32:18 +0000

    drm/i915: Fix detection of base of stolen memory
    
    The routine to query the base of stolen memory was using the wrong
    registers and the wrong encodings on virtually every platform.
...

Does this make sense to you?

I have verified that cherry-picking this commit also fixes the bug on
kernel 3.6 and 3.8.

I should mention that I now run -intel 2.21.6, and I have verified
that the bug is still present if I boot an unpatched 3.6 or 3.8
kernel.

Thanks.
Comment 13 Daniel Vetter 2013-05-06 08:36:56 UTC
Well, it doesn't make much sense to me, the only sensible explanation is that we've stomped over some bios stuff. But on 3.6 we don't really use stolen memory, so I have no idea.

Anyway, I've submitted the commit for stable inclusion, thanks for reporting this issue.