Re: Old Video Card Problem in RH9

["Mike A. Harris" <mharris www linux org uk>]

On Thu, 12 Feb 2004, Thomas Dodd wrote:

>| rather than a driver specific bug.  I assume any video hardware
>| on this system will result in the same problem regardless of
>| driver.
>
>Not according to the Xfree86 bug Alex mentioned.

Alex himself in his last email also hypothesized that it was a
bug in the PCI code:

----------------------------------------------------
>Ask and ye shall receive:
>http://bugs.xfree86.org/show_bug.cgi?id=604
>
>Looks like a problem with the PCI code.  there is a fix, but it is
>awaiting feedback from the original poster.  perhaps you can 
>verify it.
----------------------------------------------------

>Thanks for the help Alex.

And for concurring with my initial thoughts as well.  ;o)


>| I have never even once in my life been on redhat-install list.
>
>OK. My bad. I though you were, before your email adress included
>@redhat.com :)

If so, that would have been well over 3.5 years ago, certainly 
longer than I remember.


>Still, you have moved off most redhat lists, like the shrike and
>vahalla lists.

There are too many lists to follow.  I track the current distro, 
more or less like I always have, however where in the past I 
would overlap lists for a month, I ended up becoming too busy to 
really follow things closely anymore, and so I unsubscribed from 
many lists.  I spend most of my list-time so to speak - on 
XFree86 related lists and similar nowadays.  I also try to avoid 
lists that are low-development content and high-rant-and-rave 
type of lists, although that isn't always avoidable.  My 
preference is mostly for developer centric lists for discussing 
developmental issues with high S/N ratio.  Second to that I like 
to keep a small handful of "help" type lists such as this one, 
and 5-10 others.

Most of it is just downloaded and archived though... only so many 
hours in a day...  ;o/


>|>Yes he should join this list. Convincing him is another issue. I
>|>don't know if he has paid for any support, but he claimed the
>|>card was listed as supported.
>|
>|
>| "support" means very different things to different people.  Zero
>| of the drivers are "certified to be error free".  And we give no
>| warranty that we will fix every single bug that every single user
>| discovers either.  If we were to make such commitments, we would
>| probably throw out all of the drivers except for "radeon".
>
>If I by a software package and it list my hardware/OS as supported, I
>expect it to function. So, if RHL9 listed this card as "supported" I
>would expect it to work. Like my TNT2. It works, and if it didn't
>efforts would be made to fix it, yes? (I mean the 2D driver from
>xfree86, not GLX or NVIDIA's driver).

"work" however means different things to different people.  If 
for example one's expectation of "works" means all features or 
even 'most' features of their video card is "supported" and 
"functional", then for the most part "zero" video cards are 
"supported".

Many of the drivers included in the distribution are supplied "as
is" with efforts made to apply upstream bug fixes as they become
available.  An example would be the "s3" driver, the "s3virge"  
driver, the "cirrus" driver, "ark", "apm", and many other legacy
drivers for ancient hardware.  These are supplied with the 
distribution for end user convenience only, so that users that 
have this hardware have a chance of having it work out of the box 
without having to download sources and compile it themselves.

Those drivers are "very very low priority", meaning if they have
problems, it is very unlikely that I will personally track down a
card, purchase or otherwise obtain it, and then debug it for
hours/days/weeks until a solution is found.  It isn't
economically viable to do so in any way.

Most of the drivers however do tend to work for many if not all 
people, and so it is worth including them, even if we have no 
intention of dumping a tonne of resources into maintaining them 
or fixing them.  That is the "as is" part.  However, even though 
they're typically "as is", I don't /ignore/ bugs and issues in 
them.  They just don't get the attention that a current 
generation mainstream driver such as "radeon" would get.  If I'm 
made aware of a fix for cirrus logic for example, or if I come 
across one myself when digging through CVS, or doing a google or 
search through CVS commits after a user reports a problem, I will 
generally spend a bit of time trying to include fixes and in some 
cases update the whole driver.  See the "rendition" driver for an 
example.

My point here, is that there are "limits" on how much work *ANY* 
distribution vendor can provide to support any kind of hardware 
driver, and that often includes various factors such as:

1) wether or not they actually have physical access to the given
   hardware

