Bug 57423 - Oxygen VX1, pixel scribbling, system crashes
Summary: Oxygen VX1, pixel scribbling, system crashes
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.1
Hardware: alpha
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-12 03:20 UTC by Robert M. Riches Jr.
Modified: 2007-04-18 16:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-06-02 01:52:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
configuration file from Xconfigurator, 16-bit color (1.83 KB, text/plain)
2001-12-12 03:22 UTC, Robert M. Riches Jr.
no flags Details
log file from XV1 (20.86 KB, text/plain)
2001-12-12 17:07 UTC, Robert M. Riches Jr.
no flags Details
another log file from VX1 (20.75 KB, text/plain)
2001-12-12 17:08 UTC, Robert M. Riches Jr.
no flags Details
Xconfigurator-created, 16-bit, DisplaySize manually added (1.86 KB, text/plain)
2002-01-28 15:10 UTC, Robert M. Riches Jr.
no flags Details

Description Robert M. Riches Jr. 2001-12-12 03:20:32 UTC
Description of Problem:
With a Permedia 3 Oxygen VX1 PCI graphics card, the screen appears
to be scribbled on by some stray pixel content from other areas of
the screen.  The screen takes on a window-screen appearance, with
semi-random gunk obscuring some of the pixels.  The hash changes as
xclock and other windows write to their own pixels.  It appears
something is scribbling in bad memory places, either in the video
RAM or in the X server's address space.  The symptoms are the same
regardless of whether Xconfigurator or "XFree86 --configure" was
used to generate the configuration file.

Also, with this card, the system hung or crashed three or four times
within a few hours.  (Normally, it stays up for weeks at a time.)

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

How Reproducible:
fully reproducible

Steps to Reproduce:
1. run Xconfigurator or "XFree86 --configure"
2. run "startx"

Actual Results:
Screen is hashed out.  System is unstable.

Expected Results:
The screen should be clean of hash/gunk.  The system should be
stable--not hang or crash.

Additional Information:
I'll attach the configuration file produced by XConfigurator for
16-bit color.  The gunk on the screen was worse at 24-bit color
than it was for 16-bit color.  I did not try 8-bit color or lower
resolutions than 1600x1200.  The whole reason I bought this card
was to try to run 24-bit color at 1600x1200.  Maurice at Harddata
said the VX1 should work, after two Voodoo3-3K and a nVidia Vanta
did not work at 24-bit color.  The Voodoo3 had done 24-bit color
just fine with RH6.1.  I'm currently using the Vanta at 16-bit color.

