Reproducible with earlier versions?
This problem is reproducible on my machine with latest CVS/GIT versions of Mesa,
X.org and DRM.
Reverting Mesa to CVS as of 2006-04-05 fixes the ppracer hang, but the hangs
persist with other applications (Google Earth).
Does the lockup happen always at the same time ?
At least roughly so, but I'm not sure it's exactly the same frame.
Created attachment 6030 [details]
r300 initialization voodoo
Please try launching this program before X
(go to console stop X, launch the program, rerun X)
then try if you still see lockup. You will have to
edit the source to modify #define ADDR youaddress
where your address is given by lspci -v
then second line of memory at ie:
0000:01:00.1 Display controller: ATI Technologies Inc RV350 NJ [Radeon 9800 XT]
Subsystem: Micro-Star International Co., Ltd.: Unknown device 9561
Flags: bus master, stepping, 66MHz, medium devsel, latency 64
Memory at e8000000 (32-bit, prefetchable) [size=128M]
Memory at fe9e0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: <available only to root>
then gcc r300init.c -o initr300
./initr300 (as root)
Should I feed the getchar() calls?
If I do so from textmode, I get this:
RD error 0x0000001F get 0x00000013
RD error 0x151557FF get 0x1515577F
RD error 0x151557FF get 0x1515577F
Textmode is corrupted, and running X gives a corrupted display and a hang.
01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Radeon Mobility
M300] (prog-if 00 [VGA])
Subsystem: IBM Unknown device 056e
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at c0000000 (32-bit, prefetchable) [size=128M]
I/O ports at 3000 [size=256]
Memory at b0100000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at b0120000 [disabled] [size=128K]
Capabilities:  Power Management version 2
Capabilities:  Express Endpoint IRQ 0
Capabilities:  Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Capabilities:  Advanced Error Reporting
ADDR set to 0xb0100000.
Could you comment out code btw S01 & S02 and see if this work.
Try also commenting out code up to S05
Commenting out the coe between the "S 01" and "S 02" printfs still corrupts
textmode and X.
With "S 01" through "S 05" comment out there is no corruption, but things
behaves the same as not running initr300t: ppracer hangs with current Mesa CVS
but not with CVS 2006-04-05, and googleearth hangs even with CVS 2006-04-05.
BTW, I ran initr300 after loading the radeon DRM module (from textmode).
Do you have page flipping enabled? If you have, disable it and see if it
All of my reports are with the default EnablePageFlip = off.
Created attachment 6047 [details]
R300 dynamic clock initialization
Could you try this one, like the other change the addr at top of file to
reflect your addr. This sime you can launch it without leaving X but launch it
with no application running and do sync before and as root.
Or you may try the lastest radeon driver in git (the same fix goes in few hour
ppracer still crashes. with the latest CVS/GIT versions of Mesa+DRM+X.org,
(including the "radeon: force CP and VIP clocks on some r300 and rv100 chips"
change to xf86-video-ati).
BTW, the crash is not fully deterministic. Here, if I pick the first ppracer
practice track and let it run without touching anything, the crash varies
between 10 to 12 seconds into the game.
Could you attach your xorg.conf and one Xorg.0.log to the bug please. Did you
try running one Xorg server with fglrx first and then another one with open
driver althought in your case this doesn't seems to help we might miss another
Created attachment 6056 [details]
Log for a minimal X session with a ppracer hang.
Using current CVS/GIT of Mesa, DRM and X.org. Ignore the fact that X is on :1
instead of :0. This is the first instance of X invoked since reboot.
Created attachment 6057 [details]
xorg.conf for above log.
Log and xorg.conf attached.
I don't have a working fglrx installation at the moment.
Try with fglrx and check your card temperature. I had a bad surprise when i
found out that after i runned the first r300init lockups remains even with fglrx
and Windows. Further investigation pointed out that r300init modified some
memory timings parameters. Those very aggressive parameters mistreated the AGP
stuff of my MB ( an A7N8X ) and then my second MB ( an A7N8X-E D ). And that
distorded MB mistreated my second GC ( another 9800 Pro ). Result : 2 MB and 2
GC almost dead, unusable ( artifacts , no 3D, crash after 30 minutes even in 2D ).
Could you try disabling AIGLX Option “AIGLX” “false” in ServerLayout section. Is
there anythings after a lockup in your kernel log file (grep for drm), you might
need to mount your partition with sync option in order to get interesting log.
The ppracer hangs persists when r300 is loaded after fglrx without reboot.
Moreover, r300's 3D rendering is now corrupted (see attachment). The laptop's
fan doesn't speed up, so if there is overheating it's too brief to be detected.
Running today's CVS/GIT of Mesa/X.org/DRM, with Option "AIGLX" "false".
ppracer runs fine with fglrx 2.25.18, BTW.
A couple of suggestions:
1. ppracer ran OK in Mesa CVS 2006-04-05. You can try to isolate the change
2. If you think it's a clocks issue, you may want to see what fglrx's "aticonfig
--set-power-state" does, it might re-init the relevant registers.
Created attachment 6060 [details]
Badly rendered glxgears (for comment 19).
The last buildable Mesa CVS on which ppracer runs well is 2006-04-07.
The first buildable Mesa CVS demonstrating the hangup is 2006-05-03.
Inbetween these dates I can't build Mesa CVS:
../common/dri_util.c: In function ‘driCreateNewDrawable’:
../common/dri_util.c:634: error: ‘__DRIdrawable’ has no member named ‘copySubBuffer’
Running with -dumbSched and 'Option "Silkenmouse" "false"' makes no difference.
Could you try ppracer with disabling fog, one of the change
btw the two version is fog. If this doesn't do anythings try
launching ppracer with setting R300_SPAN_DISABLE_LOCKING
environement variable to 1.
No change with fog disabled or R300_SPAN_DISABLE_LOCKING=1, it still hangs
BTW, note the link to bug 7371. With the old non-crashing version I also got the
The hang is indeed triggered by rendering of the snow tracks, as suggested in
bug 7371. The hangs go away when I set "set track_marks false" in
~/.ppracer/options, and come back when I flip it to "true".
Does this help in isolating the DRI bug?
(In reply to comment #24)
> The hang is indeed triggered by rendering of the snow tracks, as suggested in
> bug 7371. The hangs go away when I set "set track_marks false" in
> ~/.ppracer/options, and come back when I flip it to "true".
> Does this help in isolating the DRI bug?
Should be fixed in CVS now. Please reopen if not.
(In reply to comment #20)
> Created an attachment (id=6060) 
> Badly rendered glxgears (for comment 19).
I recall this happens if color tiling is not enabled.
Doesn't seem worth while tracking down IMHO.
Current CVS fixes the ppracer hang on my box.
Also, either this or some other recent commit solved the Google Earth hang.
Mass version move, cvs -> git