* [DRM] Lower the severity of the radeon lockup messages.
@ 2011-10-21 16:51 Dave Jones
2011-10-22 7:17 ` Robert Hancock
0 siblings, 1 reply; 3+ messages in thread
From: Dave Jones @ 2011-10-21 16:51 UTC (permalink / raw)
To: airlied; +Cc: Linux Kernel
abrt files a lot of bug reports when users get GPU lockups, but there's not really
enough context to do anything useful with them. Given the lack of GPU context being
dumped, this patch removes the stack trace, so that abrt ignores the messages.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c
index 7fd4e3e..a488b50 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -263,7 +263,7 @@ retry:
*/
if (seq == rdev->fence_drv.last_seq && radeon_gpu_is_lockup(rdev)) {
/* good news we believe it's a lockup */
- WARN(1, "GPU lockup (waiting for 0x%08X last fence id 0x%08X)\n",
+ printk(KERN_WARNING "GPU lockup (waiting for 0x%08X last fence id 0x%08X)\n",
fence->seq, seq);
/* FIXME: what should we do ? marking everyone
* as signaled for now
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [DRM] Lower the severity of the radeon lockup messages.
2011-10-21 16:51 [DRM] Lower the severity of the radeon lockup messages Dave Jones
@ 2011-10-22 7:17 ` Robert Hancock
2011-10-22 7:19 ` David Airlie
0 siblings, 1 reply; 3+ messages in thread
From: Robert Hancock @ 2011-10-22 7:17 UTC (permalink / raw)
To: Dave Jones, airlied, Linux Kernel
On 10/21/2011 10:51 AM, Dave Jones wrote:
> abrt files a lot of bug reports when users get GPU lockups, but there's not really
> enough context to do anything useful with them. Given the lack of GPU context being
> dumped, this patch removes the stack trace, so that abrt ignores the messages.
>
> Signed-off-by: Dave Jones<davej@redhat.com>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c
> index 7fd4e3e..a488b50 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -263,7 +263,7 @@ retry:
> */
> if (seq == rdev->fence_drv.last_seq&& radeon_gpu_is_lockup(rdev)) {
> /* good news we believe it's a lockup */
> - WARN(1, "GPU lockup (waiting for 0x%08X last fence id 0x%08X)\n",
> + printk(KERN_WARNING "GPU lockup (waiting for 0x%08X last fence id 0x%08X)\n",
> fence->seq, seq);
> /* FIXME: what should we do ? marking everyone
> * as signaled for now
At the risk of sounding obvious, wouldn't it be better to enhance the
driver to dump out more useful debugging info in this case rather than
just suppressing the ABRT report?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [DRM] Lower the severity of the radeon lockup messages.
2011-10-22 7:17 ` Robert Hancock
@ 2011-10-22 7:19 ` David Airlie
0 siblings, 0 replies; 3+ messages in thread
From: David Airlie @ 2011-10-22 7:19 UTC (permalink / raw)
To: Robert Hancock; +Cc: Dave Jones, airlied, Linux Kernel
>
> At the risk of sounding obvious, wouldn't it be better to enhance the driver
> to dump out more useful debugging info in this case rather than just
> suppressing the ABRT report?
In theory yes, in practice that is non-trivial. The amount of data you
need to keep track off is in the MBs, it can range from any previous GPU
command stream sent to the GPU, to the contents of any of the vertex
buffers etc.
the problem with GPU lockups is you don't notice them until after you've
queued up a tonne more stuff since they are such deep pipelines.
Dave.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-10-22 7:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-21 16:51 [DRM] Lower the severity of the radeon lockup messages Dave Jones
2011-10-22 7:17 ` Robert Hancock
2011-10-22 7:19 ` David Airlie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).