Red Hat Bugzilla – Bug 461801
FireGL 4300 not working well in rawhide
Last modified: 2008-12-17 15:35:21 EST
Created attachment 316336 [details]
Description of problem:
Since upgrading to rawhide my system with a FireGL 3400 is not working very well (while my system with a Radeon 9200 continues to work as before).
I am seeing lockups on the order of tens of minutes. This didn't happen in fedora 9 and doesn't appear to be happening while using the vesa driver.
Also my gnome desktop had some weird artifacts that also went away after switching to the vesa driver. Some icons were not shown next to applications in the menu, the background image was not properly fitted to the screen size and the cursor seemed to be able to be able to move below the bottom of the screen.
Version-Release number of selected component (if applicable):
I have tried to stay current (i.e. grabbing new stuff from koji as well as the normal rawhide pushes) and the problem has persisted over the last several days (when i switched to rawhide), but currently i am using:
I can't make lock ups happen on demand, but it is happening pretty often.
The desktop artifacts happen all of the time.
Steps to Reproduce:
I tried xorg-x11-drv-ati-6.9.0-12.fc10.x86_64 long enough to verify the desktop artifacts were still present. I didn't see a lockup but was only using it for a minute or two before switching back to vesa.
Could we get /var/log/Xorg.0.log from starting X with ati driver and without /etc/X11/xorg.conf, please?
Created attachment 316354 [details]
Xorg.0.log file from reboot with no xorg.conf file
I have attached an Xorg.0.log file from a reboot without an xorg.conf file.
While doing this test I did appear to witness an X server crash (at least my LCD display lost signal in the middle of doing stuff).
can you boot with nomodeset on the kernel command line?
I didn't see the request before I left the office. I'll test this tomorrow morning.
Created attachment 316445 [details]
Xorg.0.log from a nomodeset no xorg.conf boot
I don't know about lockups yet, boot using nomodeset did solve the desktop artifacts. Both icons are showing up and the background image is properly scaled.
You new kernel didn't finnish building in time for me to check right now, but I'll try it in a couple of hours.
I tried the 323 kernel since there was a comment about a radeon change.
Without nomodeset the artifacts were still there.
With nomodeset things seem to be normal.
I retested this with xorg-x11-server-common-1.5.0-6.fc10.x86_64 (and related server stuff) and xorg-x11-drv-ati-6.9.0-14.fc10.x86_64. I am still seeing the same behavior. I won't have another chance to test on this machine until Monday.
I retested this with kernel-2.6.27-0.336.rc6.git5.fc10.x86_64 and am still seeing the problem.
Today I am seeing some different behavior (without using nomodeset). The desktop froze after it displayed by background and icons but before I could actually do anything. However the background and icons were displayed normally.
Some versions of potentially relevant packages are:
I have now had a successful boot without nomodeset where I was able to complete a graphical login.
In case it rebreaks later I am currently at:
Why things seem to be a little slow still, I think the stuff covered by this bug are resolved so I'll close it. If things rebreak later I'll reopen it.
In a bit of irony my desktop locked up while firefox was redrawing the web page after I closed this bug. Some places where there was text had what appeared to be random bit maps.
I tried a few more reboots with and without nomodeset set and had some more lockups. In one case running glxgears with a nomodeset boot seemed to cause a lockup. In one case I was able to see that a real shutdown occur after pressing the reset button, so in at least one case the kernel didn't die, just X.
I retested this with kernel-2.6.27-0.393.rc8.git7.fc10.x86_64 and xorg-x11-server-common-1.5.1-5.fc10.x86_64 and had another X crash. The shutdown buttin still worked, so I think the kernel was still running, though I couldn't switch to a vt or restart X using the console keyboard.
I am still seeing X lockups/crashes with modesetting enabled.
I retested this with kernel-2.6.27-13.fc10.x86_64 and xorg-x11-drv-ati-6.9.0-27.fc10.x86_64 and can still get a lockup/crash, though it seems to be getting harder. Running glxgears in one destop and firefox in another and switching back and forth seems to eventually trigger the problem.
I'm seeing similar problems with rawhide on this system:
(ATI Technologies Inc RV370 5B64 [FireGL V3100 (PCIE)])
The mean time between lockups is maybe 3 hours of active use. A statistically
insignificant sample of lockups lead me to believe that it is more likely to
happen when I click the mouse over a button.
The last time X froze, I was able to ssh into the box but I could not kill Xorg,
Xorg's parent process or telinit 3. I haven't tried vesa or nomodeset yet
although I had to use nomodeset during anaconda installation to see the mouse
pointer and fit the screen.
I am going to tentatively close this is today my normal stress tests haven't gotten a lockup in significantly longer than normal. If bad things happen later, I'll reopen it.
Currently I am using:
It worked for me for quite a while, but I'm seeing the same or very similar symptoms again since a recent update. I'm not sure if it's the same bug or a new one.