Lenovo T530 has a green bar always exists on top of the screen, from initial boot to normal boot, from bootsplash to homescreen, always flashing.

Bug #1041315 reported by James M. Leddy on 2012-08-24
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
OEM Priority Project
Critical
Unassigned
linux (Ubuntu)
Critical
Unassigned
Declined for Precise by Chris Van Hoof
Oneiric
Critical
Timo Aaltonen

Bug Description

SRU justification:

Impact:

Commit "628280f36e4fdbd drm/i915: Sanitize BIOS debugging bits from PIPECONF" got in the oneiric kernel via upstream, since it fixed a similar issue as here with an earlier version of the intel VBIOS. With a newer VBIOS however, the issue is back. Simply reverting the commit would likely mean breaking other setups.

this is a critical bug for some our OEM's

Fix:

upstream patch 3bcf603f6d5d18b from 3.1 works around a bug in the CPT/PPT PCH chips, and it was bisected as the commit that fixes the bug in 3.1 and up.

Testcase:

boot a kernel that doesn't have 3bcf603f6d5d18b but has 628280f36e4fdbd
on hw that has a "new enough" VBIOS.

--

Issue Description
-----------------

Garbage green lines (4-5 pixel lines) appear on top of some Lenovo laptops'
screens, persist from boot splash screen to desktop running.

Collected Data
--------------

Attached are the kernel dmesg, Xorg.0.log and dump files by intel_reg_dumper
for oneiric installation with kernel version 3.0.0-19.33 and 3.0.0-20.34, and
for precise installation with kernel version 3.2.0-23.26.

Observations
------------

2. This issue only happens on Oneiric with kernel version 3.0.0-20.34
and later ones

3. This issue does not happen on Oneiric with kernel version
3.0.0-19.33 and previous ones

4. This issue does not happen on Precise (12.04) with kernel version 3.2.0-23.36

5. This issue is caused by the upstream commit below:

   f47166d2 drm/i915: Sanitize BIOS debugging bits from PIPECONF

   The rationale and original bug description for the above commit can be
   found at https://bugs.freedesktop.org/show_bug.cgi?id=47271

6. This issue would be gone if the above commit is reverted on Oneiric kernel
   version 3.0.0-19.33 and later ones

7. There is one other commit below which fixed an issue of the above commit
   in later kernel version, BUT this commit was verified to have nothing to
   do with the issue here:

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

8. This issue was reported to be related to BIOS version as well (see comment #3)

9. There is a WARN_ON() oops on Oneiric with both kernel versions, but this is
   supposedly an unrelated seperate issue, as it happens in both cases, but
   presumably fixed in Precise.

10. By comparing the dump contents between two kernels running on Oneiric, the
    significant difference is the PIPEACONF register

11. By comparing the dump contents between oneiric and precise, there are many
    more registers with different values

Summary
-------

We are able to identify the guilty commit, and are able to provide a workaround
by reverting the commit or by doing PIPECONF register change for non-relevant
machines. However, we are not able to form a correct theory to explain exactly
the above observations and to shape a correct patch to fix the root cause.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1041315

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
description: updated
tags: added: blocks-hwcert-enablement
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Incomplete → Triaged
tags: added: oneiric
James M. Leddy (jm-leddy) wrote :

The bug-bind utility nominated precise. Please ignore, that is an error.

James Ferguson (jamesf) wrote :

I can confirm that this was definitely triggered by BIOS in combination with the mentioned patch. BIOS H0ET34WW triggers the problem, an earlier BIOS (from memory H0ET31WW) definitely did not show the problem.

description: updated

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:

 2c2
< GEN6_INSTDONE_1: 0xfffffffe
---
> GEN6_INSTDONE_1: 0x00000000
14c14
< PIPEACONF: 0xc0000054 (enabled, active, 6bpc)
---
> PIPEACONF: 0xc0000050 (enabled, active, 6bpc)
34c34
< DSPASURF: 0x0096b000
---
> DSPASURF: 0x04830008
169c169
< 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)
174,175c174,175
< RC6_RESIDENCY_TIME: 0x0001b916
< RC6p_RESIDENCY_TIME: 0x00000000
---
> RC6_RESIDENCY_TIME: 0x00331e26
> RC6p_RESIDENCY_TIME: 0xf5d8388f

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.

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.

scratch that, the commit got pulled to the distro kernel for 12.04..

Jamie Chang (jamie315) on 2012-10-18
Changed in oem-priority:
importance: Undecided → Critical

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.

Changed in linux (Ubuntu):
importance: Medium → Critical
assignee: nobody → Timo Aaltonen (tjaalton)

We've bisected it down to 3bcf603f6d5d18bd9d076dc280de71f48add4101 from 3.1 that fixes the bug. Sending it to stable next.

Timo Aaltonen (tjaalton) wrote :

The fixing commit is 3bcf603f6d5d18bd9d076dc280de71f48add4101 from 3.1. It needs to be added to 3.0 on oneiric.

