This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 495454 - KMS:RS690M:Radeon X1200 Series Running gimp causes any subsequent window drag to freeze the system (EXA)
KMS:RS690M:Radeon X1200 Series Running gimp causes any subsequent window drag...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
11
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-13 05:51 EDT by Robert P. J. Day
Modified: 2010-05-24 15:07 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-24 15:07:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
The output of "dmesg" after modprobing drm and radeon with debugging. (50.25 KB, text/plain)
2009-04-13 14:49 EDT, Robert P. J. Day
no flags Details
The output of "dmesg" after "init 5". (108.47 KB, text/plain)
2009-04-13 15:24 EDT, Robert P. J. Day
no flags Details
The output of "dmesg" (via ssh) after my desktop locks up. (53.66 KB, text/plain)
2009-04-13 15:27 EDT, Robert P. J. Day
no flags Details
Xorg.0.log file representing "XAA" and that seems to work. (68.68 KB, text/plain)
2009-04-13 16:22 EDT, Robert P. J. Day
no flags Details
Xorg.0.log file after "XAA" option is removed. (68.34 KB, text/plain)
2009-04-13 16:28 EDT, Robert P. J. Day
no flags Details
Xorg.0.log file with "EXA" option in xorg.conf. (68.38 KB, text/plain)
2009-04-13 17:15 EDT, Robert P. J. Day
no flags Details
Xorg.0.log file from currently hung system. (68.12 KB, text/plain)
2009-04-23 18:51 EDT, Robert P. J. Day
no flags Details

  None (edit)
Description Robert P. J. Day 2009-04-13 05:51:55 EDT
As long as gimp is not running, I can happily drag windows back and forth on my desktop.  However, after starting gimp thusly:

  $ gimp filename.png

and without even doing anything in gimp, the next attempt to drag a window causes the system to freeze -- the only thing still active is the cursor, which remains in the "drag" format (tilted square with four smaller squares inside).

I've tested this five times, and had exactly the same result each time, requiring a power cycle and reboot to get the system back.  The behaviour seems to be the same, regardless of whether gimp is run in the foreground or background.
Comment 1 Robert P. J. Day 2009-04-13 07:39:34 EDT
I tried one more test and could only verify that, while I could move other windows around once gimp had started, it was moving the main gimp image window that caused the lockup.  It's as if, once gimp is displaying a PNG image, it's unable to reposition it by moving that image window.
Comment 2 Christopher Beland 2009-04-13 13:46:39 EDT
I was unable to reproduce this problem with gimp-2.6.6-2.fc11.x86_64.

What is the version number of the gimp RPM you are running?  ("rpm -q gimp")

I assume you are running the default desktop configuration (GNOME and metacity)?

Do you see any errors generated when you are experiencing symptoms, either in ~/.xsession-errors, /var/log/Xorg.0.log, or /var/log/messages?

Comparing this to bug 489776 (which seems slightly different), does the same thing happen if you view the same image in Inkscape?

Does the same thing happen if you run gimp in a newly created Unix user account?  If so, then this may be specific to your graphics hardware.  The standard attachments that might be helpful in diagnosing this problem would then be:

* Contents of /etc/X11/xorg.conf, if it exists
* Smolt profile.  (Run "yum install smolt" if it is not already installed, then run "smoltSendProfile" and add the public URL provided to this bug in a comment.)

If you have an /etc/X11/xorg.conf, another standard diagnostic is to move this file aside and try letting X auto-detect everything after a reboot.

Hopefully we can narrow down the critical difference that is causing this to happen for you but not me.
Comment 3 Christopher Beland 2009-04-13 13:50:12 EDT
I notice on fedora-test-list that switching from the radeon driver to the vesa driver fixed a different problem for you.  Does that also fix this problem?
Comment 4 Robert P. J. Day 2009-04-13 13:57:02 EDT
Yes, it does.  With the radeon driver giving me the full 1280x800 display, the instant I moved the gimp main image window, hard lockup.  Now using the vesa driver at 1024x768, I'm good and I can drag that window all over the place.

I think we've narrowed it down to the radeon driver, wouldn't you say?

$ rpm -q gimp
gimp-2.6.6-2.fc11.x86_64
$
Comment 5 Robert P. J. Day 2009-04-13 14:01:34 EDT
You can find my smolt profile here:

