As reported in another thread, Supreme Commander's graphic display slows considerably (<1 FPS), and if run in a terminal session a large number of lines are show in the terminal, but one line in particular is interesting to the poster:
Additionally, I am using a GeForce 7600GS card with the latest drivers (180.60, I believe - I'm not in front of it right now, but it's definitely the latest) The error itself is:
Code: err:ntdll:RtlpWaitForCriticalSection section 0x7e114810 "d3d9_main.c: d3d9_cs" wait timed out in thread 001f, blocked by 0009, retrying (60 sec)
This appears to be a revisit of the deadlocking issue as reported in bug 14746, but according to another triage person, this is not so. I would like to know if code has been moved from x11drv.c to d3d9_main.c that would cause this error and for the framerate to drop considerably.
Thank you.
James McKenzie
2009/6/6 James McKenzie jjmckenzie51@earthlink.net:
This appears to be a revisit of the deadlocking issue as reported in bug 14746, but according to another triage person, this is not so. I would like to know if code has been moved from x11drv.c to d3d9_main.c that would cause this error and for the framerate to drop considerably.
It's at least a different critical section. The logs from bug 14746 aren't a whole lot of help, but my guess is that the "deadlock" occurs because thread 0009 dies with the x11drv critical section held. You'll see the RtlpWaitForCriticalSection() ERR anytime a wait on a critical section takes unreasonably long, this does not by itself indicate the bug is a duplicate. (Or a deadlock, for that matter. The code could just take very long to execute.)
As for solving the bug, if it's a deadlock, the main things you need are a +tid,+d3d9 log and the output of "bt all" at the moment the application is deadlocked. It's simplifies things if those are both from the same run.
-
Henri Verbeet -
James McKenzie