1106:3122 VT8623 [Apollo CLE266] integrated CastleRock graphics xorg-x11-drv-via-0.2.1-4.1 This chipset currently locks up with a blank screen when booted with the default configuration in Fedora. Only X appears to be stuck, you are able to login via the network. agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode mtrr: base(0xe4000000) is not aligned on a size(0x2080000) boundary This message repeats forever in dmesg when X is stuck. According to davej this means X is retrying repeatedly after the failure. LTSP reports that historically they have had to explicitly set an amount of video RAM like 16384 in order for the native via driver to work on this chipset. Turning off DRI in xorg.conf also seems to make this driver work. kernel-2.6.17-1.2630.fc6.i586 xorg-x11-drv-via-0.2.1-4.1.i386 If we are unable to fix this driver before FC6, I recommend disabling DRI in the shipping binary so X will at least do *something*. Logs and other info coming next...
Created attachment 136770 [details] Xorg.0.log Xorg.0.log at the point X gets stuck displaying a blank screen.
Created attachment 136774 [details] X log during rawhide anaconda, which works because /dev/dri/card0 does not exist.
ajax took one look and figured out that assert.h was missing from xorg-x11-drv-via, which only manifests itself in the DRI codepath. This worked when explicitly setting 16MB of video RAM because that is too low, and DRI disables itself. Unfortunately, this is probably the first time anybody tested DRI with this driver ever. While it is able to login to a user desktop just fine, running anything that requires DRI causes X to lockup. ajax is investigating further, but if we can't figure this out quickly, we should disable DRI in FC6. It turns out that nobody could have been using with DRI since FC5 anyway.
Well, there is bug 179970. But that's broken well before it gets to X.
ajax said that he will disable DRI for this driver in RHEL5 for the sake of stability, but we agreed that it is best to keep it enabled in FC6. If nobody runs into the problem, then it will never be fixed...
Since this bugzilla report was filed, there have been several major updates, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their distribution available. 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.
Warren, is this still relevant in the currently updated Rawhide?
I will have to test this when I get back to the office.
Warren, ping?
xorg-x11-drv-via-0.2.2-4.fc8 has behavior exactly as described in Comment #3. (Did we end up disabling DRI by default in RHEL5?)
xorg-x11-drv-via-0.2.2-4.fc8 I can also confirm I'm seeing no display on a Via VT8623 (lspci line shown below). 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03) I did try the option of setting the videoram to a smaller amount as shown above, but that did not work. Attaching xorg.log and xorg.conf
Created attachment 262591 [details] xorg.log from machine This is the result of logging into the box via ssh, typing "init 5" waiting a few minutes and then typing "init 3".
Created attachment 262601 [details] xorg.conf file with lower memory setting Even with the lower memory, still no display.
Smolt profile for the affected box just in case it helps: http://smolt.fedoraproject.org/show?UUID=d45b75f0-8eff-4cd4-a761-74917ce75420
Dave, if X isn't coming up at all then you might be seeing a different issue than this report. Please try disabling DRI in your xorg.conf file and see if the behavior has changed at all. Unfortunately, I don't remember the syntax to do this. You can also disable DRI by preventing it from loading the drm kernel module for the VIA platform, You can find this at /lib/modules/VERSION/./kernel/drivers/char/drm/via.ko
Looks like you could be right, I modified the xorg.conf to the settings shown below and still no X. However a brief scan of the xorg.log file suggests that NoDRI doesn't actually work. Looks like I've now found two separate bugs (lucky me!), will go raise my own :o( Sorry for the noise! Section "Device" Identifier "Videocard0" Driver "via" Option "NoDRI" VideoRam 16384 EndSection
If this is for F8 could you please install xorg-x11-drv-openchrome and try it out. You will need to change the Driver line in your xorg.conf to Driver "openchrome" You might also need to add Option "EnableAGPDMA" "false" to the Device section as well. This is due to a recent regression in drm, we are working on this. Please post your log using the openchrome driver and I should be able to troubleshoot the problem. I have a cle266 running F8 and openchrome without a problem.
Mass migration: via -> openchrome.
Warren, can you please retry with xorg-x11-drv-openchrome. This is the successor to xorg-x11-drv-via. Just replace Driver 'via' by Driver 'openchrome' in your xorg.conf. You shouldn't need any other option in the Device section (except the Identifier, obviously).
Can't test this quickly, environment is currently gone. Will do so in the next week.
Warren I am afraid a week already passed … :-) If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA.
xorg-x11-server-Xorg-1.3.0.0-42.fc8 xorg-x11-drv-openchrome-0.2.901-2.fc8 Nice, this driver used the maximum 1680x1050 resolution of my monitor while the via driver could only do 1400x1050. [test@newcaprica ~]$ glxinfo name of display: 172.31.100.219:0.0 libGL error: open DRM failed (Operation not permitted) libGL error: reverting to (slow) indirect rendering The system completely deadlocked at this point. Option "EnableAGPDMA" "false" suggested did not help the deadlock issue.
Jon, anything else to suggest?
Warren, could you please attach the xorg log and xorg conf ?
There is no xorg.conf, and this is the same machine and log as Bug #435570
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Could you update to the latest version, retest and report back to see if this still remains an issue for you. You can get the latest update from here. http://koji.fedoraproject.org/koji/packageinfo?packageID=5229 Thank you.
Warren, does latest openchrome driver from either F10 updates (0.2.903-5.fc10) or F10-updates-testing (0.2.903-6.fc10) help ? Can you please provided an updated xorg log ?
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.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.