Your message dated Sat, 24 Nov 2012 17:57:12 -0800 with message-id <[email protected]> and subject line Re: i915: please save more useful debugging info when GPU locks up has caused the Debian Bug report #662348, regarding i915: please save more useful debugging info when GPU locks up to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 662348: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662348 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Source: linux-2.6 Version: 2.6.32-41 Severity: wishlist Tags: upstream patch After an i915 GPU hang, apparently[*] the most convenient and useful information a person can provide is the last batch buffer. A patch applied in the 2.6.34 merge window taught the driver to save this information on error: 9df30794f609 "drm/i915: Record batch buffer following GPU error" 2010-02-18 Ben, would the attached patches make sense for squeeze? (Warning: untested. I don't have a machine using Intel graphics.) With the first applied, one can do the following after a GPU hang. mount -t debugfs debugfs /sys/kernel/debug cat /sys/kernel/debug/dri/0/i915_error_state >i915_error_state A later patch adds a notice inviting the user to do that to the kernel log. The patches do not seem very risky (the first one adds the error state collection feature and the ones afterwards are minor tweaks I noticed while hunting for potential bugfixes relating to that), but this is more complication than stable_kernel_rules.txt encourages. So these are not meant as candidates for inclusion in 2.6.32.y+drm33.z. [*] judging from <http://intellinuxgraphics.org/how_to_report_bug.html>: "for GPU hang, get the last batch buffer (see the guide)". Chris Wilson (4): drm/i915: Record batch buffer following GPU error drm/i915: Only print an message if there was an error drm/i915: Only print 'generating error event' if we actually are drm/i915: Include 'i915_error_state' hint for when the GPU catches fire Daniel Vetter (2): drm/i915: unload: fix error_work races drm/i915: unload: don't leak error state drivers/gpu/drm/i915/i915_debugfs.c | 85 +++++++++++ drivers/gpu/drm/i915/i915_dma.c | 10 +- drivers/gpu/drm/i915/i915_drv.h | 21 +++ drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 266 ++++++++++++++++++++++++++++++++--- drivers/gpu/drm/i915/i915_reg.h | 1 + 6 files changed, 359 insertions(+), 26 deletions(-)
--- End Message ---
--- Begin Message ---tags 662348 + wontfix quit Jonathan Nieder wrote: > The patches do not seem very risky (the first one adds the error state > collection feature and the ones afterwards are minor tweaks I noticed > while hunting for potential bugfixes relating to that), but this is > more complication than stable_kernel_rules.txt encourages. So these > are not meant as candidates for inclusion in 2.6.32.y+drm33.z. In practice, updating to a newer kernel is generally a better debugging strategy. Closing. Regards, Jonathan
--- End Message ---
