Summary: | [IVB GT2] urbanterror makes machine hang | ||
---|---|---|---|
Product: | DRI | Reporter: | libo <bo.c.li> |
Component: | DRM/Intel | Assignee: | Eugeni Dodonov <eugeni> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | high | CC: | ben, chris, daniel, jbarnes, kenneth |
Version: | XOrg git | ||
Hardware: | All | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 42991, 44622 |
Description
libo
2012-01-09 20:20:55 UTC
As usual, please attach full dmesg and the i915_error_state plus any other relevant details. Also try with i915.reset=0 and without gnome-session to simplify the test environment and hopefully reduce the system hang into a GPU hang. The bug also exists even if running it with simplify test enviroment. (In reply to comment #2) > Also try with i915.reset=0 and without gnome-session to simplify the test > environment and hopefully reduce the system hang into a GPU hang. I try to get dmesg of kernel with netconsole, but I can't get anything. Do I need to add some parameter with kernel ?Or do you have other advice to get more message? (In reply to comment #1) > As usual, please attach full dmesg and the i915_error_state plus any other > relevant details. Could any developer confirm this is reproducible or not? Is this a regression? If so, please bisect it. I can reproduce this on my IVB. I doubt it's a regression. At least, not a recent one. I'll see if I can create an apitrace that reproduces the issue. I don't think it's a regression because the bug has always exists but it can't be reproduced steadily before. This bug only exists on IVB GT2. I have (In reply to comment #8) > I don't think it's a regression because the bug has always exists but it can't > be reproduced steadily before. Ken, is it still reproducible if you pretend it's a GT1 and use the more conservative defaults in mesa? I'm on vacation from Jan.19 to Feb.5. My email response may be slow. Ken, Eugeni, can you test whether the recent batch of IVB w/a help here? The magic IVB hang-fixing patches seem to have solved this one as well. The Ivy Bridge hang workarounds have made it to drm-intel-fixes and have landed in Linus tree. They should be available in 3.3-rc5. commit d71de14ddf423ccc9a2e3f7e37553c99ead20d7c Author: Kenneth Graunke <kenneth@whitecape.org> Date: Wed Feb 8 12:53:52 2012 -0800 drm/i915: gen7: Disable the RHWO optimization as it can cause GPU hangs. The BSpec Workarounds page states that bits 10 and 26 must be set to avoid 3D ring hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610 Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> commit db099c8f963fe656108e0a068274c5580a17f69b Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Wed Feb 8 12:53:51 2012 -0800 drm/i915: gen7: work around a system hang on IVB This adds the workaround for WaCatErrorRejectionIssue which could result in a system hang. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610 Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> commit e4e0c058a19c41150d12ad2d3023b3cf09c5de67 Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Wed Feb 8 12:53:50 2012 -0800 drm/i915: gen7: Implement an L3 caching workaround. This adds two cache-related workarounds for Ivy Bridge which can lead to 3D ring hangs and corruptions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610 Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> A patch referencing this bug report has been merged in Linux v3.3-rc5: commit eae66b50c760233fad526edf4a0d327be17a055d Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Wed Feb 8 12:53:49 2012 -0800 drm/i915: gen7: implement rczunit workaround I have verified it and issue has been fixed. commit eae66b50c760233fad526edf4a0d327be17a055d Hi Daniel, has your branch integrated this patch? commit eae66b50c760233fad526edf4a0d327be17a055d Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Wed Feb 8 12:53:49 2012 -0800 drm/i915: gen7: implement rczunit workaround (In reply to comment #1) > As usual, please attach full dmesg and the i915_error_state plus any other > relevant details. I can't find it in -next (or -queued) branch . (In reply to comment #18) > Hi Daniel, has your branch integrated this patch? > > commit eae66b50c760233fad526edf4a0d327be17a055d > Author: Eugeni Dodonov <eugeni.dodonov@intel.com> > Date: Wed Feb 8 12:53:49 2012 -0800 > > drm/i915: gen7: implement rczunit workaround > > (In reply to comment #1) > > As usual, please attach full dmesg and the i915_error_state plus any other > > relevant details. > --- Comment #19 from libo <bo.c.li@intel.com> 2012-03-30 20:36:54 PDT ---
> I can't find it in -next (or -queued) branch .
It's not there yet, it's only in -testing. I plan to merge -fixes into
-next before the next testing cycle (assuming that all the things I'd like
to end up in next are indeed there).
When continually running openarena above 10 times, it would cause GPU hang on IVB. Ouping Zhang, please open a new bug report for the openarena hangs, it sounds like they are a new (and maybe unrelated) sighting. This patch also can fix the below issue. (In reply to comment #22) > Ouping Zhang, please open a new bug report for the openarena hangs, it sounds > like they are a new (and maybe unrelated) sighting. Closing old verified+fixed. |
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.