LP:919350 Regression Commit Identified
Herton Ronaldo Krzesinski
herton.krzesinski at canonical.com
Fri Jan 27 15:43:14 UTC 2012
On Fri, Jan 27, 2012 at 07:09:58AM -0800, Brad Figg wrote:
> On 01/27/2012 04:41 AM, Tim Gardner wrote:
> >On 01/27/2012 04:51 AM, Herton Ronaldo Krzesinski wrote:
> >>On Thu, Jan 26, 2012 at 01:41:48PM -0700, Tim Gardner wrote:
> >>>On 01/26/2012 01:18 PM, Joseph Salisbury wrote:
> >>>>Hi Tim and Leann,
> >>>>
> >>>>The commit that caused the regression for bug 919350[1] has been
> >>>>identified:
> >>>>
> >>>>e9925217e61dd3594f81b415f2b7e077426f208f
> >>
> >>The same change on oneiric is causing an issue on Precise as well, but a
> >>different one (reported to be on resume from suspend):
> >>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/917330
> >>
> >>So 3.2 also presents a regression, but in a different way, and is
> >>already being worked upstream to be fixed (reported also here:
> >>https://lkml.org/lkml/2012/1/21/66, initial fix here:
> >>http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg07955.html)
> >>
> >>The reports on bug 919350 is a different regression (no screen on boot),
> >>and people there says that 3.2 works fine. I didn't find any problem in
> >>the backport, except that it still uses (doesn't change)
> >>dev_priv->edp.bpp, while in upstream this code changed. I guess this bpp
> >>is low to make the link value less than it should be, resulting in the
> >>failure later (wrong link * lanes selection).
> >>
> >>May be the backport for 3.0 requires also commits
> >>858fa03527ded333dc5701f546bd5d1b5d7515ad and
> >>89c6143263ef8e14e42e17324a234418d8030b10 (with this last one changed
> >>later to not use intel_crtc->bpp as it causes the later resume from
> >>suspend issue in 3.2).
> >>
> >>But I tend that we should just revert the backport from oneiric, even if
> >>bringing back bug 899598 (better a low resolution than no screen at all),
> >>we are already bringing to many changes to a stable release and
> >>diverging. Let me know what you think, I can send a revert for the
> >>oneiric kernel, or ask reporters on 919350 to try the backport again
> >>plus the additional changes.
> >>
> >
> >
> >Reverting would be my inclination.
> >
> >rtg
>
> I concur. Lets get this out of Oneiric and get it respun. We can
> get this out in this cycle.
Ok, I'm going to revert it directly on master and respinning oneiric today.
>
> Brad
> --
> Brad Figg brad.figg at canonical.com http://www.canonical.com
>
--
[]'s
Herton
More information about the kernel-team
mailing list