| Message ID | 1426761584-16693-1-git-send-email-deepak.s@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, 19 Mar 2015, deepak.s@linux.intel.com wrote: > From: Deepak S <deepak.s@linux.intel.com> > > Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some > of the baytrail systems :(. Switching back to legacy mode rps. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012 > Signed-off-by: Deepak S <deepak.s@linux.intel.com> Introduced in commit 31685c258e0b0ad6aa486c5ec001382cf8a64212 Author: Deepak S <deepak.s@linux.intel.com> Date: Thu Jul 3 17:33:01 2014 -0400 drm/i915/vlv: WA for Turbo and RC6 to work together. Cc: stable@vger.kernel.org > --- > drivers/gpu/drm/i915/i915_irq.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 6d8340d..7bbdede 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) > INIT_WORK(&dev_priv->l3_parity.error_work, ivybridge_parity_work); > > /* Let's track the enabled rps events */ > - if (IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) > - /* WaGsvRC0ResidencyMethod:vlv */ > - dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED; > - else > - dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; > + dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; > > INIT_DELAYED_WORK(&dev_priv->gpu_error.hangcheck_work, > i915_hangcheck_elapsed); > -- > 1.9.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote: > From: Deepak S <deepak.s@linux.intel.com> > > Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some > of the baytrail systems :(. Switching back to legacy mode rps. Do we want to throw out the actual code as well then? > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012 > Signed-off-by: Deepak S <deepak.s@linux.intel.com> > --- > drivers/gpu/drm/i915/i915_irq.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 6d8340d..7bbdede 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) > INIT_WORK(&dev_priv->l3_parity.error_work, ivybridge_parity_work); > > /* Let's track the enabled rps events */ > - if (IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) > - /* WaGsvRC0ResidencyMethod:vlv */ > - dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED; > - else > - dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; > + dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; > > INIT_DELAYED_WORK(&dev_priv->gpu_error.hangcheck_work, > i915_hangcheck_elapsed); > -- > 1.9.1
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote: > From: Deepak S <deepak.s@linux.intel.com> > > Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some > of the baytrail systems :(. Switching back to legacy mode rps. Is there any way to identify either what systems it's OK to use on, or to identif what Baytrail systems it isn't OK to use on? Just reverting this completely seems overly broad if it's possible to tell the difference between working and non-working systems. Kind regards, David Weinehall
On Thursday 19 March 2015 04:48 PM, Ville Syrjälä wrote: > On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote: >> From: Deepak S <deepak.s@linux.intel.com> >> >> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some >> of the baytrail systems :(. Switching back to legacy mode rps. > Do we want to throw out the actual code as well then? > Chris as cleaned up patches for VLV rps WA. I think its worth a try >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012 >> Signed-off-by: Deepak S <deepak.s@linux.intel.com> >> --- >> drivers/gpu/drm/i915/i915_irq.c | 6 +----- >> 1 file changed, 1 insertion(+), 5 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c >> index 6d8340d..7bbdede 100644 >> --- a/drivers/gpu/drm/i915/i915_irq.c >> +++ b/drivers/gpu/drm/i915/i915_irq.c >> @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) >> INIT_WORK(&dev_priv->l3_parity.error_work, ivybridge_parity_work); >> >> /* Let's track the enabled rps events */ >> - if (IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) >> - /* WaGsvRC0ResidencyMethod:vlv */ >> - dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED; >> - else >> - dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; >> + dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; >> >> INIT_DELAYED_WORK(&dev_priv->gpu_error.hangcheck_work, >> i915_hangcheck_elapsed); >> -- >> 1.9.1
On Thursday 19 March 2015 05:14 PM, David Weinehall wrote: > On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote: >> From: Deepak S <deepak.s@linux.intel.com> >> >> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some >> of the baytrail systems :(. Switching back to legacy mode rps. > Is there any way to identify either what systems it's OK to use on, > or to identif what Baytrail systems it isn't OK to use on? > > Just reverting this completely seems overly broad if it's possible to > tell the difference between working and non-working systems. > > > Kind regards, David Weinehall Restricting the changes to few system will be the right way to go. How do we get details of now working system? - Deepak
On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote: > > > On Thursday 19 March 2015 05:14 PM, David Weinehall wrote: > >On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote: > >>From: Deepak S <deepak.s@linux.intel.com> > >> > >>Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some > >>of the baytrail systems :(. Switching back to legacy mode rps. > >Is there any way to identify either what systems it's OK to use on, > >or to identif what Baytrail systems it isn't OK to use on? > > > >Just reverting this completely seems overly broad if it's possible to > >tell the difference between working and non-working systems. > > Restricting the changes to few system will be the right way to go. > How do we get details of now working system? That depends. Who reported the non-working Baytrail-systems? And just as importantly, do we have Baytrail systems where this is confirmed to work? If we can identify the respective revisions of the systems we might be able to discern the pattern and continue from there. Kind regards, David Weinehall
On Thu, Mar 19, 2015 at 03:38:19PM +0200, David Weinehall wrote: > On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote: > > > > > > On Thursday 19 March 2015 05:14 PM, David Weinehall wrote: > > >On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote: > > >>From: Deepak S <deepak.s@linux.intel.com> > > >> > > >>Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some > > >>of the baytrail systems :(. Switching back to legacy mode rps. > > >Is there any way to identify either what systems it's OK to use on, > > >or to identif what Baytrail systems it isn't OK to use on? > > > > > >Just reverting this completely seems overly broad if it's possible to > > >tell the difference between working and non-working systems. > > > > Restricting the changes to few system will be the right way to go. > > How do we get details of now working system? > > That depends. Who reported the non-working Baytrail-systems? > And just as importantly, do we have Baytrail systems where this is > confirmed to work? > > If we can identify the respective revisions of the systems > we might be able to discern the pattern and continue from there. My experience with random crashes with rps on snb/ivb is that there's no solid systems, just systems where no one has bothered to be really evil yet. I'd be really cautious with whitelisting since it tends to not really solve the underlying bug (if there is one), usually blows up really fast in size and is long-term unmaintainable. We've been there a few times with other hacks and issues :( -Daniel
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 6004
-------------------------------------Summary-------------------------------------
Platform Delta drm-intel-nightly Series Applied
PNV -1 272/272 271/272
ILK 301/301 301/301
SNB 303/303 303/303
IVB 342/342 342/342
BYT 287/287 287/287
HSW 362/362 362/362
BDW 308/308 308/308
-------------------------------------Detailed-------------------------------------
Platform Test drm-intel-nightly Series Applied
PNV igt_gem_userptr_blits_minor-sync-interruptible DMESG_WARN(1)PASS(2) DMESG_WARN(1)PASS(1)
Note: You need to pay more attention to line start with '*'
On Thu, 19 Mar 2015, Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, Mar 19, 2015 at 03:38:19PM +0200, David Weinehall wrote: >> On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote: >> > >> > >> > On Thursday 19 March 2015 05:14 PM, David Weinehall wrote: >> > >On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote: >> > >>From: Deepak S <deepak.s@linux.intel.com> >> > >> >> > >>Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some >> > >>of the baytrail systems :(. Switching back to legacy mode rps. >> > >Is there any way to identify either what systems it's OK to use on, >> > >or to identif what Baytrail systems it isn't OK to use on? >> > > >> > >Just reverting this completely seems overly broad if it's possible to >> > >tell the difference between working and non-working systems. >> > >> > Restricting the changes to few system will be the right way to go. >> > How do we get details of now working system? >> >> That depends. Who reported the non-working Baytrail-systems? >> And just as importantly, do we have Baytrail systems where this is >> confirmed to work? >> >> If we can identify the respective revisions of the systems >> we might be able to discern the pattern and continue from there. > > My experience with random crashes with rps on snb/ivb is that there's no > solid systems, just systems where no one has bothered to be really evil > yet. > > I'd be really cautious with whitelisting since it tends to not really > solve the underlying bug (if there is one), usually blows up really fast > in size and is long-term unmaintainable. We've been there a few times with > other hacks and issues :( Plenty of talk but no final verdict on the patch either way, and the bug is still open too. :( Deepak, is this patch still needed? BR, Jani. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Monday 13 April 2015 05:36 PM, Jani Nikula wrote: > On Thu, 19 Mar 2015, Daniel Vetter <daniel@ffwll.ch> wrote: >> On Thu, Mar 19, 2015 at 03:38:19PM +0200, David Weinehall wrote: >>> On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote: >>>> >>>> On Thursday 19 March 2015 05:14 PM, David Weinehall wrote: >>>>> On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote: >>>>>> From: Deepak S <deepak.s@linux.intel.com> >>>>>> >>>>>> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some >>>>>> of the baytrail systems :(. Switching back to legacy mode rps. >>>>> Is there any way to identify either what systems it's OK to use on, >>>>> or to identif what Baytrail systems it isn't OK to use on? >>>>> >>>>> Just reverting this completely seems overly broad if it's possible to >>>>> tell the difference between working and non-working systems. >>>> Restricting the changes to few system will be the right way to go. >>>> How do we get details of now working system? >>> That depends. Who reported the non-working Baytrail-systems? >>> And just as importantly, do we have Baytrail systems where this is >>> confirmed to work? >>> >>> If we can identify the respective revisions of the systems >>> we might be able to discern the pattern and continue from there. >> My experience with random crashes with rps on snb/ivb is that there's no >> solid systems, just systems where no one has bothered to be really evil >> yet. >> >> I'd be really cautious with whitelisting since it tends to not really >> solve the underlying bug (if there is one), usually blows up really fast >> in size and is long-term unmaintainable. We've been there a few times with >> other hacks and issues :( > Plenty of talk but no final verdict on the patch either way, and the bug > is still open too. :( > > Deepak, is this patch still needed? > > BR, > Jani. Hi Jani, Chris has cleaned up patches for "WA for Turbo and RC6 to work" & these patches are helping to resolve freeze issue. We can ignore this patch. :) Thanks Deepak > > > > >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 6d8340d..7bbdede 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) INIT_WORK(&dev_priv->l3_parity.error_work, ivybridge_parity_work); /* Let's track the enabled rps events */ - if (IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) - /* WaGsvRC0ResidencyMethod:vlv */ - dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED; - else - dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; + dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; INIT_DELAYED_WORK(&dev_priv->gpu_error.hangcheck_work, i915_hangcheck_elapsed);