Bug 505538

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available), /var/log/dmesg, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 348222 [details]
dmesg

Created attachment 348223 [details]
xorg.conf

Created attachment 348224 [details]
Xorg.0.log

Created attachment 348225 [details]
Xorg.1.log

Created attachment 348226 [details]
Xorg.2.log

Created attachment 348227 [details]
Xorg.3.log

Created attachment 348228 [details]
Xorg.4.log

Created attachment 348229 [details]
Xorg.4.log

Created attachment 348230 [details]
Xorg.5.log

Today I tried to install rhel6-alpha-1 on the same system :
the behaviour of rhel-6 is much better, there was only one problem
with graphical input and that was the screen for setting the timezone
( locating a city on the map ).

One remark, unfortunately I was not able to complete the installation,
so this was only verified for the first screens including allocation of
partitions.

I had the same problem of slow graphics with Fedora 11.

VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]

with Fedora 10 it worked fine. After upgrading to Fedora 11, the X was _VERY_ slow. The pointer was taking several seconds to respond to a mouse movement. Logging in took over ten minutes. Even running fvwm, I didn't have the patience for it to come up fully.

I couldn't find any xorg.conf settings to fix the problem. However, adding nomodeset to the kernel entry in /etc/grub.conf fixed the problem completely. So I guess this is a kernel bug.

Thanks for #12, it seems to solve my problem 

Question to RedHat, is the nomodeset parameter just a bypass
or a solution ?!

Winfrid

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

(In reply to comment #14)
> 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.]  

With an up to date Fedora 11 system, the problem persists. Without "nomodeset" on the kernel command line, the system is unusable in X windows mode, but works fine in console mode. With "nomodeset" everything works. So waiting over 3 months and hoping it would solve itself didn't work:)

Winfrid asked a question back in July, which I still consider relevant. Is my "nomodeset" just a workaround, as I suspect?

I have since upgraded to Fedora 12 plus updates. There are some differences and initially I couldn't get things to work properly either with or without nomodeset. With nomodeset I had broken fonts until I set AccelMode to EXA (bug 557358). Without it I first had crashes, which seem to be due to having two cables connecting the same video card to the same monitor. That worked in F11 but in F12 it interprets it as a dual head system and has memory problems. Unplugging the second cable fixed that (Maybe bug 542729?). After that, I am back to performance problems but not as bad as in F11. Whereas in F11 I had VERY slow response to each mouse movement, in F12 I have normal response most of the time with hangs for about a second once in a while. This is now using:

  xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12.i686

It is still not really usable like this, but it is a step in the right direction.

I noticed a lot of messages:
  init: ck-log-system-stop respawning too fast, stopped
in the system log if I use AccelMode EXA. Otherwise I get no messages that would give a clue as to why it is hanging.

I think I can now answer Winfrid's question from July. Previously Xorg used user space mode setting (UMS) and now there is a kernel space version (KMS). The newer kernels default to KMS, but "nomodeset" tells it to go back to UMS. So it seems that the kernel mode setting feature is new and not yet fully debugged, but it is the default. Elsewhere Jerome Glisse wrote "boot with KMS, we are low prioritizing UMS bugs" so I guess that it is more of a fallback to the old way of doing things, which is now deemed obsolete rather than an actual workaround.

This seems to be in fixed Fedora 12 with the updates:

kernel-PAE-2.6.32.9-67.fc12.i686
xorg-x11-drv-ati-6.13.0-0.21.20100219gite68d3a389.fc12.i686

I'm not sure which of the two made the difference. In any case, glxgears now gives me about 100 FPS without any jumping. This is still using EXA acceleration as bug 557358 hasn't been fixed yet.

So thanks for fixing it, at least in Fedora 12. I don't know about Fedora 11, though as I no longer have any systems to test it on. I would have no objection to closing the bug as NEXTRELEASE. However, I guess that is Winfrid's call.

(In reply to comment #13)
> Thanks for #12, it seems to solve my problem 

Could you please try with the latest upgrades to F12 (both with and without nomodeset)? Does it help?

> Question to RedHat, is the nomodeset parameter just a bypass
> or a solution ?!

Yes, certainly, it is just a temporary crutch, and if something works without nomodeset we don't care about nomodeset anymore.

Thank you,

Matěj

I'm still encountering a similar hang on a 

Compaq Deskpro 686
Graphics controller is nVidia NV5 RIVA TNT2 Pro rev 15
Chipset is intel 82815.

I installed F12 from a CD, which installed and booted fine, and then performed a yum upgrade. 

Kernel 2.6.32.10-90.fc12.i686.PAE

The original kernel, 2.6.31.5-127.fc12.i686.PAE, works fine.

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 as wosrkforme per comment 17.

---

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