Description of problem: Recently machine began locking up hard after being up for a few hours. Tried older kernel to no avail. Now I'm suspecting the ati driver in updates-testing. I've gone back to the driver from FC5 release and am trying that. Version-Release number of selected component (if applicable): 6.5.8.0-1
Created attachment 128632 [details] Xorg log from 6.5.8.0 driver, no rhgb.
Created attachment 128633 [details] Xorg log from stock FC5 driver, just X restart
'ati' is just a wrapper attempting to guess which driver really to use and it was strongly suggested in the past that using the "real" one instead ('r128', 'radeon', ... ) which fits your video is really preferable. OTOH fairly recently https://bugs.freedesktop.org/show_bug.cgi?id=5781 was closed "due to the lack of activity". Related?
(In reply to comment #3) > 'ati' is just a wrapper attempting to guess which driver really to use This part is fairly accurate, in particular the "attempting" part, because it does not actually work properly all the time and absolutely can not be relied upon. > and it was strongly suggested in the past that using the "real" one instead > ('r128', 'radeon', ... ) which fits your video is really preferable. There are still some people out there who recommend using the "ati" wrapper for purist reasons, however as you state here, using the specific driver is actually the correct thing to do. The "ati" wrapper is another unnecessary layer of code that is not well maintained, and so does not always know about various hardware that the actual real driver does know about. So, just for the record for everyone reading this, I'll go one step further than just agreeing with you here, and actually state that using the "r128" driver for Rage 128 hardware, and the "radeon" driver for Radeon and FireGL hardware is the officially correct and only recommended way to configure ATI hardware. Mach64 hardware can be configured to use either "ati" or "atimisc" as that hasn't changed in ages. In the future, the "ati" wrapper might be removed from X.Org, although upstream hasn't yet committed to doing that yet, but it is very likely. HTH
Created attachment 128663 [details] Diff between 6.5.7 and 6.5.8 Xorg logs Okay, changed xorg.conf to use "radeon". Still have lockup with 6.5.8 and am back on 6.5.7 now. I'm attaching a diff of the 6.5.7 and 6.5.8 Xorg.0.log files. This is full boot for each with no rhgb. Also think I may be seeing similar problem with a ATI Radeon VE/7000 QY card. System hung starting up the rhgb server. Could move the cursor, but was stuck at the blank screen and X cursor.
Have you tried using a lower Depth so that DRI could be enabled? Also, that RHGB hang might be due to a kernel bug (#190575). Have you tried updating to the 2.6.16-1.2111 kernel?
(In reply to comment #6) > Have you tried using a lower Depth so that DRI could be enabled? Yes, it dri works with a lower depth, but I'm not really interested in that. I suppose I could see if I have the hang at lower depth and dri enabled. I'll see. > Also, that RHGB hang might be due to a kernel bug (#190575). Have you tried > updating to the 2.6.16-1.2111 kernel? Yeah, the rhgb issue was definitly the kernel, sorry for the noise.
Created attachment 129272 [details] xorg.conf with dual monitors configured
Created attachment 129273 [details] log file
If this issue turns out to still be reproduceable in the latest updates for this Fedora Core release, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates. Setting status to "NEEDINFO_REPORTER", and awaiting upstream bug report URL for tracking. Thanks in advance.
My system: IBM ThinkPad T30 with Radeon 7500 and 1400x1050 internal LCD, connected to external 1600x1200 VGA LCD. This system has been working reliably for months with FC3, in dual-head mode. Updated to FC5 and found that baseline configuration no longer supported dual-head mode. Per advice at http://www.redhat.com/archives/rhl-list/2006-May/msg02069.html I too updated my ATI driver to xorg-x11-drv-ati-6.5.8.0-1.i386.rpm. Other than this module my system is 100% 'up- to-date' per PUP. Symptoms: Boots correctly into dual-head mode (no problems with rhgb). Seems to run fine for a while, but eventually crashes. Complete hang - can't even SSH into it. Note, one reliable way to hang it is to enter XScreenSaver 4.24 Preferences and click the "Mode" drop- down list (which seems to default to "Random Screen Saver"). The 5-element list displays and the system is immediately frozen. SSH remote access is dead too.
Note, per FreeDesktop bug 7019, the hang may be related to 24 bit mode. I switched both monitors to 16 bit mode and the reliable crash (XScreenSaver 4.24 Preferences) is *resolved*.
Andrew - In 24 bit mode, is DRI disabled? Search for "Direct rendering disabled" in the Xorg log. Just curious to see if that is a common factor here.
It looks like DRI is disabling itself on my machine for two different reasons. Here are the modes I tested. 16 bpp, single head: DRI enabled 24 bpp, single head: DRI disabled: (EE) RADEON(0): Static buffer allocation failed. Disabling DRI. (EE) RADEON(0): At least 17325 kB of video memory needed at this resolution and depth. (**) RADEON(0): RADEONInitMemoryMap() : (**) RADEON(0): mem_size : 0x01000000 (**) RADEON(0): agp_size : 0x0a1b41f0 (**) RADEON(0): agp_base : 0x0a1b41f0 (**) RADEON(0): MC_FB_LOCATION : 0xe8ffe800 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 16 or 24 bpp, dual head: DRI Disabled: (WW) RADEON(0): Direct Rendering Disabled -- Dual-head configuration is not working with DRI at present. Please use the radeon MergedFB option if you want Dual-head with DRI. I don't have any experience with MergedFB and I haven't tried that configuration. Should I?
6.5.8.0 hit updates. Now my machine locks up regardless of color depth/DRI. Gone back to 6.5.7.3-4. Interestingly, it ran better last time in 24bit/no DRI (lasted over 24 hours, rather than 8 minutes in 16bit/DRI. Anthing I can do to debug?
So far having better luck with 2.6.18-1.2189.fc5 and xorg-x11-drv-ati-6.5.8.1-1 (home built).
Also saw problems on IBM X32. Currently running good with 2.6.18-1.2189.fc5 and 6.5.7.3-4. Will try 6.5.8.1 soon.
6.5.8.1 and 2.6.18-1.2189.fc5 works in 16 bit/DRI mode but seems to hang in 24-bit/non-DRI mode on my Inspiron 4150 (Radeon Mobility M7 LW).
Same problem like in the original report here, with IBM R52 laptop (Rage Mobility M300 chip), FC6 with all updates available today. Might be the same problem as #204098
Just experienced with FC6 in 24-bit/non-DRI mode: kernel-2.6.18-1.2798.fc6 xorg-x11-drv-ati-6.6.2-4.fc6 shifting back to 16-bit/DRI...
I have not seen this in a long time running F7 and rawhide.