Bug 43012 - i915 Modesetting - Offset Graphics - Panther Point Chipset with Sandy Bridge GPU
i915 Modesetting - Offset Graphics - Panther Point Chipset with Sandy Bridge GPU
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel)
All Linux
: P1 normal
Assigned To: drivers_video-dri-intel@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-30 01:37 UTC by Carl Richell
Modified: 2012-07-01 10:32 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.3.0-030300-generic #201203182135
Tree: Mainline
Regression: Yes


Attachments
Picture of offset desktop (449.60 KB, image/jpeg)
2012-03-30 01:42 UTC, Carl Richell
Details
dmesg boot through suspend and resume (128.30 KB, text/plain)
2012-03-30 13:20 UTC, Carl Richell
Details
intel_reg_dumper broken state (11.58 KB, text/plain)
2012-03-30 13:20 UTC, Carl Richell
Details
intel_reg_dumper working state (11.58 KB, text/plain)
2012-03-30 13:20 UTC, Carl Richell
Details
xrandr broken state (3.39 KB, text/plain)
2012-03-30 13:21 UTC, Carl Richell
Details
xrandr working state (3.39 KB, text/plain)
2012-03-30 13:21 UTC, Carl Richell
Details
Sanitize debugging state leftover by the BIOS (1.97 KB, patch)
2012-03-30 13:46 UTC, Chris Wilson
Details | Diff

Description Carl Richell 2012-03-30 01:37:41 UTC
See attached picture. Desktop is offset to the right a couple hundred pixels. Occurs in Plymouth, LightDM, and at the desktop. Replicable on two laptop models with Panther Point chipsets and Sandy Bridge GPU's.

After Suspend and Resume the desktop is in the correct position.

Bug is not present back at 3.0.26. Occurs in 3.1rc2 and forward (don't have an rc1 kernel build to test).
Comment 1 Carl Richell 2012-03-30 01:42:29 UTC
Created attachment 72747 [details]
Picture of offset desktop
Comment 2 Daniel Vetter 2012-03-30 07:04:38 UTC
Ok, can you please boot with drm.debug=0xe added to your kernel cmdline, got through suspend/resume (to fix your screen) and then attach your full dmesg (since boot). Please make sure that you have printk timestamps enabled.

Then also grab the latest intel-gpu-tools (1.2) and attach the complete output of intel_reg_dumper once for the broken state (right after boot) and once for the working state (after resume). Also please attach the output of xrandr --verbose for both cases.

Please attach these files individually as text/plain - much easier to handle than a tar.bz.
Comment 3 Carl Richell 2012-03-30 13:20:03 UTC
Created attachment 72757 [details]
dmesg boot through suspend and resume
Comment 4 Carl Richell 2012-03-30 13:20:36 UTC
Created attachment 72758 [details]
intel_reg_dumper broken state
Comment 5 Carl Richell 2012-03-30 13:20:59 UTC
Created attachment 72759 [details]
intel_reg_dumper working state
Comment 6 Carl Richell 2012-03-30 13:21:21 UTC
Created attachment 72760 [details]
xrandr broken state
Comment 7 Carl Richell 2012-03-30 13:21:35 UTC
Created attachment 72761 [details]
xrandr working state
Comment 8 Chris Wilson 2012-03-30 13:46:38 UTC
Created attachment 72762 [details]
Sanitize debugging state leftover by the BIOS
Comment 9 Carl Richell 2012-03-30 16:04:52 UTC
Chris, your patch works beautifully. From your comments, this sounds like a BIOS bug. Please clarify what should be fixed in the BIOS and I will relay the information. We should be able to fix the BIOS before these particular systems actually reach the wild.
Comment 10 Chris Wilson 2012-03-30 16:14:06 UTC
Hmm, Panther Point. If you have the Intel BIOS, I think we have notified the team already. The part in question are bits 3<<27 in the PIPEACONF/PIPEBCONF registers which modify when the display engine starts reading from the pipe following the vblank and are earmarked for debugging use only. The BIOS is leaving those bits turned on.
Comment 11 Carl Richell 2012-03-30 16:26:46 UTC
Excellent, thank you Chris.
Comment 13 Chris Wilson 2012-04-03 21:42:38 UTC
commit f47166d2b0001fcb752b40c5a2d4db986dfbea6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Mar 22 15:00:50 2012 +0000

    drm/i915: Sanitize BIOS debugging bits from PIPECONF
    
    Quoting the BSpec from time immemorial:
    
      PIPEACONF, bits 28:27: Frame Start Delay (Debug)
    
      Used to delay the frame start signal that is sent to the display planes.
      Care must be taken to insure that there are enough lines during VBLANK
      to support this setting.
    
    An instance of the BIOS leaving these bits set was found in the wild,
    where it caused our modesetting to go all squiffy and skewiff.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47271
    Reported-and-tested-by: Eva Wang <evawang@linpus.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012
    Reported-and-tested-by: Carl Richell <carl@system76.com>
    Cc: stable@kernel.org
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 14 Florian Mickler 2012-04-16 21:18:12 UTC
A patch referencing this bug report has been merged in Linux v3.4-rc2:

commit f47166d2b0001fcb752b40c5a2d4db986dfbea68
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Mar 22 15:00:50 2012 +0000

    drm/i915: Sanitize BIOS debugging bits from PIPECONF
Comment 15 Florian Mickler 2012-07-01 09:47:20 UTC
A patch referencing a commit referencing this bug report has been merged in Linux v3.5-rc1:

commit a9dcf84b14ef4e9a609910367576995e6f32f3dc
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 13 22:29:25 2012 +0200

    drm/i915: don't clobber the pipe param in sanitize_modesetting

Note You need to log in before you can comment on or make changes to this bug.