Difference between revisions of "Talk:R300"

From ThinkWiki
Jump to: navigation, search
Line 8: Line 8:
  
 
== X lockups after a couple of seconds ==
 
== X lockups after a couple of seconds ==
----
 
  
 
I have an T41p and I tried the r300 driver, using Xorg 6.9.0.dfsg.1-4 and libgl1-mesa-dri version 6.4.1-0.3, both from debian unstable, on a 2.6.15 kernel. It starts nicely, and 3D acceleration seems to be enabled, but the system freezes after a few seconds after X started up. I used the settings as described on this page. Any idea what to look for? --[[User:Nomeata|Nomeata]] 21:03, 21 February 2006 (CET)
 
I have an T41p and I tried the r300 driver, using Xorg 6.9.0.dfsg.1-4 and libgl1-mesa-dri version 6.4.1-0.3, both from debian unstable, on a 2.6.15 kernel. It starts nicely, and 3D acceleration seems to be enabled, but the system freezes after a few seconds after X started up. I used the settings as described on this page. Any idea what to look for? --[[User:Nomeata|Nomeata]] 21:03, 21 February 2006 (CET)

Revision as of 19:40, 12 April 2006

Is this relevant also to the ATI Mobility Radeon X300?

--Thinker 13:30, 8 Dec 2005 (CET)

Somewhat. As far as I know, pcie support is still broken with r300, so while in theory the x300 should be supported, it doesn't seem like that's the case at the moment.


X lockups after a couple of seconds

I have an T41p and I tried the r300 driver, using Xorg 6.9.0.dfsg.1-4 and libgl1-mesa-dri version 6.4.1-0.3, both from debian unstable, on a 2.6.15 kernel. It starts nicely, and 3D acceleration seems to be enabled, but the system freezes after a few seconds after X started up. I used the settings as described on this page. Any idea what to look for? --Nomeata 21:03, 21 February 2006 (CET)


I have the same problem on an R52 with debian testing/unstable (Xorg 6.9.0.dfsg.1-6, libgl1-mesa-dri 6.4.1-0.4). Kernel is 2.6.16. The system is still usable over ssh, but trying to terminate the server freezes it completely (not even SysRq works). Server kill (Signal 9) works, but doesn't restore the console. strace over ssh shows me that the Xorg process is still responding to mouse movements (lots of select()s, read()s, gettimeofday()s) but it always tries to

ioctl(9, 0x6444, 0)

which returns with code -1, errno is EBUSY (Device or resource busy). File descriptor 9 refers to /dev/dri/card0.

This seems to be an endless loop, maybe a race condition in the X server / r300 driver? I couldn't figure out what ioctl 0x6444 is.

Hope this helps somebody more familiar with the X internals solve this problem. Guess I'll post a bug report to X.org, too.

-- acolomb 2006-04-12 20:28 CEDT