http://www.smolts.org/client/show/pub_27661e7f-528e-4db6-9ba4-8ce692a3ddf6

Yup, I'm running the default GNOME and metacity desktop.

I don't have inkscape installed.  And my entire xorg.conf file (the working version, obviously using the vesa driver) is:

Section "ServerFlags"
        Option "DontZap" "false"
EndSection

Section "Device"
	Identifier "Videocard0"
	Driver "vesa"
EndSection

  To switch back to radeon, I change only that one word.  And, so far, not a hiccup in my X session.  If I'd been using the radeon driver, I guarantee it would have locked up by now.
Comment 6 Christopher Beland 2009-04-13 14:31:01 EDT
Yes, that's pretty strong evidence.  Reassigning this bug to the kernel, which I hope is the right component for your driver.

Our standard diagnostic page also recommends the following test...

>>
First, boot into runlevel 3 by adding this to the kernel command line : 
    3 
and then run the following commands : 
    modprobe -r radeon drm 
    modprobe drm debug=1 
    modprobe radeon modeset=1 
At this point, please save dmesg and add it to this bug if at all possible. 
    init 5 
At this point, please upload Xorg.0.log (ssh'ing to the machine if at all possible). Any partially run test is useful if you can get the logs. 
<<

That's about the limit of my expertise as a triager.  Thanks for being a good sport about poking and prodding this machine!
Comment 7 Robert P. J. Day 2009-04-13 14:49:56 EDT
Created attachment 339352 [details]
The output of "dmesg" after modprobing drm and radeon with debugging.

The attached file represents the output from the "dmesg" command after:

  # init 3    (to get out of X)
  # modprobe -r drm radeon
  # modprobe drm debug=1
  # modprobe radeon modeset=1

At that point, I grabbed the output of "dmesg".  I'll next try to "init 5" to test this, but I'm fairly sure things will go south in a hurry.  I'll try to use ssh to grab whatever diagnostics I can if I can stay connected.
Comment 8 Robert P. J. Day 2009-04-13 15:04:05 EDT
I'm unsure what to do next in terms of testing.  If i just run "init 5", what will happen given that my xorg.conf file specifies the vesa driver, but I already have the drm and radeon drivers loaded, and in debugging mode?  I'm thinking that what I want to do, from runlevel 3, is now reproduce what happens when I'm running X in full 1280x800 with a radeon driver in "nomodeset" (which is the only way I can *get* full 1280x800 res), and doing what I know will lock things up, while hoping an ssh session into that system survives so i can check "dmesg".  Does that sound reasonable?

So, my plan:

* be in runlevel 3
* load drm with debugging
* load radeon with "nomodeset" (to get 1280x800)
* move xorg.conf out of the way so it has no effect
* "init 5", to hopefully get my full res X session
* do something I *know* will lock things up under those circumstances
* pray to some arbitrary deity that I can get something out of dmesg across the ssh link if it survived

  Thoughts?
Comment 9 Robert P. J. Day 2009-04-13 15:24:44 EDT
Created attachment 339361 [details]
The output of "dmesg" after "init 5".

This attached file represents the output from "dmesg" after being in runlevel 3, moving /etc/X11/xorg.conf out of the way, then

# modprobe drm debug=1
# modprobe radeon modeset=0
# init 5

since that's the configuration that gives me full 1280x800 res under the radeon driver, but it's also the configuration that's guaranteed to lock almost instantly after I try anything in my X session.  So I just let the X session start, and grabbed the output of "dmesg" before anything else happened.
Comment 10 Robert P. J. Day 2009-04-13 15:27:18 EDT
Created attachment 339362 [details]
The output of "dmesg" (via ssh) after my desktop locks up.

To get my desktop to lock, I started firefox and browsed over to linux-kvm.org, which inevitably does bad things to the radeon driver.  As it did this time.

Luckily, the ssh connection survived and I'm still logged in that way, so I grabbed the output of "dmesg" one more time.
Comment 11 Robert P. J. Day 2009-04-13 15:31:54 EDT
Since I'm (amazingly) still connected via ssh to the hung laptop, is there anything else you want me to check?  For instance, the output of "top" is kind of weird:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                         
 3011 root      20   0  472m  30m 9804 R 98.3  0.8  11:27.54 Xorg                            
 2194 root      20   0  242m 3956  868 S 41.8  0.1   6:08.93 rsyslogd                        
 2466 root      20   0 19884  960  820 R 27.4  0.0   2:30.43 hald-addon-stor                 
 2463 root      20   0 19884  956  820 S 19.9  0.0   1:49.89 hald-addon-stor

I've never seen "rsyslogd" suck up that much CPU.
Comment 12 François Cami 2009-04-13 15:46:11 EDT
Reassigning to xorg-x11-drv-ati as xorg-x11-drv-vesa does not exhibit the problem.

Robert, what happens if you add a
	Option "AccelDFS" "off"
line in the "Device" section of your xorg.conf ?

You can also try :
	Option "AccelMethod" "XAA"
as well (same section).

/var/log/Xorg.0.log from the locked-up laptop would help as well.

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 13 Robert P. J. Day 2009-04-13 15:50:03 EDT
What other settings do you want me to use?  I'm assuming the radeon driver, and "nomodeset", yes?  Since that's what gives me full 1280x800 resolution which is, of course, what we're going for here.  At the moment, my xorg.conf reads:

Section "ServerFlags"
        Option "DontZap" "false"
EndSection

Section "Device"
	Identifier "Videocard0"
	Driver "vesa"
EndSection

so I'll change "vesa" to "radeon" and add those options above, one at a time.
Comment 14 François Cami 2009-04-13 15:51:11 EDT
Yes, that was with the radeon driver and nomodeset as a kernel parameter.
Comment 15 Robert P. J. Day 2009-04-13 16:02:09 EDT
OK, "nomodeset" is in my grub.conf so it's the default.  Booted to runlevel 3, and added:

  Option "AccelDFS" "off"

that solved nothing -- i did my gimp test and it locked up immediately.  i'll add the other option now and test shortly.  here's the tail end of Xorg.0.log, based on the fact that i can still ssh in:

(II) RADEON(0): Printing probed modes for output LVDS
(II) RADEON(0): Modeline "1280x800"x60.0   71.11  1280 1328 1360 1440  800 803 809 823 (49.4 kHz)
(II) RADEON(0): Modeline "1280x720"x59.9   74.50  1280 1344 1472 1664  720 723 728 748 -hsync +vsync (44.8 kHz)
(II) RADEON(0): Modeline "1152x768"x59.8   71.75  1152 1216 1328 1504  768 771 781 798 -hsync +vsync (47.7 kHz)
(II) RADEON(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) RADEON(0): Modeline "1024x768"x59.9   63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync (47.8 kHz)
(II) RADEON(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) RADEON(0): Modeline "800x600"x59.9   38.25  800 832 912 1024  600 603 607 624 -hsync +vsync (37.4 kHz)
(II) RADEON(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) RADEON(0): Modeline "640x480"x59.4   23.75  640 664 720 800  480 483 487 500 -hsync +vsync (29.7 kHz)
(II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0
invalid output device for dac detection   <---???????????
(II) RADEON(0): EDID for output HDMI-0

  What's with that line above that I flagged?  Significant?  Probably not, I'm guessing just complaining that there's nothing on the HDMI port.
Comment 16 Robert P. J. Day 2009-04-13 16:11:16 EDT
OK, here's my current xorg.conf:

Section "ServerFlags"
        Option "DontZap" "false"
EndSection

Section "Device"
	Identifier "Videocard0"
	Driver "radeon"
	Option "AccelDFS" "off"
	Option "AccelMethod" "XAA"
EndSection

and my gimp test works!!!  as in, i can grab and drag the main image window.  and i can use firefox to browse to linux-kvm.org and it loads properly.  so it was, apparently, adding that AccelMethod option that did it.  I'll take that out and test one more time to verify.  Or was there another combination you wanted me to test?  But this is looking good, it's not breaking and I have full 1280x800 resolution.
Comment 17 François Cami 2009-04-13 16:13:19 EDT
Robert,

Could you please attach *full* Xorg.0.log from both XAA and non-XAA attempts ?

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 Robert P. J. Day 2009-04-13 16:15:23 EDT
And leave the AccelDFS option in there both times?
Comment 19 François Cami 2009-04-13 16:17:19 EDT
I don't think it does matter in your case, you can remove it before the two runs.

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 20 Robert P. J. Day 2009-04-13 16:22:41 EDT
Created attachment 339374 [details]
Xorg.0.log file representing "XAA" and that seems to work.

The Xorg.0.log file that represents a working X session with the radeon driver and the following xorg.conf file:

Section "ServerFlags"
        Option "DontZap" "false"
EndSection

Section "Device"
        Identifier "Videocard0"
        Driver "radeon"
        Option "AccelMethod" "XAA"
EndSection
Comment 21 Robert P. J. Day 2009-04-13 16:28:33 EDT
Created attachment 339376 [details]
Xorg.0.log file after "XAA" option is removed.

This is the Xorg.0.log file after removing the "XAA" option and simply returning to runlevel 5, without trying to do anything.  Once this file was copied, I tried the gimp test and, sure enough, lockup.
Comment 22 Robert P. J. Day 2009-04-13 16:32:48 EDT
Summary of what seems to work:

* "nomodeset" kernel option in grub.conf
* xorg.conf containing:

Section "ServerFlags"
        Option "DontZap" "false"
EndSection

Section "Device"
	Identifier "Videocard0"
	Driver "radeon"
	Option "AccelMethod" "XAA"
EndSection

Please tell me this is over. :-)
Comment 23 François Cami 2009-04-13 16:54:19 EDT
Robert, could you add the full Xorg log from a EXA attempt that locked up ?
There may very well be interesting lines at the end.

It should still be in /var/log/, probably as /var/log/Xorg.0.log.old . 

Thanks, and that should be all for now :)