System hardware is a UP-2000 with one processor, two CDROMs (one of
them a writer) on the mobo's SE SCSI connector, two SCSI disks on
the LVD connector.  Other PCI cards are a BTTV (bt878?) card, rocketport
serial card (with Harddata driver), Ensoniq sound card, 5-port USB
card (because mobo USB ports don't work), 3C905b ethernet.  System
software is SRM 5.8-81, RH7.1 updated a week or two ago, and XFree

Comment 1 Robert M. Riches Jr. 2001-12-12 03:22:19 UTC
Created attachment 40394 [details]
configuration file from Xconfigurator, 16-bit color

Comment 2 Robert M. Riches Jr. 2001-12-12 17:07:19 UTC
Created attachment 40427 [details]
log file from XV1

Comment 3 Robert M. Riches Jr. 2001-12-12 17:08:17 UTC
Created attachment 40428 [details]
another log file from VX1

Comment 4 Mike A. Harris 2002-01-24 23:50:32 UTC
XFree86 4.1.0-15 and other required packages have now been released
as errata for RHL 7.1.  Please upgrade to this release of XFree86,
and see if the problem persists.  You will also need Mesa, xinitrc,
XFree86-compat-libs, and our new kernel erratum.

Does the new release solve this problem for you?

Comment 5 Robert M. Riches Jr. 2002-01-27 06:40:59 UTC
I tried it, and it's maybe a bit closer to working.
I found that up2date required me to upgrade the kernel first,
then the XFree86 and related stuff.

One small negative observation:  Xconfigurator appears to
write/install the configuration files even when it "fails" as
defined by no positive response to the "can you see this?" test.

With the TNT2 Vanta card (used because the VX1 wasn't working)
16-bit color works perfectly at 1600x1200, but 24-bit color has
the same old shifting problems as always.  With the Oxygen VX1
card, 16-bit color has a lot of purple crudlets (horizontal purple
lines about 75-100 pixels long littering the landscape); and
24-bit color has a lot of bright red or orange-red littering.
The system has been up for an hour, but there might still be
stability issues.

Are there configuration options (such as GLX, DRI, etc.) that
should be disabled to try to get rid of the littering?  Which
options should I disable and which should I keep?  I don't
really care about fancy 3D acceleration, just decent xterm
and netscape scrolling, gimp display, etc.

On one of the lists, it was suggested I try kernel 2.4.16 or
2.4.17 and XFree 4.2.0 (which I would put in /usr/local to
avoid conflicts with the RH-supplied stuff).  Any suggestions
wrt. that potential experiment?


Comment 6 Robert M. Riches Jr. 2002-01-28 15:08:39 UTC
One strange thing I noticed while studying the config file in
more detail: Xconfigurator appears to think the Oxygen VX1 is
a Permedia 2, when it's actually a Premedia 3, or so I'm told.
I'm going to attach the latest config file from Xconfigurator
(plus a DisplaySize attribute manually added).

How should the config file differ for an Oxygen VX1 from the
one now that think's it's a permedia 2?

Comment 7 Robert M. Riches Jr. 2002-01-28 15:10:31 UTC
Created attachment 43779 [details]
Xconfigurator-created, 16-bit, DisplaySize manually added

Comment 8 Robert M. Riches Jr. 2002-01-29 19:37:36 UTC
Please disregard the previous question about whether the VX1 should
be treated as a pm2 or something else.

As has been discussed on the mailing list, XFree86 4.2.0 compiled
from xfree86.org sources and installed in /usr/local seems to work
quite well, even at 24(32)-bit color.  There are brief (probably
one or two frames) white flecks or blobs, which SWCursor does not
eliminate, but they're tolerable.

Thanks for making the 4.2.0 RPMs available in the 7.2 testing area.
I hope to buy 7.2 when it's released.

Comment 9 Mike A. Harris 2002-02-03 14:12:42 UTC
So 4.2.0 is working ok for you now with this issue?  If so, I'd like to
close the report as fixed in rawhide.

"swcursor" disables the hardware mouse cursor and uses a software mouse
cursor instead.  Is this blob problem related to the cursor?

>Thanks for making the 4.2.0 RPMs available in the 7.2 testing area.

No problem.  I hope to be able to release it as erratum at some point
as well.

>I hope to buy 7.2 when it's released.

Red Hat Linux 7.2 has been released since October 2001.  ;o)
Or did you mean our next release?  hehehe

Thanks for the update.  Take care!

Comment 10 Robert M. Riches Jr. 2002-02-04 19:47:27 UTC
The sparkle/blob problem is independent of HWcursor vs. SWcursor,
which I verified again this morning.  The /var/log/X... file shows
SW cursor is being used, but the sparkles/blobs remain.  It just
makes the cursor less responsive time-wise.

Since when was Red Hat Linux 7.2 released in October, 2001 for the
_Alpha_ architecture???  :-)  The last I heard was it would be on
Compaq's web site some time in Q1, 2002.  (translation: check back
in April)

I'm agreeable to closing the report.  I'll look forward to buying
7.2 and then putting in the 4.2.0 RPMs.

Thanks for your work on these issues and on further improving the
best available OS on this planet.

Comment 11 Mike A. Harris 2002-03-07 20:40:29 UTC
Hehehe.. sorry..  Wasn't thinking Alpha there...  ;o)

Comment 12 Mike A. Harris 2002-05-18 00:33:49 UTC
Ok, thanks.. I'll close the report as fixed in 4.2.0, however if the problem
persists, feel free to reopen it, and bump the bug report up to RHL 7.2 once
our Alpha release is available.  Note that 7.2 contains 4.1.0 though, but
4.2.0 is available in rawhide, or I can make it available to you for alpha.

I've also Cc'd Alan Hourihane, whom I believe maintains this driver.


Comment 13 Alan Hourihane 2002-05-18 12:09:54 UTC
I've no idea what you mean by blobs....

Can you describe in a bit more technical detail.

I've got 4 x Permedia 3 based cards and never seen any drawing problems with 


