Skip to contentSkip to conversation

Commit ecff665f5e3f (drm/ttm: make ttm reservation calls...) causes system hang on Radeon RS780

PATCH Applied Markus Trippelsdorf 3 participants 7 messages Jul 10, 2013 – Jul 11, 2013

Subsystems (2)
DRM drivers Radeon and amdgpu DRM drivers
lore
Share & tools
lore

Markus Trippelsdorf

author Reviewed-by Jerome Glisse
#0 lore raw

By simply copy/pasting a big document under LibreOffice my system hangs itself up. Only a hard reset gets it working again.
see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551

I've bisected the issue to:

commit ecff665f5e3f1c6909353e00b9420e45ae23d995

Author: Maarten Lankhorst <[email protected]>
Date:   Thu Jun 27 13:48:17 2013 +0200

drm/ttm: make ttm reservation calls behave like reservation calls

This commit converts the source of the val_seq counter to the ww_mutex api. The reservation objects are converted later, because there is still a lockdep splat in nouveau that has to resolved first.

Signed-off-by Maarten Lankhorst <[email protected]>
Reviewed-by Jerome Glisse <[email protected]>
Signed-off-by Dave Airlie <[email protected]>
Signature · 1 line
Markus
#1 lore raw

Op 10-07-13 11:22, Markus Trippelsdorf schreef:

Quoted 12 lines

By simply copy/pasting a big document under LibreOffice my system hangs itself up. Only a hard reset gets it working again.
see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551

I've bisected the issue to:

commit ecff665f5e3f1c6909353e00b9420e45ae23d995

Author: Maarten Lankhorst <[email protected]>
Date:   Thu Jun 27 13:48:17 2013 +0200

drm/ttm: make ttm reservation calls behave like reservation calls

Quoted 8 lines

This commit converts the source of the val_seq counter to the ww_mutex api. The reservation objects are converted later, because there is still a lockdep splat in nouveau that has to resolved first.

Signed-off-by Maarten Lankhorst <[email protected]>
Reviewed-by Jerome Glisse <[email protected]>
Signed-off-by Dave Airlie <[email protected]>

Hey,

Can you try current head with CONFIG_PROVE_LOCKING set and post the lockdep splat from dmesg, if any? If there is any locking issue lockdep should warn about it. Lockdep will turn itself off after the first splat, so if the lockdep splat happens before running the affected parts those will have to be fixed first.

~Maarten

author
#2 lore raw
Quoted 21 lines · Maarten Lankhorst

Op 10-07-13 11:22, Markus Trippelsdorf schreef:

Quoted 12 lines

By simply copy/pasting a big document under LibreOffice my system hangs itself up. Only a hard reset gets it working again.
see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551

I've bisected the issue to:

commit ecff665f5e3f1c6909353e00b9420e45ae23d995

Author: Maarten Lankhorst <[email protected]>
Date:   Thu Jun 27 13:48:17 2013 +0200

drm/ttm: make ttm reservation calls behave like reservation calls

Quoted 8 lines

This commit converts the source of the val_seq counter to the ww_mutex api. The reservation objects are converted later, because there is still a lockdep splat in nouveau that has to resolved first.

Signed-off-by Maarten Lankhorst <[email protected]>
Reviewed-by Jerome Glisse <[email protected]>
Signed-off-by Dave Airlie <[email protected]>
Quoted 7 lines

Hey,

Can you try current head with CONFIG_PROVE_LOCKING set and post the lockdep splat from dmesg, if any? If there is any locking issue lockdep should warn about it. Lockdep will turn itself off after the first splat, so if the lockdep splat happens before running the affected parts those will have to be fixed first.

There was an unrelated EDAC lockdep splat, so I simply disabled it.

This is what I get:

