Bug 208891 - r300 does not work with 4GB on Intel x86_64
r300 does not work with 4GB on Intel x86_64
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Airlie
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-10-02 11:00 EDT by Adam Goode
Modified: 2008-02-09 04:19 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-09 04:19:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg log (46.72 KB, text/plain)
2006-10-02 11:02 EDT, Adam Goode
no flags Details
xorg.conf (562 bytes, text/plain)
2006-10-02 11:02 EDT, Adam Goode
no flags Details

  None (edit)
Description Adam Goode 2006-10-02 11:00:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20060913 Fedora/ Firefox/ 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):

How reproducible:

Steps to Reproduce:
1. Modify xorg.conf to have Driver "radeon"
2. Start X

Actual Results:
Black screen
X process takes 100% CPU, becomes unkillable

Expected Results:

Additional info:
Comment 1 Adam Goode 2006-10-02 11:02:21 EDT
Created attachment 137550 [details]
Xorg log
Comment 2 Adam Goode 2006-10-02 11:02:39 EDT
Created attachment 137551 [details]
Comment 3 Adam Goode 2007-05-03 20:36:15 EDT
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" ?
Comment 4 Adam Goode 2007-06-05 22:21:39 EDT
Fixed upstream in 2.6.22-rc4.
Comment 5 Adam Goode 2008-01-22 21:28:58 EST
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.

Comment 6 Adam Goode 2008-02-04 14:54:55 EST
Still broken in latest rawhide kernel-2.6.24-9.fc9.
Comment 7 Dave Airlie 2008-02-05 22:53:19 EST
any ideas when it started to break... sounds like we are going to have to bisect
the kernel to find this ... uggh....
Comment 8 Adam Goode 2008-02-05 23:00:04 EST
Not sure exactly, F8 was working, when I switched to rawhide it broke. So
somewhere between kernel- and kernel-2.6.24-0.157.rc8.fc9 ??

I'll give bisect a go, I guess.
Comment 9 Adam Goode 2008-02-05 23:36:16 EST
Ug, rawhide has gcc 4.3, which the kernel doesn't like...
Comment 10 Dave Airlie 2008-02-07 19:46:18 EST
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...
Comment 11 Adam Goode 2008-02-09 04:19:11 EST
Working great with kernel- !

Note You need to log in before you can comment on or make changes to this bug.