http://bugs.freedesktop.org/show_bug.cgi?id=23436
Pauli suok...@gmail.com changed:
What|Removed |Added
Component|Drivers/DRI/Radeon |Drivers/DRI/R600
--
http://bugs.freedesktop.org/show_bug.cgi?id=23436
--- Comment #3 from Rafał Miłecki zaj...@gmail.com 2009-08-24 00:52:33 PST
---
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
http://bugs.freedesktop.org/show_bug.cgi?id=23436
--- Comment #4 from Pauli suok...@gmail.com 2009-08-24 02:01:24 PST ---
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
http://bugs.freedesktop.org/show_bug.cgi?id=23436
--- Comment #5 from Rafał Miłecki zaj...@gmail.com 2009-08-24 04:53:02 PST
---
(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
http://bugs.freedesktop.org/show_bug.cgi?id=23436
--- Comment #6 from Rafał Miłecki zaj...@gmail.com 2009-08-24 04:55:25 PST
---
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.
--
http://bugs.freedesktop.org/show_bug.cgi?id=23436
--- Comment #1 from Rafał Miłecki zaj...@gmail.com 2009-08-21 04:36:59 PST
---
One more lock up and I noticed my dmesg was full of:
[drm] wait idle failed status : 0xA0003030 0x0003
[drm] wait idle failed status : 0xA0003030 0x0003
http://bugs.freedesktop.org/show_bug.cgi?id=23436
--- Comment #2 from Rafał Miłecki zaj...@gmail.com 2009-08-21 04:54:35 PST
---
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
