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): XFree86-4.0.3-21 How Reproducible: fully reproducible Steps to Reproduce: 1. run Xconfigurator or "XFree86 --configure" 2. run "startx" 3. 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 4.0.3-21.
Created attachment 40394 [details] configuration file from Xconfigurator, 16-bit color
Created attachment 40427 [details] log file from XV1
Created attachment 40428 [details] another log file from VX1
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?
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? Thanks.
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?
Created attachment 43779 [details] Xconfigurator-created, 16-bit, DisplaySize manually added
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.
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!
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.
Hehehe.. sorry.. Wasn't thinking Alpha there... ;o)
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. Thanks
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 4.2.0. Alan.
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 cursor between the right edge of the netscape window and the root background causes a two-D 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 appearance 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 RPMs? Thanks for the good work you do.
Does using the Option "noaccel" cure the problem ?
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).
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 it. Option "XaaNoScanlineCPUToScreenColorExpandFill" or Option "XaaNoScanlineImageWriteRect" Thanks. Alan.
Neither the blobs nor the sparkles leave anything behind. They are transient, probably only visible for one frame. Sorry if that was not clear. 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?
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!