Red Hat Bugzilla – Bug 207344
VT8623 VIA locks up with DRI
Last modified: 2009-10-12 17:51:33 EDT
1106:3122 VT8623 [Apollo CLE266] integrated CastleRock graphics
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
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.
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 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
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
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.
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?)
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:
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
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!
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
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
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
Can't test this quickly, environment is currently gone. Will do so in the next
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.
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:
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.
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:
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.