Bug 461801

Summary: FireGL 4300 not working well in rawhide
Product: [Fedora] Fedora Reporter: Bruno Wolff III <bruno>
Component: xorg-x11-drv-atiAssignee: Dave Airlie <airlied>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: idht4n, jeff, mcepl, xgl-maint
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-20 14:47:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Xorg.0.log
none
Xorg.0.log file from reboot with no xorg.conf file
none
Xorg.0.log from a nomodeset no xorg.conf boot none

Description Bruno Wolff III 2008-09-10 17:36:30 UTC
Created attachment 316336 [details]
Xorg.0.log

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:
xorg-x11-drv-ati-6.9.0-10.fc10.x86_64
kernel-2.6.27-0.321.rc6.fc10.x86_64

How reproducible:
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:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Bruno Wolff III 2008-09-10 19:24:22 UTC
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.

Comment 2 Matěj Cepl 2008-09-10 19:41:40 UTC
Could we get /var/log/Xorg.0.log from starting X with ati driver and without /etc/X11/xorg.conf, please?

Comment 3 Bruno Wolff III 2008-09-10 20:46:02 UTC
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).

Comment 4 Dave Airlie 2008-09-10 22:56:24 UTC
can you boot with nomodeset on the kernel command line?

Comment 5 Bruno Wolff III 2008-09-11 00:04:05 UTC
I didn't see the request before I left the office. I'll test this tomorrow morning.

Comment 6 Bruno Wolff III 2008-09-11 14:24:05 UTC
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.

Comment 7 Bruno Wolff III 2008-09-11 16:44:29 UTC
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.

Comment 8 Bruno Wolff III 2008-09-11 21:09:15 UTC
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.

Comment 9 Bruno Wolff III 2008-09-19 16:42:19 UTC
I retested this with kernel-2.6.27-0.336.rc6.git5.fc10.x86_64 and am still seeing the problem.

Comment 10 Bruno Wolff III 2008-09-30 14:32:33 UTC
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:
kernel-2.6.27-0.372.rc8.fc10.x86_64
xorg-x11-drv-ati-6.9.0-20.fc10.x86_64
xorg-x11-server-common-1.5.1-2.fc10.x86_64
mesa-dri-drivers-7.2-0.3.fc10.x86_64

Comment 11 Bruno Wolff III 2008-10-01 20:21:09 UTC
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:
kernel-2.6.27-0.377.rc8.git1.fc10.x86_64
xorg-x11-drv-ati-6.9.0-21.fc10.x86_64
xorg-x11-server-common-1.5.1-4.fc10.x86_64
mesa-dri-drivers-7.2-0.5.fc10.x86_64
libdrm-2.4.0-0.21.fc10.x86_64
libdrm-2.4.0-0.21.fc10.i386
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.

Comment 12 Bruno Wolff III 2008-10-01 20:36:08 UTC
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.

Comment 13 Bruno Wolff III 2008-10-06 15:49:10 UTC
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.

Comment 14 Bruno Wolff III 2008-10-10 21:00:40 UTC
I am still seeing X lockups/crashes with modesetting enabled.
kernel-2.6.27-3.fc10.x86_64
xorg-x11-drv-ati-6.9.0-25.fc10.x86_64
xorg-x11-server-common-1.5.2-1.fc10.x86_64
mesa-libGL-7.2-0.7.fc10.i386
libdrm-2.4.0-0.21.fc10.x86_64

Comment 15 Bruno Wolff III 2008-10-15 17:44:40 UTC
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.

Comment 16 David 2008-10-18 03:32:40 UTC
I'm seeing similar problems with rawhide on this system:

http://www.smolts.org/client/show/pub_d49c89b4-8ca6-4c42-9edf-2d7ab3532390
(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.

Comment 17 Bruno Wolff III 2008-10-20 14:47:17 UTC
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:
kernel-2.6.27.3-30.rc1.fc10.x86_64
xorg-x11-drv-ati-6.9.0-28.fc10.x86_64
xorg-x11-server-common-1.5.2-7.fc10.x86_64
mesa-libGL-7.2-0.9.fc10.x86_64
mesa-libGL-7.2-0.9.fc10.i386
libdrm-2.4.0-0.21.fc10.x86_64
libdrm-2.4.0-0.21.fc10.i386

Comment 18 David 2008-12-17 20:35:21 UTC
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.

kernel 2.6.27.7-134.fc10.i686 
xorg-x11-server-common.i386               1.5.3-5.fc10 
xorg-x11-drv-ati.i386                     6.9.0-61.fc10
mesa-libGL-devel.i386                     7.2-0.14.fc10  
libdrm.i386                               2.4.0-0.21.fc10