Bug 80089 - upgrading from 7.2 to 7.3 caused display problems
Summary: upgrading from 7.2 to 7.3 caused display problems
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
Blocks: 82779
TreeView+ depends on / blocked
Reported: 2002-12-19 20:09 UTC by Need Real Name
Modified: 2007-04-18 16:49 UTC (History)
0 users

Fixed In Version: 4.3.0-42
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-12-15 13:04:14 UTC

Attachments (Terms of Use)

Description Need Real Name 2002-12-19 20:09:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.7-10 i686)

Description of problem:
WE have a lab of 17 Dell DImension 4100 PCs. Video card is
ATI Rage 128, 16MB. After upgrading 4 machines to RH7.3
(from kernel 2.4.7-10 to  2.4.18-3 all 4 machines have the following
problem: the inital "login screen" is distorted. The login box
lacks surrounding frames. A horisontal multicolored stripe, appears
on the top of the screen. Single pixels can be seen on the stripe.
The problem is intermittent and happens usually upon logging out.
Ctr Alt Backspace fixes it but it reapperas after some time. 
The problem seems to happen only if you have a combination of
ATI Rage 128 videocard and RH7.3. At least one application, which
requires extensive use of colors stopped working ( vmware ). 
It shows an error: not enough color left for LEDs. Switching desktops
or monitors do not help

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.login to the system

Actual Results:  "login screen" looks distorted

Expected Results:  "login screen" should look normal. A white framed Login box
on the
blue background

Additional info:

vmware started from the problematic machine does not work if Xserver
of the same machine is used ( see LEDs error messages above ) It works 
though if we use Xserver of an old non-upgraded machine as X server
for the application GUI.

Comment 1 Mike A. Harris 2002-12-20 01:52:06 UTC
I have many Rage 128 boards and I've not noticed any problems.

My suggestion is to rerun Xconfigurator manually and use it's newly
generated configuration.

Also note that Red Hat does not support installation of the operating system
inside VMware, nor do we support the usage of VMware in the system, nor
the inserting of VMware's kernel modules.

If you can reproduce this problem using the latest official updates
of everything available via up2date or the updates.redhat.com site,
using the latest official kernel update, and without having ever loaded
any proprietary kernel modules or VMware kernel modules, and never having
used VMware at all since boot, and can do this 100% reproduceably and
easily, please provide a copy of your X config file, log file, and your
complete /var/log/messages file including all content over a couple
of reboots uncompressed as individual file attachments using the link
below.  Also attach the output of "lsmod" from during having the problem,
and "lspci -vvn".  Once I've got instructions on how to reproduce reliably
without any proprietary software or kernel modules being involved, I
will investigate this problem and help troubleshoot.

Thanks in advance.

Comment 2 Miloslav Trmac 2002-12-20 10:45:19 UTC
There were quite a few people that encountered the problem with ATI R128,
including me.
The workaround is to comment out (add # at start of line) the 
        Load "dri"
line in /etc/X11/XF86Config.4
The fix is to upgrade to RHL 8.0.

Comment 3 Need Real Name 2002-12-20 23:04:09 UTC
I fixed a problem thanks to  Miloslav Trmac very useful comment. 
Load "dri" has to be commented out in /etc/X11/XF86Config-4
Mike, I do not  expect RedHat to support vmware. But if an application 
worked under official RedHat 7.2 distribution and could not be even launched
after I upgraded to Rh7.3 (bought from Redhat), that means there is a bug
in RedHat.  

Here is the fix:
generate  Xf86Config-4 using Xconfigurator
In section Screen DefaultDepth  24 ( instead of DefaultDepth 8 )
                  Depth 24 ( instead of Depth 8 )
comment out  Load "dri"

Comment 4 Mike A. Harris 2002-12-27 05:08:25 UTC
No, it doesn't necessarily mean there is a bug in Red hat Linux.  There
very much MIGHT be a bug.  However, you are using VMware, which is very
much an unsupported piece of software, which puts kernel modules into the
running kernel which make the system unsupported.

Can you reproduce this display problem without using VMware, while using
a Red Hat official kernel, and without using proprietary software that I
do not have access to?  If I can not reproduce the problem on a Rage 128
card, and without using VMware (which I do not have access to) then there
is nothing I can do to troubleshoot this.  The Rage 128 system I have
set up here right now for testing, has Red Hat Linux 7.[0123] installed on
it as well as 8.0, and I do not see any display corruption problems.

What I am basically saying here, is that you need to provide explicit
instrucitons on how to reproduce corruption without ever using VMware, or
I can't help you.  And if you can produce such corruption without ever
using VMware, please provide detailed step by step instructions on how
to do so, so I can try to do so.  If I can reproduce it, then I very much
may be able to do something to fix it possibly.  If I can't reproduce it,
then there is nothing I realistically can do.

Does that make sense?

Comment 5 Need Real Name 2003-01-03 21:19:15 UTC
The problem also exists on the machines which  never had vmware installed.
To reproduce a problem ( a distorted login screen ), mentioned above, all
you have to do is to upgrade from RH7.2  ( I bought it from RedHat on CDs )
to RH7.3 ( bought it from REd HAt on CDs too ). The problem is intermittent.
it does not happen always, you should probably leave machine on for sometime,
rebooting helps ( again sometimes ). I mentioned above how I fixed it, so to 
to reproduce a problem  Depth has to be 8 and Load dri uncommented in
/etc/X11/XF86Config.4  ( both is default after I installed RH7.3 )

Comment 6 Mike A. Harris 2003-12-15 13:04:14 UTC
Rage 128 video hardware does not support 3D acceleration at depth 8.
Actually, no video hardware (that I am aware of) supports 3D at
depth 8.

I am unable to reproduce this problem on 2 Rage 128 systems I have
here with RHL 8.0 installed on them.  The current XFree86 for RHL 8.0
and 7.3 is the same version of the source code, recompiled for each
release.  If you haven't already, please update to the latest erratum
for the OS release you are using, including the latest official
Red Hat kernel for that OS release.

Red Hat Linux 7.3 and 8.0 are end of life as of December 31, 2003,
and we are unlikely to release further XFree86 updates for these
OS releases between now and then unless there are critical security
flaws found.  Both products are in security-fix mode currently.

If the latest updates do not solve this problem for you, please
upgrade your operating system to Fedora Core 1, or Red Hat Enterprise
Linux 3, both of which ship XFree86 4.3.0 which is quite newer than
the XFree86 release from RHL 7.3, and it is entirely possible that
this problem has been fixed for a long time now in this newer
XFree86 release.

If, while using Fedora Core 1 with XFree86 4.3.0, you still
encounter this problem, please attach your X server log file,
config file, and /var/log/messages to this bug report as individual
uncompressed file attachments, and update the bug report to point
to Fedora Core 1 please.  It is also a good idea to report this
problem directly to XFree86.org via their bugzilla tracker, located
at: http://bugs.xfree86.org and provide the URL of your upstream
bug report here for us to track the issue upstream as well.

I'm going to close this as CURRENTRELEASE for now, as I'm unable
to reproduce it on the specific models of R128 I have tested it on,
and I don't know what specific model you have.  It's possible they
could be different, however your log files will show wether that
is the case or not.  Feel free to set this to REOPEN if the problem
persists in Fedora Core 1, after attaching the files requested above,
and filing an upstream bug report also, and I will track the issue.

Thanks in advance.

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