Hello, Not sure if it's of any help, but Thiago Macieira has the same model as mine, but with a different panel (lower resolution, 1366x768), and he never suffered of this problem. What comes to my mind reading your message - why should dual channel on HD+ be treated differently than on panels with lower resolution?
Kind regards, Georg On Mon, Jul 2, 2012 at 11:06 AM, Takashi Iwai <ti...@suse.de> wrote: > At Mon, 2 Jul 2012 10:54:43 +0200, > Georg Grabler wrote: >> >> I've had this problem with the e6420 on 1600x900. Applying your work >> around fixed it for me. Though, kernel 3.5-rc4 fixes the problem "for >> real" (it even fixes the default resolutions set when X comes up, >> which did not work properly before). > > OK. So far, my assumption looks correct. > >> I'm not aware of what this could cause to other resolutions than >> 1600x900, that's why i did not recommend Chakra to apply the patch. > > Well, the only question is the native resolution of the panel. > > If it ever happens with a panel lower than 1600x900 resolution, it > means that the fix should be applied to all panels. If it happens > only with such higher ones, it's likely an issue with HD+ panel > dual-channel mode, and the workaround should be applied in a limited > manner. > > > thanks, > > Takashi > >> >> Kind regards, >> Georg >> >> On Mon, Jul 2, 2012 at 10:18 AM, Takashi Iwai <ti...@suse.de> wrote: >> > At Thu, 28 Jun 2012 14:23:04 -0400, >> > Giacomo Comes wrote: >> >> >> >> On Thu, Jun 28, 2012 at 07:52:18AM +0200, Takashi Iwai wrote: >> >> > At Tue, 26 Jun 2012 15:08:32 -0400, >> >> > Giacomo Comes wrote: >> >> > > >> >> > > I have a dell latitude E6420 with Sandybridge Mobile (GT2). >> >> > > Since I got it (about one year ago), it has been a nightmare to run >> >> > > linux on it. >> >> > > At the beginning I installed openSUSE 11.4 (kernel 2.6.37.6) and the >> >> > > laptop >> >> > > would freeze almost immediately. After that I waited for newer >> >> > > kernels in order to >> >> > > see if things would improve. They did improve indeed and finally with >> >> > > kernel 3.0 >> >> > > I was able to run linux (openSUSE 11.4) without laptop freeze or >> >> > > screen issue. >> >> > > Unfortunately, the only kernel that works with my laptop is 3.0. >> >> > > Newer kernel >> >> > > (3.1, 3.2, 3.3 and 3.4) do not work. >> >> > > This is what happen if I run kernel 2.6.39, 3.1, 3.2, 3.3 and 3.4: >> >> > > The laptop boot and does the boot process fine. At the end of the >> >> > > boot process X >> >> > > starts and here the problem appears (about 50% of the times): >> >> > > the screen goes black on the left side (about 2/3 of the whole >> >> > > screen) with white >> >> > > stripes to the right side (the remaining 1/3). >> >> > > The laptop is not dead: I can remotely login or I can perform a clean >> >> > > shutdown >> >> > > if I press the power button, but the screen is totally dead. >> >> > > Another strange issue is that after a bad boot (with the black >> >> > > screen) at the >> >> > > next reboot the screen will start to flicker. The flickering will >> >> > > last some time >> >> > > and it will become less intense as the time goes until it will >> >> > > disappear completely. >> >> > > The funny thing is that the intensity of flicker depends on how long >> >> > > I keep the >> >> > > black screen. If, after the boot process, the black screen appears >> >> > > and I reboot >> >> > > the laptop immediately, then the flicked is moderate and it disappear >> >> > > after >> >> > > 1 or 2 minutes. If I keep the black screen for 1 minute or more, then >> >> > > after the >> >> > > reboot the flicker is very intense and it takes much more to fade. >> >> > >> >> > This reminds me of a similar bug I've seen on HP laptops with HD+ >> >> > (1600x900) monitors. Could you check whether the patch below helps? >> >> > >> >> > Note that it just avoids entering to the wrong mode. If your laptop >> >> > already starts flickering, at first recover from the flickering state, >> >> > apply the patch, and reboot/test. >> >> > >> >> > >> >> > Takashi >> >> > >> >> > --- >> >> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c >> >> > b/drivers/gpu/drm/i915/intel_lvds.c >> >> > index 08eb04c..3f61bba 100644 >> >> > --- a/drivers/gpu/drm/i915/intel_lvds.c >> >> > +++ b/drivers/gpu/drm/i915/intel_lvds.c >> >> > @@ -413,7 +413,7 @@ static void intel_lvds_prepare(struct drm_encoder >> >> > *encoder) >> >> > * the panel fitter. However at all other times we can just reset >> >> > * the registers regardless. >> >> > */ >> >> > - if (!HAS_PCH_SPLIT(encoder->dev) && intel_lvds->pfit_dirty) >> >> > + /*if (!HAS_PCH_SPLIT(encoder->dev) && intel_lvds->pfit_dirty)*/ >> >> > intel_lvds_disable(intel_lvds); >> >> > } >> >> > >> >> >> >> This patch seems to fix the problem. I will regularly run a kernel with >> >> this patch and report if I see any other issue. >> > >> > Which native resolution does your machine have? >> > If it's 1600x900 or such, we may consider to apply the workaround >> > generically for such resolutions. AFAIK, all the HP machines affected >> > by this symptom have 1600x900 panels (but different panel vendors). >> > >> > >> > thanks, >> > >> > Takashi >> > _______________________________________________ >> > Intel-gfx mailing list >> > Intel-gfx@lists.freedesktop.org >> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