Comment 14 Robert M. Riches Jr. 2002-05-18 14:19:20 UTC
Here's an attempt at a bit more technical detail about the "blobs" or "sparkles"
I'm seeing with
XFree86 4.2.0 (have not yet had opportunity to try the 4.2.0 RPMs, so am still
using the 4.2.0
compiled from xfree86 sources and installed in /usr/local).

The first type of sparkle or blob appears when the cursor changes.  With
netscape showing a
light-colored bugzilla window and a dark gray root window background, moving the
between the right edge of the netscape window and the root background causes a
blob of white to appear just to the right of the border.  The blob appears to be
made of white
horizontal lines about 50-75 pixels wide.  The blob is about 25-50 scan lines
high.  The white
lines are appear to be present on about half of the scan lines, apparently
randomly distributed.

The second type is one scan line high, mostly when I'm running xawtv.  They are
one scan
line high, between 20 and 100 pixels high wide with most of them less than 50
pixels wide.
Their frequency is proportional to the amount of xawtv window visible,
decreasing when another
window covers the xawtv window.  I see both white and black (or light and dark)
types.  It appears
they copy part of the same scan line, about 200 or maybe 256 pixels to the right
of where it
should be.  A transition of light on the left and dark on the right will cause
light sparkles to the
right of the transition.  A transition from dark on the left and light on the
right will cause dark
sparkles to the right of the transition.

I have a hunch that the problem is caused by writes to the video RAM interfering
with the
datapath that reads from the video RAM and displays to the screen.  Further, the
that pixel content is being shifted to the right by around 256 pixels makes me
wonder if the
read path splits the pixel address into 8-bit bytes and pixels are being pulled
from video RAM
with the second order group of address bits being one less than it should be, or
maybe not
updated correctly.  Perhaps writes to the video RAM prevent the carry from the
read path's
address from the bit of significance 128 to the bit of significance 256.

The time duration of both types appears to be one frame time.  Using SWCURSOR
does not
reduce the second type, and I don't believe it reduced the first type.  I'm
running 1600x1200
at 24/32-bit color at 85Hz.

Was that sufficient detail?

When (if?) RH7.2 becomes available (will be at Compaq's (now Hew-Paq's) web
site, I'm told),
I'd like to try an RPM version of 4.2.0 with all the excellent patches you great
folks at Redhat
have spent so much time working on.  At one time, Mike Harris said to use RPMs
from his
"testing" area, _NOT_ from rawhide.  Could you please inform where I should get
the RPMs
to use with 7.2 (when it's available) and whether I should use binary or source

Thanks for the good work you do.

Comment 15 Alan Hourihane 2002-05-18 14:48:40 UTC
Does using the 

Option "noaccel"

cure the problem ?

Comment 16 Robert M. Riches Jr. 2002-05-18 20:49:56 UTC
Uncommenting "option noaccel" from the configuration file
(and verifying its effectiveness by looking in the log file)
cures the first type, blobs affecting multiple scan lines when
the cursor changes shape.  However, it does not cure the
second type, sparkles affecting only one scan line each
when running xawtv (and perhaps other applications that
write to many pixels in real time).

Comment 17 Alan Hourihane 2002-05-19 09:03:11 UTC
O.k. With the sparkles - do they leave any artifacts on the screen or not ?

As for the blobs...

Can you remove noaccel and try one of the following and tell me which fixes

Option "XaaNoScanlineCPUToScreenColorExpandFill"


Option "XaaNoScanlineImageWriteRect"



Comment 18 Robert M. Riches Jr. 2002-05-20 21:12:29 UTC
Neither the blobs nor the sparkles leave anything behind.  They are
transient, probably only visible for one frame.  Sorry if that was not

I tried both the options suggested, and neither one solves the blobs,
the multiple scan-line high things when changing cursor shape.  It
didn't occur to me to try them together.  Would that be useful?

Comment 19 Robert M. Riches Jr. 2002-06-01 21:48:52 UTC
FYI: In preparation for up2dating to 4.1.0-25, I disabled the local 4.2.0 (from
xfree86.org sources) and went back to RH's 4.1.0-15, and the persistent
crudlet problem, the problem originally reported, had gone away.  Perhaps
the update in March to kernel 2.4.9-31 had done the trick.  4.1.0-25 seems
to work great, so far, with the minor exception that the transient sparkles
and blobs are still there (same as with 4.2.0 from xfree86.org sources).
Thanks for all the good work!

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