Description of Problem: If I logout of GNOME the resulting GDM screen is badly corrupted. The mouse and keyboard are both still active but I can't see the login window properly. Version-Release number of selected component (if applicable): XFree86-4.2.0-6.52 How Reproducible: every time Steps to Reproduce: 1. login to GNOME 2. logout 3. Actual Results: screen corruption Expected Results: gdm screen appears normally Additional Information: Dell Latitude C800 with ATI Rage Mobility M4
Created attachment 52885 [details] X log file
Created attachment 52886 [details] X config file
There are lots of messages like this in the syslog: kernel: [drm:r128_cce_indirect] *ERROR* process 1978 using buffer owned by 0
Please attach your syslog messages file from the start of kernel boot up to and including these errors.
Could this be because your confir specifies 1400X1050 as the resolution of your "Monitor" while "Screen" has the diferent choices. As a matter of fact I've seen a lot of strange problems (reported here earlier) on Dell C800 at the resolutions other than 1400x1050 (that is Dewll-recommended). What will happen if you specify "1400x1050" as the only one available in "Screen" section of your config?
Created attachment 54325 [details] syslog as requested
In the past I've tried to use 1400x1050 but it has never worked. If I do put that in the screen section I will get 1600x1200 instead.
I know whats wrong ... I have the same laptop and the problem is caused by dma not being enabled .... here is the fix (from dri.sourceforge.net) troubleshoooting guide ... PS: 3d accelleration will not work until you reduce resolution to 1024X768 at 16 bits .... once you do though your graphichs performance will double. Anyhow heres the fix ... i have put the relevant part into an init script that starts at runlevel 3 ... gdm kicks in at runlevel 5 9.1 Bus Mastering DMA-based DRI drivers (that's most DRI drivers) cannot function unless bus mastering is enabled for your graphics card. By default, some systems don't having bus mastering on. You should enable it in your BIOS. Alternately, you can check the status of bus mastering and change the setting from within Linux. There may be similar procedures for other operating systems. Run lspci (as root) and find the information describing your graphics adapter. For example: 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:11.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) 00:12.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c895 (rev 02) 00:14.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 08) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc.: Unknown device 0009 (rev 01) The bus, device, and function number comprise the device id, which is conventionally written in the form bus:dev.func, or in this case 01:00.0. Use the setpci command to examine bit two of register 4 for your graphics card. This will indicate whether or not bus mastering is enabled. setpci -s 01:00.0 4.w A hexadecimal value will be printed. Convert the least significant digit to binary. For example, if you see 3, that's 0011 in binary (bit two is 0). If you see 7, that's 0111 in binary (bit two is 1). In the first example, bus mastering is disabled. It's enabled in the second example. The following shell script will enabled bus mastering for your graphics card and host bridge. Run it as root. #!/bin/bash dev=01:00.0 # change as appropriate echo Enabling bus mastering on device $dev setpci -s $dev 4.w=$(printf %x $((0x$(setpci -s $dev 4.w)|4))) dev=00:00.0 echo Enabling bus mastering on host bridge $dev setpci -s $dev 4.w=$(printf %x $((0x$(setpci -s $dev 4.w)|4))) You can check if this worked by running the first setpci command again.
I am having a similar problem on a desktop with a ATI Rage 128 RF/SG AGP video card (32MB video RAM). The system is a PIII SMP (running the UP kernel makes no difference). I have tried skipjack-2 with both no errata applied and with all errata applied ... makes no difference. It does NOT happen every time but does most of the time. It does not matter if I log out of gnome or kde. A ctrl-alt-backspace corrects the screen.
Well, it is not gdm related ... kdm suffers the same problem.
Yes, this is the same problem -- I found the error message in /var/log/messages: kernel: [drm:r128_cce_indirect] *ERROR* process 1204 using buffer owned by 0
So do you find forcing bus mastering on does actually solve the problem? If so, I can investigate having the video driver do this itself.
When I upgraded to the final 7.3 release, the problem got a lot better. I can now switch from X to the console and back without hanging the system. However, I do get occasional display crashes when using Xine and/or mplayer.
Does "a lot better" mean that the problem no longer occurs and you do not see gdm login corruption? xine/mplayer issues should be filed in separate bug reports as that would be considered a separate problem.
It means that I haven't seen the problem since installing 7.3
Ok, beauty. Thats what I needed to know. ;o) Thanks for the update. Closing as fixed in RHL 7.3 (CURRENTRELEASE)