Description of Problem:
As already reported elsewhere (#59104, but this was for XFree86-4.1.0-15
and this time MGA G450 is in UP1500 and not UP1100) XFree86-4.1.0-19
promptly kills text console covering it with various vertical stripes
with a cursor blinking somewhere. Blind 'telinit 1' restores text but
only after level 1 is really reached.
'rpm -Uvh --oldpackage XFree86-4.1.0-8.alpha.rpm' from the previous
beta restores sanity and a text on a console.
I wonder what is the point of filing bug reports if the same bugs
reapper in a different context?
Version-Release number of selected component (if applicable):
No way to avoid it.
The point of filing bug reports is to bring problems to the attention
of people who might be able to fix them. I guess it is fair of me
to indicate that the only changes that have occured in XFree86 that
are related to the alpha platform, are changes made directly by
XFree86.org in the stock source code, or via Alpha patches sent directly
to us from Compaq, with request of integration to fix bugs on Alpha.
Perhaps your negative comments should be redirected to one of those
two sources where they would catch the attention of those working on
the code, and creating these bugs. I'm sure they'll be glad to get
the reports, and fix the problems.
Reassigning to Alpha project team.
bhu - Just a note on MGA, Matrox more or less maintains the mga driver,
and nowadays most driver changes in the mga driver come directly from
them. While we're greatful that they contribute to open source at all,
past experience shows that they either do not test their code out at
all prior to submission to XFree86.org, or else they test it only very
minimally, and probably only on the particular new piece of hardware
that they are adding support for. As such it is not unlikely that the
driver will break in new ways with each release.
Also to note, is that the specifications for the G450 and G550 are
not available publically, nor under NDA. I highly doubt that Matrox,
nor anyone at XFree86.org tests mga hardware out on the Alpha platform,
since it doesn't appear to be well tested on any platform.
Patches coming in from compaq tend to be the only source of Matrox
driver fixes for the alpha platform. I have 2 Alpha machines here,
that are PCI only, however I only have a G450 AGP card which I have
yet to see working even in an x86 machine.
Sounds like the EnterVT/LeaveVT code might be incomplete or buggy. I
had a brief look at it the other day for a problem reported on a
Millenium 1 card, but didn't spot anything obvious, and don't have one
I've got contacts at Matrox if you need them, just let me know.
Hope this info is helpful.
Well, if you want more "positive" comments then how about "XFree86-4.1.0-15
kills a text console on Athlon with NVIDIA GeForce 2 MX"? Because it does
that too (and there are no binary only drivers in sight). It is not doing
that right away, as I can see on Alphas, but only after some days running.
To make up for that a screen is covered with multicolored vertical "strokes"
only a few pixels wide and different length instead of boring uniform and
Mind you the previous report talked also about RIVA TNT2 on Alpha so it is
hard to put that at Matrox feet. Especially that on another Athlon box with
MGA 400 and the same version of X I did not observe anything of that sort
(currently this other box has XFree86-4.2.0-6.32 recompiled for 7.2 distro
and so far so good and a text console is not going away).
I will try XFree86-4.2.0 on Alpha in question when I will get a kernel
in a good enough shape there to be able to recompile. The last attempt
to do so completely destroyed a file system (which is not a fault of X :-).
The other Alpha (UP1100), mentioned in the previous report, does not have
such stability troubles but it also does not have a free disk space required
to recompile X.
All in all it looks to me that X server is scribbling on memory which does
not belong to it and this is not limited only to Alpha but I do not have
a smoking gun. And once again XFree86-4.1.0-8 (it is enough to replace
a server package only leaving the rest intact) does not misbehave that
way which sounds to me like a positive information.
I can confirm now that the bug described in this report DOES NOT happen
on the same machine, with the same MGA G450 card and otherwise the same
software installation, but when I replace XFree86-4.1.0-19 with
XFree86-4.2.0-6.45 from rawhide. A text console is still there after I
started an X server - at least for the first 15 minutes. :-)
This behavior is also the same if I will use ATI Radeon 7500 instead
(which needs 4.2.0 to work at all). Hence it looks like that the bug in
question is limited to some range of subversions of 4.1.0 but it occures,
to a different degree, across a number of video cards and architectures.
BTW - the above means that Radeon 7500 indeed works on Alpha although it
requires 'Option "CrtScreen"' in a Device section, or none of screens will
be found, and video artifacts during an X startup are downright scary. :-)
Provide the output of "lspci -vvn" to me, and I will see about
adding CrtScreen to the configuration by default for this particular
(I still don't have an AGP Alpha to test with...)
Defering for AGP Alpha acquisition..
As noted a long time ago updating X to 4.2.0 solved the problem. Even
when you will get an Alpha with AGP do you really plan to work on an old
Well... I have a personal interest in the Alpha, so even if Red Hat does not
have any supported Alpha products at the time, I'm still interested in helping
keep Alpha alive and kicking. That might actually mean that these AGP Alpha
issues are already fixed by then of course, but it doesn't hurt to track them
until then at least. I'l probably ping George on some of them from time to time
to see if he knows of status change, etc.
Don't have AGP Alpha hardware, and we don't ship Alpha anymore. Safe to
close this oldie as WONTFIX now I think.