Please ping that bug after a few days of use when you're sure XAA solves the problem.

To maintainer, this seems weird in the EXA log :
exaCopyDirty: Pending damage region empty!

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 24 Robert P. J. Day 2009-04-13 17:07:48 EDT
I'm assuming you're asking me to replace "XAA" with "EXA", is that it?
Comment 25 Robert P. J. Day 2009-04-13 17:15:47 EDT
Created attachment 339379 [details]
Xorg.0.log file with "EXA" option in xorg.conf.

This is the Xorg.0.log file corresponding to using the "EXA" option, which has the effect of bringing back all the bad, old behaviour, such as failing the "gimp" test.  xorg.conf:

Section "ServerFlags"
        Option "DontZap" "false"
EndSection

Section "Device"
	Identifier "Videocard0"
	Driver "radeon"
	Option "AccelMethod" "EXA"
EndSection
Comment 26 Robert P. J. Day 2009-04-13 17:17:24 EDT
Francois, there was no earlier "EXA" attempt, so I'm not sure if you're misunderstanding what we did earlier.
Comment 27 François Cami 2009-04-13 17:19:29 EDT
No, I'm asking for an EXA log that contains the lock-up, as you stated in
comment 21 that you saved the log before the lock-up. The old log should still
be in /var/log . EXA is used by default if you don't specify an AccelMethod, so the Xorg log without that line in xorg.conf is effectively an EXA attempt.

