Hardware: Dell Inspiron 4100, Mobile Pentium III-M 1.0 GHz, Intel 830MP chipset
ATI Radeon Mobility LY (AGP), 16 Mb RAM
Software: SuSE 7.3, kernel 2.4.16 with devfs, XFree86-4.2.0 (WithPam and
WithPamMisc), management by xdm.
agpgart.o has two patches, see URL below for details.
Symlinks point to libGL.so, libGLcore.a and libglx.a from XFree86-4.2.0.
XF86Config excerpt (see URL below for the whole thing):
Section "Module"
Load "glx"
Load "dri"
Section "Device"
Driver "radeon"
Option "AGPMode" "4" (failure happens with or without 4X AGP)
Section "DRI"
Mode 0666
Reference: http://www.math.ucla.edu/~jimc/insp4100/X-setup.html#DRI
Complete XFree86.0.log available on request.
OpenGL applications successfully use DRI, e.g. glxgears gets 628 fps vs.
220 fps without DRI. I added /dev/dri/card0 to /etc/logindevperm, so xdm
would chown-chmod the device to $USER 600 at login, and root 600 when the
session ends. Users can log in, but when they log out the system
freezes: the screen goes black, you can't switch VTs, and the Magic SysRq
Key has no effect. The failure occurs if and only if that line is present
in /etc/logindevperm.
Having removed the line, I went through the following operations:
1. Check /dev/dri/card0, it's root 666.
2. User logs in using xdm. Still root 666.
3. User runs glxgears. It uses DRI.
4. Switch VTs, chown otheruser /dev/dri/card0, chmod 600 /dev/dri/card0.
5. Change mind, chown root /dev/dri/card0 (no second chmod)
6. Switch Vts, user runs glxgears again. Reports "operation not
permitted, using slow indirect rendering" and runs at 230 fps.
7. Switch VTs, check /dev/dri/card0. IT'S NOT THERE! radeon kernel
module is still loaded and has the same access count. Remember this
is in devfs.
8. Used the Magic SysRq Key to sync, remount and reboot.
I cannot recognize any relevant messages in syslog or in XFree86.0.log.
There is one difference in XFree86.0.log between the one covering the
above trial and an instance where the bug was not provoked: in the
trial, after the usual report about mouse buttons which normally occurs
at the end, it [drm] removed 1 reserved context for kernel, unmapped
SAREA. Then it opened the DRI device again, seemingly identical to the
first time, and [drm] created radeon driver again with identical
reservations. It isn't possible to tell what happened when, but the mod
date of the file was shortly before I rebooted the machine, not when the
server started up.
James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: [EMAIL PROTECTED] http://www.math.ucla.edu/~jimc (q.v. for PGP key)
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
