Bug 23436

Summary:	RV620 locks up on starting/quiting 3D app
Product:	Mesa	Reporter:	Rafał Miłecki <zajec5>
Component:	Drivers/DRI/R600	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Rafał Miłecki 2009-08-21 03:03:31 UTC

I use Mesa master git and agd5f's r6xx-r7xx-3d git.

IIRC I didn't experience any lock up while running 3D app. However it happens often while starting (first frame) or quiting.

It's hard to reproduce with glxgears (last 20 tries of start&quit didn't hit bug) but really easy to reproduce with morph3d. Starting&quiting morph3d about 3-5 times is usually enought to lock up.

When machine locks up I can ssh to it or use SysRq.

dmesg | tail doesn't show anything drm related, but I didn't use debug param when modprobing drm. When I try debug=15 every lock up is hard one and I can not ssh to machine nor SysRq anymore.

Based on 3 cases, last line of /var/log/Xorg.0.log seems to be:
exaCopyDirty: Pending damage region empty!

One idea I've got on IRC was:
<suokko> zajec: Sounds like possible gpu hang so best info would be what did the latest cmdbuf include
but don't know how to get that cmdbuf.

Comment 1 Rafał Miłecki 2009-08-21 04:36:59 UTC

One more lock up and I noticed my dmesg was full of:
[drm] wait idle failed status : 0xA0003030 0x00000003
[drm] wait idle failed status : 0xA0003030 0x00000003
[drm] wait idle failed status : 0xA0003030 0x00000003
this time.

It was when using original mesa r600 driver with 4 additional fprintf, but I don't think this could cause that messages, right?

Comment 2 Rafał Miłecki 2009-08-21 04:54:35 UTC

I feel it's much harder to lock up my RV620 after adding 4 fprintf into radeon_common.c flushing function. Some race with EXA maybe?

Also I remember similar problem with Xv when I was using mesa/drm's r6xx-r7xx-support branch. Sometimes starting video caused lock up. That was fixed in mainline (doesn't happen in 2.6.31-rcX anymore). I think the fixing commit was:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4247ca942a16745da3d09c58996b276d02655a72
Can this be the same issue, just about 3D this time?

Comment 3 Rafał Miłecki 2009-08-24 00:52:33 UTC

Uncommenting dump_cmdbuf(cs) in:
r600_cmdbuf.c:r600_cs_emit(struct radeon_cs *cs)
cause I can not lock up machine anymore. I've run over routine of starting&quitting morph3d 2000 times.

Have no idea how can this be fixed without debugging driver :|

Comment 4 Pauli 2009-08-24 02:01:24 UTC

You have drm lock lockup because debug output is coming from inside drm lock which is writen toterminal thattries to acquire drm lock for text rendering.

So you have to redirect debug output to a file in DRI1 mode.

Comment 5 Rafał Miłecki 2009-08-24 04:53:02 UTC

(In reply to comment #4)
> You have drm lock lockup because debug output is coming from inside drm lock
> which is writen toterminal thattries to acquire drm lock for text rendering.
> 
> So you have to redirect debug output to a file in DRI1 mode.

Er, I didn't write about any lock up with debugging enabled, did I?

I tested two cases:
1) Unmodified r600 driver, it locks up my machine easily
2) Modified r600 (uncommented dump_cmdbuf), starting morph3d 2000 times (with redirected stderr) doesn't lock up

I use following loop:
  $demos/$app 2> /home/zajec/tmp/mesa.log.$x &
  sleep 4s
  killall $app
  sleep 1s

Comment 6 Rafał Miłecki 2009-08-24 04:55:25 UTC

Ah, I was told on IRC that slowing down driver (by enabling debugging == enabling printing sth to stderr) can avoid locking up. That's probably the case.

Comment 7 Andreas Boll 2012-11-02 16:10:04 UTC

Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

Comment 8 Andreas Boll 2014-07-07 15:57:41 UTC

The classic r600 driver has been abandoned long ago.
It was replaced by the Gallium driver r600g.

If you have issues with r600g please file a new bug report with component Drivers/Gallium/r600

Thanks.

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.