Difference between revisions of "Talk:R300"
m (→Fedora) |
|||
(7 intermediate revisions by 3 users not shown) | |||
Line 5: | Line 5: | ||
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. | 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? --[[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) | ||
+ | |||
+ | |||
+ | 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 | ||
+ | |||
+ | {{cmdresult|ioctl(9, 0x6444, 0)}} | ||
+ | |||
+ | which returns with code -1, errno is EBUSY (Device or resource busy). File descriptor 9 refers to {{path|/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 | ||
+ | |||
+ | Update: It now works fine. libgl1-mesa-dri 6.4.1-0.4, xserver-xorg-video-ati 6.5.8.0-1, kernel 2.6.16. --[[User:Nomeata|Nomeata]] 23:18, 17 May 2006 (CEST) | ||
+ | |||
+ | == Fedora == | ||
+ | |||
+ | Did anyone get 3D acceleration working in a Fedora Core 5 system? I had to upgrade all X-related components to resolve various warnings and errors. Eventually I ended up with the latest xorg-x11-server-Xorg, xorg-x11-drv-ati and libdrm RPMs from Fedora development, latest Mesa CVS, and kernel 2.6.17-rc6-git5; at this point glxgears crashes the X server. | ||
+ | |||
+ | --[[User:Thinker|Thinker]] 03:24, 14 June 2006 (CEST) | ||
+ | ---- |
Latest revision as of 18:54, 14 June 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
Update: It now works fine. libgl1-mesa-dri 6.4.1-0.4, xserver-xorg-video-ati 6.5.8.0-1, kernel 2.6.16. --Nomeata 23:18, 17 May 2006 (CEST)
Fedora
Did anyone get 3D acceleration working in a Fedora Core 5 system? I had to upgrade all X-related components to resolve various warnings and errors. Eventually I ended up with the latest xorg-x11-server-Xorg, xorg-x11-drv-ati and libdrm RPMs from Fedora development, latest Mesa CVS, and kernel 2.6.17-rc6-git5; at this point glxgears crashes the X server.
--Thinker 03:24, 14 June 2006 (CEST)