Changed in linux (Ubuntu Oneiric):
importance: Undecided → Critical
status: New → In Progress
assignee: nobody → Timo Aaltonen (tjaalton)
Timo Aaltonen (tjaalton) wrote :

tracking this for oneiric

Changed in linux (Ubuntu):
assignee: Timo Aaltonen (tjaalton) → nobody
status: Triaged → Fix Released
Timo Aaltonen (tjaalton) on 2012-10-22
description: updated
Tim Gardner (timg-tpi) on 2012-10-22
Changed in linux (Ubuntu Oneiric):
status: In Progress → Fix Committed
Changed in oem-priority:
status: New → Invalid
Changed in linux:
importance: Unknown → Medium
status: Unknown → Fix Released
Changed in linux (Ubuntu Oneiric):
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed
Herton R. Krzesinski (herton) wrote :

The commit for this issue came in via a stable upstream release (linux 3.0.49). As such it is not subject to the standard bug verification process.

tags: added: verification-done-oneiric

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Launchpad Janitor (janitor) wrote :
Download full text (15.0 KiB)

This bug was fixed in the package linux - 3.0.0-28.45

---------------
linux (3.0.0-28.45) oneiric-proposed; urgency=low

  [Luis Henriques]

  * Release Tracking Bug
    - LP: #1078663

  [ Tim Gardner ]

  * [Config] updateconfigs for stable updates

  [ Upstream Kernel Changes ]

  * Revert "SUNRPC: Ensure we close the socket on EPIPE errors too..."
    - LP: #1075332
  * mn10300: only add -mmem-funcs to KBUILD_CFLAGS if gcc supports it
    - LP: #1067857
  * kbuild: make: fix if_changed when command contains backslashes
    - LP: #1067857
  * media: rc: ite-cir: Initialise ite_dev::rdev earlier
    - LP: #1067857
  * ACPI: run _OSC after ACPI_FULL_INITIALIZATION
    - LP: #1067857
  * PCI: acpiphp: check whether _ADR evaluation succeeded
    - LP: #1067857
  * lib/gcd.c: prevent possible div by 0
    - LP: #1067857
  * kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()
    - LP: #1067857
  * drivers/scsi/atp870u.c: fix bad use of udelay
    - LP: #1067857
  * workqueue: add missing smp_wmb() in process_one_work()
    - LP: #1067857
  * xfrm: Workaround incompatibility of ESN and async crypto
    - LP: #1067857
  * xfrm_user: return error pointer instead of NULL
    - LP: #1067857
  * xfrm_user: return error pointer instead of NULL #2
    - LP: #1067857
  * xfrm: fix a read lock imbalance in make_blackhole
    - LP: #1067857
  * xfrm_user: fix info leak in copy_to_user_auth()
    - LP: #1067857
  * xfrm_user: fix info leak in copy_to_user_state()
    - LP: #1067857
  * xfrm_user: fix info leak in copy_to_user_policy()
    - LP: #1067857
  * xfrm_user: fix info leak in copy_to_user_tmpl()
    - LP: #1067857
  * xfrm_user: don't copy esn replay window twice for new states
    - LP: #1067857
  * xfrm_user: ensure user supplied esn replay window is valid
    - LP: #1067857
  * net: ethernet: davinci_cpdma: decrease the desc count when cleaning up
    the remaining packets
    - LP: #1067857
  * ixp4xx_hss: fix build failure due to missing linux/module.h inclusion
    - LP: #1067857
  * netxen: check for root bus in netxen_mask_aer_correctable
    - LP: #1067857
  * net-sched: sch_cbq: avoid infinite loop
    - LP: #1067857
  * pkt_sched: fix virtual-start-time update in QFQ
    - LP: #1067857
  * sierra_net: Endianess bug fix.
    - LP: #1067857
  * 8021q: fix mac_len recomputation in vlan_untag()
    - LP: #1067857
  * ipv6: release reference of ip6_null_entry's dst entry in __ip6_del_rt
    - LP: #1067857
  * tcp: flush DMA queue before sk_wait_data if rcv_wnd is zero
    - LP: #1067857
  * sctp: Don't charge for data in sndbuf again when transmitting packet
    - LP: #1067857
  * pppoe: drop PPPOX_ZOMBIEs in pppoe_release
    - LP: #1067857
  * net: small bug on rxhash calculation
    - LP: #1067857
  * net: guard tcp_set_keepalive() to tcp sockets
    - LP: #1067857
  * ipv4: raw: fix icmp_filter()
    - LP: #1067857
  * ipv6: raw: fix icmpv6_filter()
    - LP: #1067857
  * ipv6: mip6: fix mip6_mh_filter()
    - LP: #1067857
  * l2tp: fix a typo in l2tp_eth_dev_recv()
    - LP: #1067857
  * netrom: copy_datagram_iovec can fail
    - LP: #1067857
  * net: do not disable sg for packets requiring no checksum
    - LP: #1067857
  * ...

Changed in linux (Ubuntu Oneiric):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.