Jul 10 11:40:44 x4 kernel: ================================================
Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
Jul 10 11:40:44 x4 kernel: ------------------------------------------------
Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held!
Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
Jul 10 11:40:44 x4 kernel: #0:  (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0
Jul 10 11:40:44 x4 kernel: #1:  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0
Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
Jul 10 11:40:53 x4 kernel: Emergency Sync complete
Signature · 1 line
Markus
#3 lore raw

Op 10-07-13 11:46, Markus Trippelsdorf schreef:

Quoted 33 lines · Maarten Lankhorst
Quoted 21 lines

Op 10-07-13 11:22, Markus Trippelsdorf schreef:

Quoted 12 lines

By simply copy/pasting a big document under LibreOffice my system hangs itself up. Only a hard reset gets it working again.
see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551

I've bisected the issue to:

commit ecff665f5e3f1c6909353e00b9420e45ae23d995

Author: Maarten Lankhorst <[email protected]>
Date:   Thu Jun 27 13:48:17 2013 +0200

drm/ttm: make ttm reservation calls behave like reservation calls

Quoted 8 lines

This commit converts the source of the val_seq counter to the ww_mutex api. The reservation objects are converted later, because there is still a lockdep splat in nouveau that has to resolved first.

Signed-off-by Maarten Lankhorst <[email protected]>
Reviewed-by Jerome Glisse <[email protected]>
Signed-off-by Dave Airlie <[email protected]>
Quoted 7 lines

Hey,

Can you try current head with CONFIG_PROVE_LOCKING set and post the lockdep splat from dmesg, if any? If there is any locking issue lockdep should warn about it. Lockdep will turn itself off after the first splat, so if the lockdep splat happens before running the affected parts those will have to be fixed first.

There was an unrelated EDAC lockdep splat, so I simply disabled it.

This is what I get:

Quoted 11 lines
Jul 10 11:40:44 x4 kernel: ================================================
Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
Jul 10 11:40:44 x4 kernel: ------------------------------------------------
Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held!
Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
Jul 10 11:40:44 x4 kernel: #0:  (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0
Jul 10 11:40:44 x4 kernel: #1:  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0
Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
Jul 10 11:40:53 x4 kernel: Emergency Sync complete

Thanks, exactly what I thought. I missed a backoff somewhere..

Does the below patch fix it?

---

drivers/gpu/drm/radeon/radeon_object.c +1 -0
index 0219d26..2020bf4 100644
@@ -377,6 +377,7 @@ int radeon_bo_list_validate(struct ww_acquire_ctx *ticket,
 					domain = lobj->alt_domain;
 					goto retry;
 				}
+				ttm_eu_backoff_reservation(ticket, head);
 				return r;
 			}
 		}
author
#4 lore raw
Quoted 45 lines · Maarten Lankhorst

Op 10-07-13 11:46, Markus Trippelsdorf schreef:

Quoted 33 lines · Maarten Lankhorst
Quoted 21 lines

Op 10-07-13 11:22, Markus Trippelsdorf schreef:

Quoted 12 lines

By simply copy/pasting a big document under LibreOffice my system hangs itself up. Only a hard reset gets it working again.
see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551

I've bisected the issue to:

commit ecff665f5e3f1c6909353e00b9420e45ae23d995

Author: Maarten Lankhorst <[email protected]>
Date:   Thu Jun 27 13:48:17 2013 +0200

drm/ttm: make ttm reservation calls behave like reservation calls

Quoted 8 lines

This commit converts the source of the val_seq counter to the ww_mutex api. The reservation objects are converted later, because there is still a lockdep splat in nouveau that has to resolved first.

Signed-off-by Maarten Lankhorst <[email protected]>
Reviewed-by Jerome Glisse <[email protected]>
Signed-off-by Dave Airlie <[email protected]>
Quoted 7 lines

Hey,

Can you try current head with CONFIG_PROVE_LOCKING set and post the lockdep splat from dmesg, if any? If there is any locking issue lockdep should warn about it. Lockdep will turn itself off after the first splat, so if the lockdep splat happens before running the affected parts those will have to be fixed first.