2) wether they have technical specifications for the hardware or 
   can obtain them

3) how "current" and widespread usage of the hardware is, and 
   thus how many users are affected, or might be

4) how many developers the vendor has working on the given 
   problem area.  In this case it is video drivers, and the 
   answer is "2".

5) How actively maintained the driver is upstream.

6) What other priorities the given developer(s) have in their 
   work schedules.


There are many other factors as well, the above are a short list
of a few off the top of my head.  In many cases, I do not
personally have physical access to the hardware the problem is
occuring on, yet physical access is *required* in order to
proceed with a problem report.  In that case, a judgement call
has to be made on the scope of the problem, how long it *MIGHT*
take in man hours to even debug, what the chances would be it is
even fixable with the hardware in hand, wether or not the specs 
are available and if so - if they are even well written enough to 
be useful, and how the problem stacks up against all other 
priorities.

Quite often, the specs ARE NOT available.  In many cases they are 
REQUIRED, where in others they are not.  Working specless on some 
types of problems can double or triple the time to get anywhere 
with it, if not make it impossible.

For #3, if hardware is ancient, then it will get almost zero 
chance of being looked at other than to query upstream CVS and/or 
bugzilla for fixes and perhaps google around to see if there are 
patches out there.  For example, file a bug report on Ark Logic 
PCI card having on screen corruption, and the solution I will 
give you is either (forgive my bluntness below):

1) disable 2D acceleration.  Sorry it's slow, deal with it.

or

2) use 'vesa'.  Sorry it's slow, deal with it.  If it doesn't 
   work, sorry your BIOS is buggy, we can't FLASH it with fixed 
   code.  Contact vendor for new BIOS.

or

3) report bug upstream in hopes that someone still cares about 
   the ancient driver for hardware from 10 years ago

or

4) buy a new video card


It's pretty much a guarantee that I won't be obtaining an Ark 
Logic card and debugging the problem for any reason.  I will 
certainly investigate adding patches or workarounds however that 
I can quickly locate, or which are passed on to me though.  But I 
can't justify hours of my time on a card that is 10 years old, 
which perhaps 3 people even still own that isn't in landfill 
somewhere.

So now to answer your question:

>So, if RHL9 listed this card as "supported" I would expect it to
>work. Like my TNT2. It works, and if it didn't efforts would be
>made to fix it, yes?

Yes.  Efforts will be made, but they are not infinite.  There are
definite limitations on how much time and effort are to be spent
on any given problem.  In the case of Nvidia hardware, have a
look at the "nv" driver's source code sometime.  It is
intentionally obfuscated code that directly writes hexadecimal
values into hexadecimal register numbers.  The majority of the 
driver has no symbolic macros used to reference registers at all 
period.  There are no Nvidia specifications available publically 
nor under NDA.

So then, what "effort" can I personally provide to fix your 
problem in the 'nv' driver?  I can suggest some troubleshooting 
tips to try to narrow the problem down.  I can also search in the 
standard places I search for fixes, and possibly the 'nv' driver 
maintainer has fixed the issue and I can backport a fix.  I can 
eyeball the source code in the area the problem is believed to be 
in, and hopefully spot a typo or other problem or flawed logic or 
somesuch.  In some cases that does work too.  That isn't the 
general case however.  The general case is that the problem 
requires a knowledge of the operation of the specific chip, and 
of the driver's own operation.  Not something you can obtain by 
studying cryptic hexadecimal register numbers without technical 
specifications.

So while there are many cases in which "effort" can be spent to 
fix problems and thus "support" this hardware - expending effort 
to support the stuff does NOT mean that there is a 100% guarantee 
that a solution will become available.  And 6 months isn't going 
to be spent reverse engineering a chip to understand how it works 
to fix a bug either.

There are limitations on what "support" means.


>| Again, I am a busy person and have many priorities that are of a
>| much higher magnitude than searching through random list postings
>| to try to help someone who according to you, sounds like they're
>| too busy to be bothered anyway.
>
>It took me 30second to find the thread in the archives. Another 5
>minutes to find the relavant ones and add the links. It was only
>mentioned, so you could find more information if you needed it.

