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.
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?
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?
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 :|
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.
(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
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.
Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel?
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.