If you're not sure which log it is, replacing XAA with EXA, restarting X,
locking up the machine, and getting the current log via ssh, is another way to
get a complete log.

Thanks in advance

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 28 Robert P. J. Day 2009-04-13 17:21:03 EDT
See the attachment in comment 25, I think that's what you want.
Comment 29 Robert P. J. Day 2009-04-13 17:22:40 EDT
See the attachment in comment 25, I think that's what you want.
Comment 30 François Cami 2009-04-13 17:30:17 EDT
OK, thank you Robert. Please confirm (or infirm) that using XAA really works after a few days.

Summary :
* RS690M-based laptop cannot use KMS due to bug 495208 ;
* using EXA (nomodeset) leads to Xorg locking up and taking 100% of CPU, easily triggered by moving GIMP windows around ;
* using XAA (nomodeset) apparently cures the problem.

There is a suspect line in the EXA log :
exaCopyDirty: Pending damage region empty!

All logs aboard, switching to ASSIGNED.

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 31 Robert P. J. Day 2009-04-13 17:37:26 EDT
This also solves the lockup I was getting when simply trying to browse to the site http://www.linux-kvm.org.  With EXA, that page would consistently load about 90%, then hang the desktop.  With XAA, it loads fine, so XAA would seem to solve a number of the issues I was having.

I'll report back if anything changes.
Comment 32 François Cami 2009-04-23 16:46:44 EDT
Robert,

Could you try xorg-x11-drv-ati-6.12.2-5.fc11 from Koji :
http://koji.fedoraproject.org/koji/buildinfo?buildID=99245