There was an unrelated EDAC lockdep splat, so I simply disabled it.

This is what I get:

Quoted 11 lines
Jul 10 11:40:44 x4 kernel: ================================================
Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
Jul 10 11:40:44 x4 kernel: ------------------------------------------------
Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held!
Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
Jul 10 11:40:44 x4 kernel: #0:  (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0
Jul 10 11:40:44 x4 kernel: #1:  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0
Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
Jul 10 11:40:53 x4 kernel: Emergency Sync complete
Quoted 3 lines

Thanks, exactly what I thought. I missed a backoff somewhere..

Does the below patch fix it?

Yes. Thank you for your quick reply.

Signature · 1 line
Markus
#5 lore raw

PATCH 1/1 drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate

Op 10-07-13 12:03, Markus Trippelsdorf schreef:

Quoted 46 lines · Maarten Lankhorst
Quoted 45 lines

Op 10-07-13 11:46, Markus Trippelsdorf schreef:

Quoted 44 lines · Maarten Lankhorst
Quoted 21 lines

Op 10-07-13 11:22, Markus Trippelsdorf schreef:

Quoted 12 lines

By simply copy/pasting a big document under LibreOffice my system hangs itself up. Only a hard reset gets it working again.
see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551

I've bisected the issue to:

commit ecff665f5e3f1c6909353e00b9420e45ae23d995

Author: Maarten Lankhorst <[email protected]>
Date:   Thu Jun 27 13:48:17 2013 +0200

drm/ttm: make ttm reservation calls behave like reservation calls

Quoted 8 lines

This commit converts the source of the val_seq counter to the ww_mutex api. The reservation objects are converted later, because there is still a lockdep splat in nouveau that has to resolved first.

Signed-off-by Maarten Lankhorst <[email protected]>
Reviewed-by Jerome Glisse <[email protected]>
Signed-off-by Dave Airlie <[email protected]>
Quoted 7 lines

Hey,

Can you try current head with CONFIG_PROVE_LOCKING set and post the lockdep splat from dmesg, if any? If there is any locking issue lockdep should warn about it. Lockdep will turn itself off after the first splat, so if the lockdep splat happens before running the affected parts those will have to be fixed first.

There was an unrelated EDAC lockdep splat, so I simply disabled it.

This is what I get:

Jul 10 11:40:44 x4 kernel: ================================================
Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
Jul 10 11:40:44 x4 kernel: ------------------------------------------------
Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held!
Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
Jul 10 11:40:44 x4 kernel: #0:  (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0
Jul 10 11:40:44 x4 kernel: #1:  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0
Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
Jul 10 11:40:53 x4 kernel: Emergency Sync complete
Quoted 4 lines
Quoted 3 lines

Thanks, exactly what I thought. I missed a backoff somewhere..

Does the below patch fix it?

Yes. Thank you for your quick reply.

8<------
If radeon_cs_parser_relocs fails ttm_eu_backoff_reservation doesn't get called. This left open a bug where ttm_eu_reserve_buffers succeeded but the bo's were not unlocked afterwards:

Jul 10 11:40:44 x4 kernel: ================================================
Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
Jul 10 11:40:44 x4 kernel: ------------------------------------------------
Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held!
Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
Jul 10 11:40:44 x4 kernel: #0:  (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0
Jul 10 11:40:44 x4 kernel: #1:  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0
Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
Jul 10 11:40:53 x4 kernel: Emergency Sync complete

This is a regression caused by commit ecff665f5e. "drm/ttm: make ttm reservation calls behave like reservation calls"

Reported-by Markus Trippelsdorf <[email protected]>
Tested-by Markus Trippelsdorf <[email protected]>
Signed-off-by Maarten Lankhorst <[email protected]>

---

