Bug 7155

Summary:	Mach64 machine freeze with anything but glxgears
Product:	DRI	Reporter:	barthek <gejzer>
Component:	DRM/other	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	high
Version:	XOrg git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description barthek 2006-06-08 09:34:46 UTC

My config is Dell Latitude laptop with:

0000:01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M
AGP 2x (rev 64) (8 mbs ram)

i was successful to build latest (mach64-20060403-linux) snapshot and all the
modules load correctly:

[4294695.889000] Linux agpgart interface v0.101 (c) Dave Jones
[4294695.926000] agpgart: Detected an Intel 440BX Chipset.
[4294695.931000] agpgart: AGP aperture is 64M @ 0xf4000000
[4294730.820000] agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0.
[4294730.820000] agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode
[4294730.820000] agpgart: Putting AGP V2 device at 0000:01:00.0 into 2x mode
...
[4294730.753000] [drm] Initialized drm 1.0.1 20051102
[4294730.817000] [drm] Initialized mach64 1.0.0 20020904 on minor 0: 
[4294730.910000] [drm] descriptor ring: cpu addr d0c00000, bus addr: 0xf4000000
[4294730.910000] [drm] Forcing pseudo-DMA mode
...

the problem is this - the DRI is working, I can run the glxgears OK with
framerate of 180, but when i try to launch anything 'bigger' - be it opengl
screensaver, chromium or penguing racer - I get total machine freeze.
even the tcp/ip stack is not working.

there is nothing (IMHO) in Xfree logfile that would suggest whats wrong.

i am more than happy to provide you with all relevant information that you need :)

best regards,

Comment 1 mitch074 2008-04-30 13:51:44 UTC

Pinging this bug, I have similar hardware IBM Thinkpad with Rage Mobility M1/8Mb (AGP, mach64 core with texel unit); symptoms remain with latest 6.8.0 ati driver, and recent-ish DRM CVS extract, on Ubuntu 7.10 X server (version 1.3.1 if I'm not mistaken).

Basically, as soon as textures are sent to the chip in a 3D context, the system locks hard (sysrq doesn't work either). I managed, only once, to get a correctly rendered Google Earth's first frame (and I could see it once the machine was frozen), so 3D code may still work and the bug could be trivial, but for now it completely blocks 3D on mach64.

Could we at least have a status report, as in, bug will be fixed once the TTM is finalized and mach64 makes use of it?

Comment 2 mitch074 2008-06-12 14:05:55 UTC

Pinging this bug again, new progress:
 - with the X server provided with Xubuntu 8.04, a recent drm.ko compiled from a fresh git extract, the distro-provided 6.8.0 mach64 driver, and 16-bit color depth, there is much less crashes - instead, we have occasional screen corruption and z troubles:
 - Google Earth works most of the time (froze machine once), but windows appearing over the 3D display port disappear in a blink => context priority issue?
 - glxgears performance reached 300 fps (indirect; 110 fps) => not a bug, it's cool :)
 - Xfce's compositing works; however, when a menu is set to appear, the rectangle it will fill contains garbled content (snow, or graphical elements leftover from previously displayed element) => memory addressing troubles?
 - Earth3D didn't display textures; however, that could have been a network error
 - Stellarium worked
 - EXA is generally faster than XAA, except when displaying Flash videos in Firefox (2 or 3): as far as I know, Flash uses blits - well, EXA blits are slow...

In short: I'd say this specific bug may be mostly resolved closed with an X server upgrade, but there still are problems in the mach64 drm module:
 - context priority needs work
 - memory addressing is unsafe (corruption, still occasional system freezes)
 - 32-bit performance, well, sucks... but that may be a hardware limitation.
 - EXA needs some love

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.