You need to upgrade xorg-x11-drv-ati up to that version, then switch "XAA" to "EXA" in xorg.conf and of course restart Xorg.

Testing this is critical for us as we get closer to F11 Preview then GA.

Thanks in advance

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 33 Robert P. J. Day 2009-04-23 17:01:33 EDT
Seems to work fine, I have my full 1280x800 resolution.  Was that all you needed to know?
Comment 34 Robert P. J. Day 2009-04-23 17:09:43 EDT
Perhaps admitting my ignorance, but what kind of performance boost should I have seen by switching to EXA?  With XAA, Firefox was always hogging around 100% of the CPU (on a dual-core machine).  Now with EXA, it's dropped to between 70 and 75%.  Not a *huge* decrease, but definitely noticeable.  Should I have expected that?
Comment 35 François Cami 2009-04-23 17:11:44 EDT
Robert,

Could you please try (a few times) the use cases that triggered a crash in this configuration (both http://www.linux-kvm.org/ in firefox and "$ gimp filename.png" please) and report ?

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 36 Robert P. J. Day 2009-04-23 17:20:28 EDT
Looks like there's still a few bugs in the system.  I browsed over to linux-kvm.org and, this time, I could at least load the offending graphic but, at that point, everything locked up except for being able to (very slowly) move the I-beam cursor around the screen.  I eventually power-cycled to get the system back.

You'll have to wait until tomorrow morning for any more testing, sorry.
Comment 37 Robert P. J. Day 2009-04-23 17:26:50 EDT
OK, I lied, I tried one more test -- bringing up gimp, displaying a graphics file, then trying to drag the window containing that image.  Previously, even the slightest relocation of that window locked things up.  This time, I grabbed and slowly moved the window, and it moved.  Dragged it around the screen a few times, everything was good.

Finally, I slammed it violently from side to side and that's when things locked up.  So it seems that things are improving, but we're not there yet.

In any event, since I need this system working this evening, can I assume that I can leave the koji version of that package in place, and just revert to "XAA", and I should be safe?
Comment 38 François Cami 2009-04-23 17:39:05 EDT
Thanks for testing this Robert.

To the best of my knowledge reverting to XAA in xorg.conf should be safe, otherwise grab the previous build from koji (and XAA in xorg.conf as well) and you're set.

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 39 Robert P. J. Day 2009-04-23 17:54:32 EDT
Tell you what -- I'll leave it as EXA for now with the new rpm, and just avoid the things I know will cause trouble, and see if anything else turns out to be an issue.  So far, so good.
Comment 40 Robert P. J. Day 2009-04-23 18:42:20 EDT
OK, I just had another almost total lockup with the new RPM and "EXA", with the exception that I can still move the 4-way arrow cursor around (with *very* slow response).  On the other hand, I've been able to ssh into the system, and run "top":

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                
 2170 root      20   0  465m  36m  10m R 100.1  1.0  12:22.64 Xorg                                                  
 2720 root      20   0 46372  772  512 S 25.1  0.0   2:12.13 devkit-disks-da                                        
 1878 root      20   0 19888  972  832 S 24.8  0.0   3:00.78 hald-addon-stor                                        
 1877 root      20   0 19888  968  832 S 15.0  0.0   0:47.71 hald-addon-stor                                        
 4258 root      20   0 14852 1200  868 R  2.0  0.0   0:23.78 top

  Clearly, Xorg is sucking up a *tremendous* amount of CPU.  If someone reads this in the next short while, I'm willing to see what else I can learn if you want to suggest some tests.
Comment 41 Robert P. J. Day 2009-04-23 18:43:18 EDT
OK, I just had another almost total lockup with the new RPM and "EXA", with the exception that I can still move the 4-way arrow cursor around (with *very* slow response).  On the other hand, I've been able to ssh into the system, and run "top":

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                
 2170 root      20   0  465m  36m  10m R 100.1  1.0  12:22.64 Xorg                                                  
 2720 root      20   0 46372  772  512 S 25.1  0.0   2:12.13 devkit-disks-da                                        
 1878 root      20   0 19888  972  832 S 24.8  0.0   3:00.78 hald-addon-stor                                        
 1877 root      20   0 19888  968  832 S 15.0  0.0   0:47.71 hald-addon-stor                                        
 4258 root      20   0 14852 1200  868 R  2.0  0.0   0:23.78 top

  Clearly, Xorg is sucking up a *tremendous* amount of CPU.  If someone reads this in the next short while, I'm willing to see what else I can learn if you want to suggest some tests.
Comment 42 Robert P. J. Day 2009-04-23 18:51:33 EDT
Created attachment 341033 [details]
Xorg.0.log file from currently hung system.

This is with the koji version of the driver, and "EXA" acceleration.
Comment 43 Bug Zapper 2009-06-09 09:44:03 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 44 Paul J. Reder 2009-07-01 11:55:08 EDT
I'm running with the released FC11 (latest maint as of 7/1/2009) and seem to be having the same problem (symptoms and recreate all seem to match). My system info is:

/etc/redhat-release : Fedora release 11 (Leonidas)
uname -a            : Linux mercury.Reders 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 23:23:21 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
kernel-2.6.29.5-191.fc11.x86_64
xorg-x11-drv-ati-6.12.2-14.fc11.x86_64
mobo: ASUS M4A78T-E
cpu:  AMD Phenom(tm) II X4 810

Please let me know if having another set of logs from a different machine would help. I'm anxious for a solution as my machine that worked wonderfully under FC10 is nearly unusable under FC11.

Thanks.
Comment 45 François Cami 2009-07-01 15:19:10 EDT
Paul,

Can you use nomodeset in the kernel command line and XAA in xorg.conf and report ?

Thanks in advance

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 46 Robert P. J. Day 2009-07-01 16:02:05 EDT
Francois,

Is there reason to believe that XAA and nomodeset now works?  If memory serves, the last time I tried that combination, it still gave me trouble, which is why I had to back off to EXA.
Comment 47 François Cami 2009-07-01 16:12:35 EDT
Robert,

At least it should. If it does not, at least these changes are easy to revert.

Paul, please try nomodeset only first, as per
http://fedoraproject.org/wiki/Common_F11_bugs

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 48 Paul J. Reder 2009-07-15 16:04:26 EDT
Sorry it took a while to get back to this.

I added nomodeset to my kernel line in /boot/grub/grub.conf and verified in the dmesg output that it appeared in the "Kernel command line:" output after reboot.

It still hung in the same way.

System info from above is still accurate.
Comment 49 Nivag 2009-07-27 18:20:10 EDT
I too have experienced very sluggish cursor movements with xorg taking about 100% cpu.

Is this at all related to 
     Bug 488940 
     Comment #17?

I am quite happy to provide additional diagnostics or to try different things - if that helps resolve the issues.


Additional info:
up to date Fedora 11 install
AMD 810 quad core 64 bit
8 GB DDR3 RAM
5 * 500GB in software RAID-6 configuration
ASUS M4A78T-E mother board
Integrated Radeon HD 3300 chipset

# uname -a
Linux saturn 2.6.29.6-213.fc11.x86_64.debug #1 SMP Tue Jul 7 20:45:52 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux
#
Comment 50 Paul J. Reder 2009-08-07 17:36:45 EDT
I saw a recommendation from another, seemingly unrelated, issue that indicated the ASUS sideport video feature was problematic.

I went into the bios and turned off sideport support and haven't had a crash in over 10 days of really heavy use. Not sure what changed between fc10 and fc11 to cause the sideport problem, but I'm running fine now.
Comment 51 Nivag 2009-08-07 19:02:49 EDT
see bug 504427 Comment #7 ... #10

I have had no further problems of this type since disabling SidePort and switching to UMA in the BIOS.
Comment 52 Matěj Cepl 2009-11-05 13:26:17 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 53 Matěj Cepl 2010-02-26 07:20:02 EST
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]
Comment 54 Matěj Cepl 2010-02-26 07:29:25 EST
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Notice, that this is an automatically filed comment for all bugs with hanging NEEDINFO for longer time; it is possible by quirks of bugzilla, that some bugs are in this state even though you have attached the required information; please, make a comment to this bug ... that we should see correctly; I am sorry for the bothering you in such case.]
Comment 55 Bug Zapper 2010-04-27 09:39:27 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 56 Vedran Miletić 2010-05-24 15:07:07 EDT
Closing per comment 54.

---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[This triage is part of collective effort done by students of University of
Rijeka Department of Informatics.]

Note You need to log in before you can comment on or make changes to this bug.