drivers/gpu/drm/radeon/radeon_object.c +1 -0
index 0219d26..2020bf4 100644
@@ -377,6 +377,7 @@ int radeon_bo_list_validate(struct ww_acquire_ctx *ticket,
 					domain = lobj->alt_domain;
 					goto retry;
 				}
+				ttm_eu_backoff_reservation(ticket, head);
 				return r;
 			}
 		}
Applied
#6 lore raw

Re: [PATCH] drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate

I've picked up the patch for my fixes queue. Thanks!

Alex

Quoted 92 lines · Maarten Lankhorst

Op 10-07-13 12:03, Markus Trippelsdorf schreef:

Quoted 46 lines · Maarten Lankhorst
Quoted 45 lines

Op 10-07-13 11:46, Markus Trippelsdorf schreef:

Quoted 44 lines · Maarten Lankhorst
Quoted 21 lines

Op 10-07-13 11:22, Markus Trippelsdorf schreef:

Quoted 12 lines

By simply copy/pasting a big document under LibreOffice my system hangs itself up. Only a hard reset gets it working again.
see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551

I've bisected the issue to:

commit ecff665f5e3f1c6909353e00b9420e45ae23d995

Author: Maarten Lankhorst <[email protected]>
Date:   Thu Jun 27 13:48:17 2013 +0200

drm/ttm: make ttm reservation calls behave like reservation calls

Quoted 8 lines

This commit converts the source of the val_seq counter to the ww_mutex api. The reservation objects are converted later, because there is still a lockdep splat in nouveau that has to resolved first.

Signed-off-by Maarten Lankhorst <[email protected]>
Reviewed-by Jerome Glisse <[email protected]>
Signed-off-by Dave Airlie <[email protected]>
Quoted 7 lines

Hey,

Can you try current head with CONFIG_PROVE_LOCKING set and post the lockdep splat from dmesg, if any? If there is any locking issue lockdep should warn about it. Lockdep will turn itself off after the first splat, so if the lockdep splat happens before running the affected parts those will have to be fixed first.

There was an unrelated EDAC lockdep splat, so I simply disabled it.

This is what I get:

Jul 10 11:40:44 x4 kernel: ================================================
Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
Jul 10 11:40:44 x4 kernel: ------------------------------------------------
Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held!
Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
Jul 10 11:40:44 x4 kernel: #0:  (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0
Jul 10 11:40:44 x4 kernel: #1:  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0
Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
Jul 10 11:40:53 x4 kernel: Emergency Sync complete
Quoted 4 lines
Quoted 3 lines

Thanks, exactly what I thought. I missed a backoff somewhere..

Does the below patch fix it?

Yes. Thank you for your quick reply.

8<------
If radeon_cs_parser_relocs fails ttm_eu_backoff_reservation doesn't get called. This left open a bug where ttm_eu_reserve_buffers succeeded but the bo's were not unlocked afterwards:

Jul 10 11:40:44 x4 kernel: ================================================
Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
Jul 10 11:40:44 x4 kernel: ------------------------------------------------
Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held!
Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
Jul 10 11:40:44 x4 kernel: #0:  (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0
Jul 10 11:40:44 x4 kernel: #1:  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0
Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
Jul 10 11:40:53 x4 kernel: Emergency Sync complete

This is a regression caused by commit ecff665f5e. "drm/ttm: make ttm reservation calls behave like reservation calls"

Reported-by Markus Trippelsdorf <[email protected]>
Tested-by Markus Trippelsdorf <[email protected]>
Signed-off-by Maarten Lankhorst <[email protected]>

---

drivers/gpu/drm/radeon/radeon_object.c +1 -0
index 0219d26..2020bf4 100644
@@ -377,6 +377,7 @@ int radeon_bo_list_validate(struct ww_acquire_ctx *ticket,
                                        domain = lobj->alt_domain;
                                        goto retry;
                                }
+                               ttm_eu_backoff_reservation(ticket, head);
                                return r;
                        }
                }

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel