Bug 56089 - Lenovo T530 has a green bar always exists on top of the screen, bug in 3.0 stable series
Summary: Lenovo T530 has a green bar always exists on top of the screen, bug in 3.0 st...
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Daniel Vetter
QA Contact:
Depends on:
Reported: 2012-10-17 14:02 UTC by James M. Leddy
Modified: 2017-07-24 23:00 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description James M. Leddy 2012-10-17 14:02:33 UTC
This is very similar to earlier bug 47271, except an even later bios updated then broke it again. So this is the sequence of events:

 * Old bios : old kernel == works
 * bios upgrade (VBIOS 2132) : old kernel == broken
 * kernel upgrade (backport f47166d2) == fixed
 * bios upgrade == broken
 * kernel upgrade (3.2 or later) == works

We would like help identify which kernel commit fixes the problem again so that we can backport to 3.0. The interesting thing is if we _revert_ f47166d2 in the 3.0-stable branch with the latest bios, it works again. There is also a lot of info in the ubuntu bug. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1041315

This is only a bug in the 3.0 stable series, introduced by commit f47166d2 in bug 47271.

Diff in the regdump:

<         GEN6_INSTDONE_1: 0xfffffffe
>         GEN6_INSTDONE_1: 0x00000000
<         PIPEACONF: 0xc0000054 (enabled, active, 6bpc)
>         PIPEACONF: 0xc0000050 (enabled, active, 6bpc)
<         DSPASURF: 0x0096b000
>         DSPASURF: 0x04830008
<         PCH_PP_CONTROL: 0x00000003 (blacklight disabled, power down on re=
set, panel on)
>         PCH_PP_CONTROL: 0xabcd0003 (blacklight disabled, power down on re=
set, panel on)
<          RC6_RESIDENCY_TIME: 0x0001b916
<          RC6p_RESIDENCY_TIME: 0x00000000
>          RC6_RESIDENCY_TIME: 0x00331e26
>          RC6p_RESIDENCY_TIME: 0xf5d8388f
Comment 1 Daniel Vetter 2012-10-17 14:13:12 UTC
An easy, albeit brutal way is to do a reverse bisect between 3.0 and 3.2: Mark every good commit as bad and every bad commit as good and git bisect will happily tell you which commit fixed a bug (git bisect isn't using a symmetric and so needs a few tricks to figure out where a bugfix instead of a regression is).

Looking at f47166d2 I don't have any idea what could a candidate for backporting to 3.0 from 3.2.
Comment 2 Timo Aaltonen 2012-10-17 15:18:43 UTC
As I understand it, it's most likely also a problem in 3.2.15 and up which got the same commit (f47166d2b00) backported. It's yet unknown if 3.5/3.6 have fixed it, we'll test that next.
Comment 3 Timo Aaltonen 2012-10-17 15:34:21 UTC
scratch that, the commit got pulled to the distro kernel for 12.04..
Comment 4 Timo Aaltonen 2012-10-18 10:31:30 UTC
so it's confirmed that 3.2.15 is the first version that works fine. The commit needs something else in addition to it to fix the bug. Just needs to be found out what it is.
Comment 5 Timo Aaltonen 2012-10-22 10:19:10 UTC
We've bisected it down to 3bcf603f6d5d18bd9d076dc280de71f48add4101 from 3.1 that fixes the bug. Sending it to stable next.

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.