Sometimes X locks up when I start it. It kills the radeon chip (bios post code needed to get the panel running again) and doesn't respond to the keyboard. It also consumes 100% cpu, all in user space. The log is full of: (EE) RADEON(0): Idle timed out, resetting engine...
Created attachment 3731 [details] xorg.conf
Created attachment 3732 [details] Xorg.log
Created attachment 3793 [details] opreport -l
Created attachment 3794 [details] opreport -c
This bug has been also reported in the debian bug database: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346486 If you follow the link there is also a backtrace and some workarounds. This is debian sarge running 6.9.0.dfsg.1-4. I just installed the original tarball 6.9. The error is also in the original tree.
Are you still experiencing this bug using a more current version of xorg?
No, haven't seen it for some time now.
I'm closing this one, if you start to experience the problem again, please reopen.
Created attachment 17025 [details] Xorg.4.log I see this bug on git master when running compiz and either starting a new window or resizing a window. Doesn't happen when moving a window around. lspci says: 00:08.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) The last messages are loads of the following, requiring a hard reset. (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -22 (EE) RADEON(0): Idle timed out, resetting engine... I added a return statement into RADEONWaitForIdle so the machine doesn't lock up anymore, but the timout message is of course still there. whot@hyena:~/X11R7/driver/xf86-video-ati$> git diff diff --git a/src/radeon_commonfuncs.c b/src/radeon_commonfuncs.c index 58fe306..dbdaaf5 100644 --- a/src/radeon_commonfuncs.c +++ b/src/radeon_commonfuncs.c @@ -705,6 +705,7 @@ void FUNC_NAME(RADEONWaitForIdle)(ScrnInfoPtr pScrn) xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "Idle timed out, resetting engine...\n"); + return; RADEONEngineReset(pScrn); RADEONEngineRestore(pScrn);
Reopening bug, I see this timeout error on git master.
(In reply to comment #9) > I added a return statement into RADEONWaitForIdle so the machine doesn't lock > up anymore, but the timout message is of course still there. You're saying this change keeps things working despite the timeout messages? If so, the timeout is probably just too short and needs to be extended. Ideally, something like radeon_init_timeout()/radeon_timedout() should be used, to make the actual timeout duration independent of how quickly the various loops are processed. At any rate, this report originally talked about server startup, so you shouldn't have reopened it but created a new report.
On Tue, Jun 10, 2008 at 01:42:19AM -0700, bugzilla-daemon@freedesktop.org wrote: > --- Comment #11 from Michel Dänzer <michel@tungstengraphics.com> 2008-06-10 01:42:15 PST --- > (In reply to comment #9) > > I added a return statement into RADEONWaitForIdle so the machine doesn't lock > > up anymore, but the timout message is of course still there. > > You're saying this change keeps things working despite the timeout messages? If > so, the timeout is probably just too short and needs to be extended. yes, seems to work fine. I multipled the timeout by 100, but still ran into the issue, so I figured I'd file a bug instead. > Ideally, something like radeon_init_timeout()/radeon_timedout() should be > used, to make the actual timeout duration independent of how quickly the > various loops are processed. > > At any rate, this report originally talked about server startup, so you > shouldn't have reopened it but created a new report. k, I'll move it to a new one.
Restoring FIXED resolution, new bug reported as 16292.
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.