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 _______________________________________________ xfree86-list mailing list xfree86-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/xfree86-list IRC: #xfree86 on irc.redhat.com
