Bug 207344 - VT8623 VIA locks up with DRI
VT8623 VIA locks up with DRI
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-openchrome (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Xavier Bachelot
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-09-20 15:23 EDT by Warren Togami
Modified: 2018-04-11 04:15 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-10-12 17:51:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log (46.54 KB, text/plain)
2006-09-20 15:24 EDT, Warren Togami
no flags Details
X log during rawhide anaconda, which works because /dev/dri/card0 does not exist. (42.73 KB, text/plain)
2006-09-20 16:25 EDT, Warren Togami
no flags Details
xorg.log from machine (37.67 KB, text/plain)
2007-11-17 19:31 EST, Dave Russell
no flags Details
xorg.conf file with lower memory setting (757 bytes, text/plain)
2007-11-17 19:33 EST, Dave Russell
no flags Details

  None (edit)
Description Warren Togami 2006-09-20 15:23:13 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
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.


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...
Comment 1 Warren Togami 2006-09-20 15:24:45 EDT
Created attachment 136770 [details]

Xorg.0.log at the point X gets stuck displaying a blank screen.
Comment 2 Warren Togami 2006-09-20 16:25:55 EDT
Created attachment 136774 [details]
X log during rawhide anaconda, which works because /dev/dri/card0 does not exist.
Comment 3 Warren Togami 2006-09-20 19:15:20 EDT
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.
Comment 4 Bill Nottingham 2006-09-21 23:15:25 EDT
Well, there is bug 179970. But that's broken well before it gets to X.
Comment 5 Warren Togami 2006-10-04 22:01:36 EDT
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...
Comment 6 Matěj Cepl 2007-09-11 20:34:24 EDT
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
Comment 7 Matěj Cepl 2007-10-12 08:54:16 EDT
Warren, is this still relevant in the currently updated Rawhide?
Comment 8 Warren Togami 2007-10-12 11:26:30 EDT
I will have to test this when I get back to the office.
Comment 9 Matěj Cepl 2007-11-14 09:23:34 EST
Warren, ping?
Comment 10 Warren Togami 2007-11-14 11:05:25 EST
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?)
Comment 11 Dave Russell 2007-11-17 19:28:49 EST

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
Comment 12 Dave Russell 2007-11-17 19:31:20 EST
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".
Comment 13 Dave Russell 2007-11-17 19:33:27 EST
Created attachment 262601 [details]
xorg.conf file with lower memory setting

Even with the lower memory, still no display.
Comment 14 Dave Russell 2007-11-17 20:16:56 EST
Smolt profile for the affected box just in case it helps:
Comment 15 Warren Togami 2007-11-17 20:19:07 EST
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

Comment 16 Dave Russell 2007-11-18 04:57:29 EST
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
Comment 17 Jon Nettleton 2007-11-21 13:01:55 EST
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
Comment 18 Adam Jackson 2007-11-28 11:10:43 EST
Mass migration: via -> openchrome.
Comment 19 Matěj Cepl 2008-01-18 12:47:46 EST
Warren, ping?
Comment 20 Xavier Bachelot 2008-01-22 06:26:34 EST
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). 
Comment 21 Warren Togami 2008-01-22 09:41:59 EST
Can't test this quickly, environment is currently gone.  Will do so in the next
Comment 22 Matěj Cepl 2008-02-25 18:02:47 EST
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.
Comment 23 Warren Togami 2008-02-27 02:02:11 EST

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:
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.
Comment 24 Warren Togami 2008-02-27 02:02:51 EST
Jon, anything else to suggest?
Comment 25 Xavier Bachelot 2008-03-05 19:00:55 EST
Warren, could you please attach the xorg log and xorg conf ?
Comment 26 Warren Togami 2008-03-05 20:38:53 EST
There is no xorg.conf, and this is the same machine and log as Bug #435570
Comment 27 Bug Zapper 2008-05-13 22:22:05 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 28 Jóhann B. Guðmundsson 2009-01-06 08:17:18 EST
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.


Thank you.
Comment 29 Xavier Bachelot 2009-03-22 07:32:47 EDT
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 ?
Comment 30 Matěj Cepl 2009-05-16 18:05:04 EDT
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.
Comment 31 Bug Zapper 2009-06-09 18:17:41 EDT
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: 
Comment 32 Bug Zapper 2009-07-14 13:25:26 EDT
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.
Comment 33 Matěj Cepl 2009-10-12 17:51:33 EDT
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.


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