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