I'm not being paid to read this mailing list, nor to write to it.  
I'm not paid to read the list you're asking me to read to help 
someone with a problem I'm also not being paid to help them with.  
This is my _personal_ time we're talking about here, and _I_ 
decide what I will do in my personal time.


>Given you are *THE* Xfree86 guy at Red Hat, I hopped you would
>have seen this before, and know a solution.

That doesn't mean that I have seen it before and/or do have a 
solution however.  It certainly doesn't hurt to ask me, but to 
expect me to run across the internet on my own time as a 
volunteer to do so is a bit presumptuous.

>I didn't expect you to fix it. Knowing it should or shouldn't
>work would have been a big help.  I have no clue about this
>chip, or any other S3 product. When I saw the X log, the
>multiple detections looked like something that might have been
>seen before.

Oh I've seen things similar before.  Generally it is some 
motherboard chipset that the X server doesn't quite "grok", 
perhaps even a buggy chipset that the server doesn't handle and 
needs to workaround.  Other times it is bad "assumptions" in the 
XFree86 PCI code.  Other times it is really really weirdo 
hardware, such as on some ia64 or other architectures which have 
a seriously different PCI layout.


>| Any help I give on this, or any other mailing list, isn't my
>| _job_, it is volunteerism, like anyone else.
>
>So I/he put(s) it in bugzilla, where you see it in 3 months when
>you get a chance to look at RHL9 bugs, and close it as WONTFIX,
>since RHL9 is no longer supported.

Hey, I'm no miracle worker dude.  There are over 450, if not 500 
bugs in bugzilla assigned to me.  While I'm the one who is on the 
incoming end of those reports, there's no way in hell I could 
personally fix every single one of those issues in a 40 hour week 
and keep the bug count at 0, or even near 100.  Like anyone, I 
have to prioritize bug reports that come in based on various 
factors, and fix the biggest bang for the buck things that matter 
the most.  I also do more than just fix bugs in XFree86 too.

So yes, some issues will sit around for 2 years and never get 
fixed.  Yes, some people might get pissed off about that, and 
even might get pissed off at _me_ about that.  I can understand 
their frustration, and have experienced such frustration myself, 
as I am an OSS end user just like everyone else.  I'm not going 
to work an 120 hour week however just to avoid someone getting 
upset.

If you think your problem will be considered low priority and
never get looked at, or wont get looked at in bugzilla for 4
months or 8 months, by all means don't bother filing it at all.  
I completely openly acknowledge that one human being can't fix
500 bug reports and so there are going to be people pissed off
that they have filed a bug report and it is still open 6 months
later.  If someone is going to make things personal however, and
bitch about it to me directly, then yes, I am going to take it
personally, and I will have some things to say about the other 
side of the story too.


>If you had no knowledge of this card or getting it to work, just
>say so. No need to tell me I'm asking too much. Just tell me you
>don't know the answer (or ignore the message).

Hey, I do like to help people.  Why do you think I spend my time 
trying to do so?  I obviously don't have a solution for every 
single problem out there, nor does anyone.  Nor do I have the 
time to even look into 1/10th of the problems that exist.

When I'm working on stuff on Red Hat time, it's done on a
prioritized basis of what is best for Red Hat as a whole, and our
products.

When I'm working on stuff on _my_ time, it's done on a
prioritized basis of what seems interesting to me personally, and
what I find enjoyable, including helping others on mailing lists
like this one.  However, there are limitations on how far I will
go to help someone on my own personal time, and under what
circumstances.

In this volunteer world, the volunteers don't _owe_ anyone
anything afterall.  So if someone comes to me with a problem, as 
long as it is interesting to me and/or enjoyable to fiddle with, 
great, I usually do if I have the time.  If it isn't, then 
they've got the bugzilla option, and that will of course get 
weighed against all other existing priorities and reported 
defects, etc.

People who have problems are also encouraged themselves to join
the open source community and volunteer.  Submitting patches that
fix a bug is a great way to "give back", by helping all other
users that have the same problem, and to share the joyous feeling
of helping someone else.

Share the joy!

-- 
Mike A. Harris