Red Hat Bugzilla – Bug 208891
r300 does not work with 4GB on Intel x86_64
Last modified: 2008-02-09 04:19:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/20060913 Fedora/22.214.171.124-1.fc5 Firefox/126.96.36.199 pango-text
Description of problem:
When I start X on my Dell Precision 380 with PCIE FireGL V3100 (ATI Technologies Inc RV370 5B64 [FireGL V3100 (PCIE)] (rev 80)), X displays a black screen and uses 100% of CPU. X does not respond to kill -9.
I suspect DRI is at fault, but until #207614 is resolved, I can't test without DRI.
The only working solution is VESA driver.
Before I upgraded from FC5, I remember that a later xorg-x11-drv-ati release exhibited the same effects until I commented out 'Load "dri"'.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Modify xorg.conf to have Driver "radeon"
2. Start X
X process takes 100% CPU, becomes unkillable
Created attachment 137550 [details]
Created attachment 137551 [details]
Tracked at freedesktop here:
Basically, Dave Airlie on IRC helped out a lot by poking through the code, then
he realized the existing code is doing completely the wrong thing wrt DMA and
cache coherency. It's triggered by swiotlb on Intel. I think the solution
involved "a lot of work" ?
Fixed upstream in 2.6.22-rc4.
This bug appears to have returned in rawhide.
Same symptoms, same solution, same "failed writeback test" when radeon.ko loads.
One notable difference, instead of stopping at a blank screen, it stops at a
screen filled with seemingly uninitialized garbage. The mouse pointer responds,
but nothing else.
Still broken in latest rawhide kernel-2.6.24-9.fc9.
any ideas when it started to break... sounds like we are going to have to bisect
the kernel to find this ... uggh....
Not sure exactly, F8 was working, when I switched to rawhide it broke. So
somewhere between kernel-188.8.131.52-85.fc8 and kernel-2.6.24-0.157.rc8.fc9 ??
I'll give bisect a go, I guess.
Ug, rawhide has gcc 4.3, which the kernel doesn't like...
I think we have a fix for this which I've just put in upstream, so hopefully the
next F8 stable and F9 kernels will solve this problem...
Working great with kernel-184.108.40.206-26.fc9.x86_64 !