Bug 495454

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.

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.

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?

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
$

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.

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!

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.

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?

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.

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.

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.

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

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.

Yes, that was with the radeon driver and nomodeset as a kernel parameter.

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.

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.

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

And leave the AccelDFS option in there both times?

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

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

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.

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. :-)

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

I'm assuming you're asking me to replace "XAA" with "EXA", is that it?

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

Francois, there was no earlier "EXA" attempt, so I'm not sure if you're misunderstanding what we did earlier.

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

See the attachment in comment 25, I think that's what you want.

See the attachment in comment 25, I think that's what you want.

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

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.

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

Seems to work fine, I have my full 1280x800 resolution.  Was that all you needed to know?

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?

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

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.

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?

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

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.

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.

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.

Created attachment 341033 [details]
Xorg.0.log file from currently hung system.

This is with the koji version of the driver, and "EXA" acceleration.

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

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.

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

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.

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

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.

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
#

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.

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.

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.]

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]

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.]

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

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.]