Hello,
yes I know, you don't like modules without full sources available.
But Nvidia is the leading vendor of video cards and all 2.4.x
kernels up to 2.4.13-pre5 work nice with this module.
Running pre6 I get
(==) NVIDIA(0): Write-combining range (0xf0000000,0x2000000)
(EE) NVIDIA(0): Failed to allocate LUT context DMA
(EE) NVIDIA(0): *** Aborting ***
This is Nvidia's 1.0-1541 version of its Linux drivers
Please keep this driver going during the 2.4.x series of the
kernel if at all possible.
Thanks for looking into it,
Helmut Jarausch
Inst. of Technology
RWTH Aachen
Germany
Please CC to my private email
[email protected]
On Mon, 22 Oct 2001 [email protected] wrote:
> Hello,
>
> yes I know, you don't like modules without full sources available.
We can't debug them. End of story. BTW, I _really_ doubt that even
NVidia folks could do something useful with your bug report, source
or not - insufficient details to do anything.
Please take this issue up with the provider of that driver. If they
were to provide source for the driver, we'd be glad to help you, but
unfortunately that is not the case.
-ben
On Mon, Oct 22, 2001 at 08:45:22PM +0200, [email protected] wrote:
> Hello,
>
> yes I know, you don't like modules without full sources available.
> But Nvidia is the leading vendor of video cards and all 2.4.x
> kernels up to 2.4.13-pre5 work nice with this module.
>
> Running pre6 I get
> (==) NVIDIA(0): Write-combining range (0xf0000000,0x2000000)
> (EE) NVIDIA(0): Failed to allocate LUT context DMA
> (EE) NVIDIA(0): *** Aborting ***
>
>
> This is Nvidia's 1.0-1541 version of its Linux drivers
>
> Please keep this driver going during the 2.4.x series of the
> kernel if at all possible.
>
> Thanks for looking into it,
>
> Helmut Jarausch
>
> Inst. of Technology
> RWTH Aachen
> Germany
>
>
> Please CC to my private email
>
> [email protected]
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
"I can't tell you how many bridges I've jumped off of -- all I get is wet."
On Mon, 22 Oct 2001 [email protected] wrote:
> yes I know, you don't like modules without full sources available.
> But Nvidia is the leading vendor of video cards and all 2.4.x
> kernels up to 2.4.13-pre5 work nice with this module.
So get NVIDIA to release the source code for their driver,
this would allow you to recompile the driver and make it
work again.
Note that once NVIDIA stops selling this model video card
you're stuck with the last supported version of Linux anyway
and won't be able to upgrade.
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed)
http://www.surriel.com/ http://distro.conectiva.com/
Rik van Riel wrote:
>
> On Mon, 22 Oct 2001 [email protected] wrote:
>
> > yes I know, you don't like modules without full sources available.
> > But Nvidia is the leading vendor of video cards and all 2.4.x
> > kernels up to 2.4.13-pre5 work nice with this module.
>
> So get NVIDIA to release the source code for their driver,
> this would allow you to recompile the driver and make it
> work again.
>
> Note that once NVIDIA stops selling this model video card
> you're stuck with the last supported version of Linux anyway
> and won't be able to upgrade.
Actually, NVIDIA has a HAL-type thing going on and their drivers will support all of their cards from the TNT on up to
the GeForce 3. The only unsupported models are the Riva128 and Riva128ZX.
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Mon, 22 Oct 2001 20:45:22 +0200 (CEST) [email protected] wrote:
> [...]
> Running pre6 I get
> (==) NVIDIA(0): Write-combining range (0xf0000000,0x2000000)
> (EE) NVIDIA(0): Failed to allocate LUT context DMA
> (EE) NVIDIA(0): *** Aborting ***
Probably you should do additional checks. I run a GeForce II MX here with
exactly this driver and pre6 - and have no problem at all. I tried both driver
version 1251 and 1541, and both work.
Of course I do not back the manufacturers' religion "we don't wanna show people
how we managed to make a kernel driver 800kB of size". Only I believe this is
no real loss, as nobody wants to follow this god anyway.
:-)
Regards,
Stephan
AFAIK you can use Riva128 cards with X4's "nv" driver. Oh, I see, you
meant with Nvidia's binary-only driver "nvidia." Nevermind then. :)
---
Dan Chen [email protected]
GPG key: http://www.cs.unc.edu/~chenda/pubkey.gpg.asc
On Mon, 22 Oct 2001, Christopher Friesen wrote:
> Actually, NVIDIA has a HAL-type thing going on and their drivers will support all of their cards from the TNT on up to
> the GeForce 3. The only unsupported models are the Riva128 and Riva128ZX.
> Please keep this driver going during the 2.4.x series of the
> kernel if at all possible.
Only Nvidia can help you
On Mon, Oct 22, 2001 at 09:24:11PM +0100, Alan Cox wrote:
> Only Nvidia can help you
With a problem caused by someone else and not them? Interesting viewpoint. I
also find it interesting that people think NVidia is the sole company in control
of whether or not ther drivers are opened considering SGI and other 3rd parties
own code in the 'driver pie'. This is a simplistic naive view IMHO....
> > Only Nvidia can help you
>
> With a problem caused by someone else and not them? Interesting viewpoint. I
> also find it interesting that people think NVidia is the sole company in control
> of whether or not ther drivers are opened considering SGI and other 3rd parties
> own code in the 'driver pie'. This is a simplistic naive view IMHO....
I can't debug Nvidia's code even to see why it might have broken. Its as
simple as that - no politics, no agenda on them opening it, simple technical
statement of fact.
I really doubt Nvidia will open their driver code. I've heard them explain
some of the reasons they don't and in part they make complete sense.
[email protected] writes:
> On Mon, Oct 22, 2001 at 09:24:11PM +0100, Alan Cox wrote:
> > Only Nvidia can help you
>
> With a problem caused by someone else and not them? Interesting
> viewpoint.
Binary modules can screw the kernel in arbitrary ways. If you can
reproduce a problem without thenmloaded, people on l-k will listen to
you.
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
[email protected] <[email protected]> wrote:
> On Mon, Oct 22, 2001 at 09:24:11PM +0100, Alan Cox wrote:
> > Only Nvidia can help you
>
> With a problem caused by someone else and not them? Interesting viewpoint.
No, just pragmatism. If you have a binary-only module loaded and
encounter any sort of bug (whether apparently related to that module or
not), the module author/publisher is the only one who can help.
It's a matter of who has the source code.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[email protected]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------
[email protected] wrote:
>
> On Mon, Oct 22, 2001 at 09:24:11PM +0100, Alan Cox wrote:
> > Only Nvidia can help you
>
> With a problem caused by someone else and not them? Interesting viewpoint.
Not really. If a change is made to the kernel, people can't roll any
relevant changes into nvidia's driver because only nvidia has the
source. For example, if the PCI driver interface was changed, then that
too would likely break nvidia's driver. However, it wouldn't break the
open-source drivers because the changes would be merged into them.
As soon as nvidia releases an open-source driver, then you can blame the
kernel developers for breaking the driver.
-Jeff
--
Jeff Golds
Sr. Software Engineer
[email protected]
[email protected] said:
[...]
> Please keep this driver going during the 2.4.x series of the
> kernel if at all possible.
Wrong address, dude. Complain to nVidia.
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
On Mon, Oct 22, 2001 at 11:50:59PM +0100, Alan Cox wrote:
> I can't debug Nvidia's code even to see why it might have broken. Its as
> simple as that - no politics, no agenda on them opening it, simple technical
> statement of fact.
On one side I can see this, on the other I can't. For example, no matter how
many times a user visits windows update, chances are his drivers will still work
with his current version of windows. Admittedly, some may not consider this a
feature, but I think a lot do. Why should a 'stable' kernel series break
existing drivers?
> I really doubt Nvidia will open their driver code. I've heard them explain
> some of the reasons they don't and in part they make complete sense.
Microsoft deals with companies that won't always give them access to the drivers
directly, but often they will tell users workarounds, or at least attempt to
gather enough knowledge since they are tehnically the OS vendor to give to the
driver provider to fix the problem. If you are the OS provider, and a change you
make breaks user drivers/programs generally I think it's a polite gesture to at
least attempt to find out what's going on and then pass that information on to
the people who can properly handle it...
On Mon, Oct 22, 2001 at 08:31:59PM -0500, [email protected] wrote:
> On Mon, Oct 22, 2001 at 11:50:59PM +0100, Alan Cox wrote:
> > I can't debug Nvidia's code even to see why it might have broken. Its as
> > simple as that - no politics, no agenda on them opening it, simple technical
> > statement of fact.
> On one side I can see this, on the other I can't. For example, no matter how
> many times a user visits windows update, chances are his drivers will still work
> with his current version of windows. Admittedly, some may not consider this a
Really? Sure as hell hasn't been my experience. Oh! That only
works with Windows 95! Ok, now you can get the driver to support Windows
98 but it won't support Windows NT (got one RIGHT NOW like that). Oops,
you upgraded to Windows 2000, can't support that with that driver, we
don't have a driver for that yet. Windows XP, sorry, we don't have the
Windows XP certified driver, yet, try back in a few months.
Think that's a joke? I think it's pathetic and it is EXACTLY
what I have experienced with multimedia cards, scanners, and printers.
> feature, but I think a lot do. Why should a 'stable' kernel series break
> existing drivers?
Why would Windows XP break all the non-MS Windows 2000 drivers
(don't you dare tell me it didn't, I work at a place that got slammed by
their shit). Why would things that work on Windows 98 (Delorme Eartha
DVD) not work on Windows NT or Windows 2000. The Windows mess is a swamp
out there of what drivers work with what version (some don't even work
between the original editions and updated editions - Windows 95 had
three editions that I have in hand).
> > I really doubt Nvidia will open their driver code. I've heard them explain
> > some of the reasons they don't and in part they make complete sense.
> Microsoft deals with companies that won't always give them access to the drivers
> directly, but often they will tell users workarounds, or at least attempt to
> gather enough knowledge since they are tehnically the OS vendor to give to the
> driver provider to fix the problem. If you are the OS provider, and a change you
> make breaks user drivers/programs generally I think it's a polite gesture to at
> least attempt to find out what's going on and then pass that information on to
> the people who can properly handle it...
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
The readme for their NVdriver explicitly states "All official stable kernel releases from 2.2.12 and up are supported;
"prerelease" versions such as "2.4.3-pre2" are not supported, nor are
development series kernels such as 2.3.x or 2.5.x."
Appendix B, http://www.nvidia.com/docs/lo/1021/SUPP/README.txt
Run a release kernel with thier driver, let them worry about the changes, since they have the linux source, and the kernel developers do not have thiers.
On Mon, Oct 22, 2001 at 09:43:24PM -0400, Michael H. Warfield wrote:
> Really? Sure as hell hasn't been my experience. Oh! That only
> works with Windows 95! Ok, now you can get the driver to support Windows
> 98 but it won't support Windows NT (got one RIGHT NOW like that). Oops,
> you upgraded to Windows 2000, can't support that with that driver, we
> don't have a driver for that yet. Windows XP, sorry, we don't have the
> Windows XP certified driver, yet, try back in a few months.
> Think that's a joke? I think it's pathetic and it is EXACTLY
> what I have experienced with multimedia cards, scanners, and printers.
> Why would Windows XP break all the non-MS Windows 2000 drivers
> (don't you dare tell me it didn't, I work at a place that got slammed by
> their shit). Why would things that work on Windows 98 (Delorme Eartha
> DVD) not work on Windows NT or Windows 2000. The Windows mess is a swamp
> out there of what drivers work with what version (some don't even work
> between the original editions and updated editions - Windows 95 had
> three editions that I have in hand).
Hmm...where did I say once that the user upgraded their version of windows?
Note, I said windows 'update', not windows 'upgrade'. Theoretically, based off
the whole "odd", "even", "stable", "unstable" numbering system that was given,
Kernel 2.4.x should be one 'version', and should not randomly break
programs/drivers during it's 'completely bugfix' development? I wonder how much
more driver support we might see under Linux if it didn't break compatability
with existing drivers so much...
It could be said that at least windows has a somewhat "stable" (in the sense
that it doesn't change very often) driver API, something that Linux apparently
lacks currently. Stability comes from a lack of feature creep, and that's
something that Linux doesn't have currently.
It seems as if a user is forced to upgrade to a newer minor 'kernel revision'
often to gain hardware support even though other things may break because
interfaces may have changed. Compare this to windows, where the "Windows 98"
driver API changed very little (AFAIK) and it was pretty much guranteed that no
matter how many times a user "updated" his copy of Windows 98 (note that I did
not say NT) with service packs and or other fixes to his system his drivers
would still work, and where a user can often obtain updated device support
simply by upgrading his drivers instead of upgrading his core operating system.
Contrast this with Linux where the 'helter skelter, we can break stuff because
we know better' attitude, and you begin to see why so many companies might not
be intereseted in supporting Linux at all.
It seems as if the very model of the kernel precludes a vendor's ability to
produce a driver and have it work with almost the entire series of a particular
kernel 'release', such as 2.4, contrast this with windows where often a specific
driver may work for the entire period of that particular release...
I am advocating Windows? Hardly. What I am advocating is a little bit more
sanity. The OS should not break compatability with existing drivers so often for
a 'stable' release. I know that i'm not the only one here that is quite tired of
upgrading to newer versions of the kernel to fix some bugs, only to receive a
plethora of mind boggling hardware crashing others and to find that suddenly
their drivers don't work correctly any more. We've seen arguments over the
'stable' release series regarding the VM code, I won't even go there, but I
think it proves that I'm not the only one that finds "2.4.x's" tendency to break
things and pay for them later more than annoying...
Now of course, there is nothing here to say that the kernel has in any way
broken support with the NVidia driver, obviously this discussion is far beyond
that point, and it is rather irrelevant. I believe my above discussion is the
real root of the matter, and the NVidia driver is only an example of the real
issue. It's very possible that something else broke the driver for this user and
without the proper test data reported by the user (which was admittedly rather
sparse to begin with) very little debugging can be done and very little help can
be given...
This of course comes from my somewhat limited experience in the software
development business market, and as always YMMV...
----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Sent: Monday, October 22, 2001 7:16 PM
Subject: Re: 2.4.13-pre6 breaks Nvidia's kernel module
> On Mon, Oct 22, 2001 at 09:43:24PM -0400, Michael H. Warfield wrote:
> > Really? Sure as hell hasn't been my experience. Oh! That only
> > works with Windows 95! Ok, now you can get the driver to support
Windows
> > 98 but it won't support Windows NT (got one RIGHT NOW like that). Oops,
> > you upgraded to Windows 2000, can't support that with that driver, we
> > don't have a driver for that yet. Windows XP, sorry, we don't have the
> > Windows XP certified driver, yet, try back in a few months.
>
> > Think that's a joke? I think it's pathetic and it is EXACTLY
> > what I have experienced with multimedia cards, scanners, and printers.
>
> > Why would Windows XP break all the non-MS Windows 2000 drivers
> > (don't you dare tell me it didn't, I work at a place that got slammed by
> > their shit). Why would things that work on Windows 98 (Delorme Eartha
> > DVD) not work on Windows NT or Windows 2000. The Windows mess is a
swamp
> > out there of what drivers work with what version (some don't even work
> > between the original editions and updated editions - Windows 95 had
> > three editions that I have in hand).
>
> Hmm...where did I say once that the user upgraded their version of
windows?
> Note, I said windows 'update', not windows 'upgrade'. Theoretically, based
off
> the whole "odd", "even", "stable", "unstable" numbering system that was
given,
> Kernel 2.4.x should be one 'version', and should not randomly break
> programs/drivers during it's 'completely bugfix' development? I wonder how
much
> more driver support we might see under Linux if it didn't break
compatability
> with existing drivers so much...
look buddy, you don't get it
without access to nvidia's source, we can't know what it does, where it does
it, and what we can break by doing what to the kernel
WE CAN NOT KNOW SO WE CAN NOT PREVENT IT
it is THAT simple
complain to nvidia, not the people that CAN NOT DO ANYTHING ABOUT IT
On Mon, Oct 22, 2001 at 09:44:41PM -0700, Nicholas Knight wrote:
> look buddy, you don't get it
> without access to nvidia's source, we can't know what it does, where it does
> it, and what we can break by doing what to the kernel
> WE CAN NOT KNOW SO WE CAN NOT PREVENT IT
> it is THAT simple
> complain to nvidia, not the people that CAN NOT DO ANYTHING ABOUT IT
Thanks for the all caps, I love being deafened. However, I do "get it buddy."
Secondly, I don't believe for a second that it isn't possible to trace things
down even in a 'binary-only' driver. I trace things down in a 'binary-only'
program every day practically when dealing with software, many times having the
source to a program doesn't even help me. Often I find myself using strace or
some other program to trace the execution flow of a program because it is often
more informative then the poorly written source.
I'm not complaining about the NVidia driver here. I'm simply stating that IMHO,
I find it odd that for years microsoft has not only retained binary
compatability within a release of windows but API compatability. There should
not be a change to the kernel that would require changes in the driver in a
"stable development" release tree, it's really that simple in my perhaps
somewhat limited view. Admittedly, this breakage (which is still in doubt) that
might have happened did happen with a "pre" version, but I feel this response
would have been no different even if that was not the case.
And as I've mentioned before, I know of specific cases (which I'm not allowed to
divulge) where microsoft did not have access to the vendor's source to a
specific driver, but they collected information that was then forwarded on to
the vendor to handle the request. Nowhere during this entire 'discussion' did I
see an offer to help the user possibly collect that information in a manner that
would be helpful to the vendor, nor an offer of somewhat more information
than "go cry to your vendor, you poor sap" effectively. That is what, if
anything, I'm complaining about.
I deal with issues often day during the course of developing software for my
company that are often caused by other vendor's software, but does that mean I
can tell all my customers "I'm sorry, a change I made or a bug in your vendor's
software prevents this from functioning properly, and I can't help you at all."
My customers wouldn't accept that answer for a minute, they demand something
more than "sorry, it's not my fault." Often times we spend a good amount of time
researching and finding a way to work around the issues with that vendor's
product, which sometimes even involve "fixes" to our own product that exist for
no other reason than because of that vendor's issues. And guess what, we still
have customers :) And considering we're a somewhat small business in a dismal
economy I attribute part of our success to that very thing...
If the binary only module in question sticks with the "published
interface" (as is required) isn't it a problem in Linux then?
} look buddy, you don't get it
} without access to nvidia's source, we can't know what it does, where it does
} it, and what we can break by doing what to the kernel
} WE CAN NOT KNOW SO WE CAN NOT PREVENT IT
} it is THAT simple
} complain to nvidia, not the people that CAN NOT DO ANYTHING ABOUT IT
[email protected] wrote:
> I'm not complaining about the NVidia driver here. I'm simply stating that IMHO,
> I find it odd that for years microsoft has not only retained binary
> compatability within a release of windows but API compatability.
That's simply note true, as many windows
users have pointed out to you.
> There should
> not be a change to the kernel that would require changes in the driver in a
> "stable development" release tree, it's really that simple in my perhaps
> somewhat limited view. Admittedly, this breakage (which is still in doubt) that
> might have happened did happen with a "pre" version, but I feel this response
> would have been no different even if that was not the case.
nvidia is the party who maintains the nvidia driver -
and they have stated that they do not support "pre"
kernel releases. Therefore, you ought to stick with
official releases.
(Funny, I never have that problem with my voodoo3!)
Also, you mentioned "customers" - most customers
would take a dim view of a sys admin who reboots
systems left and right to try various "pre" kernels!
You had best install the distro and leave it at that,
except of course that you keep up with updates.
cu
jjs
Sounds like Linux is slowly crawling towards the WHQL perspective on
drivers from Microsoft. If they aren't qualified:
Microsoft == WHQL
Linux == ((!tainted) + EXPORT_SYMBOL_GPL() + ...)
... then they aren't supportable or acceptable for distribution by
anyone other than the creators.
I wouldn't be surprised if someone creates a LHQL process or
business to qualify binary drivers on supportable kernels from
distributions. I'd give it about a year.
--Matt
"Michael H. Warfield" wrote:
> Really? Sure as hell hasn't been my experience. Oh! That only
> works with Windows 95! Ok, now you can get the driver to support Windows
> 98 but it won't support Windows NT (got one RIGHT NOW like that). Oops,
> you upgraded to Windows 2000, can't support that with that driver, we
> don't have a driver for that yet. Windows XP, sorry, we don't have the
> Windows XP certified driver, yet, try back in a few months.
>
> Think that's a joke? I think it's pathetic and it is EXACTLY
> what I have experienced with multimedia cards, scanners, and printers.
----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Monday, October 22, 2001 10:08 PM
Subject: Re: 2.4.13-pre6 breaks Nvidia's kernel module
> On Mon, Oct 22, 2001 at 09:44:41PM -0700, Nicholas Knight wrote:
> > look buddy, you don't get it
> > without access to nvidia's source, we can't know what it does, where it
does
> > it, and what we can break by doing what to the kernel
> > WE CAN NOT KNOW SO WE CAN NOT PREVENT IT
> > it is THAT simple
> > complain to nvidia, not the people that CAN NOT DO ANYTHING ABOUT IT
>
> Thanks for the all caps, I love being deafened. However, I do "get it
buddy."
> Secondly, I don't believe for a second that it isn't possible to trace
things
> down even in a 'binary-only' driver. I trace things down in a
'binary-only'
> program every day practically when dealing with software, many times
having the
> source to a program doesn't even help me. Often I find myself using strace
or
> some other program to trace the execution flow of a program because it is
often
> more informative then the poorly written source.
>
> I'm not complaining about the NVidia driver here. I'm simply stating that
IMHO,
> I find it odd that for years microsoft has not only retained binary
> compatability within a release of windows but API compatability. There
should
Only within a single kernel.
How many releases of windows have a kernel upgrade avalible? *POSSIBLY*
occasional changes to the kernel bewteen NT service packs, and those service
packs have a tendancy to break third party drivers.
There are at least 2, possibly 3 releases of Win95, there are a number of
drivers that work with one but not another.
Win98 and Win98SE seem for the most part to retain compatability, but then,
I doubt there was anything much changed in the kernel (but then we wouldn't
know that for sure since we don't have the source).
Here, we're dealing with changes to the core of the operating system, if you
don't like it, do as another person suggested, install one version and stick
with it, don't upgrade until you're ready to deal with old drivers not
working with new versions. Consider each release of the kernel to be
equivilant to a new release of windows as far as binary-only drivers go,
same old programs will *probably* run, but drivers can go out the window.
> not be a change to the kernel that would require changes in the driver in
a
> "stable development" release tree, it's really that simple in my perhaps
What if it was a bug fix that caused the driver to break? What if it was a
fix to 3 other drivers? We won't really know for sure since we don't have
the source, nor can we prevent further breakage in the future for the same
reason.
> somewhat limited view. Admittedly, this breakage (which is still in doubt)
that
> might have happened did happen with a "pre" version, but I feel this
response
> would have been no different even if that was not the case.
Would you have run mid-development 2.3 kernels in a production environment
that you weren't prepared to have things break in? Then why are you running
a -pre version and complaining that it's "linux's fault" that a third-party
binary-only driver that does things we may not know about breaks? nVidia
will likely have a fix out around the time or before 2.4.13 is released as
final, which is as it should be, nVidia owns the code and maintains it,
they're the ones that make it work with a new version, not the people that
don't have access to the code.
>
> And as I've mentioned before, I know of specific cases (which I'm not
allowed to
> divulge) where microsoft did not have access to the vendor's source to a
> specific driver, but they collected information that was then forwarded on
to
> the vendor to handle the request. Nowhere during this entire 'discussion'
did I
> see an offer to help the user possibly collect that information in a
manner that
> would be helpful to the vendor, nor an offer of somewhat more information
> than "go cry to your vendor, you poor sap" effectively. That is what, if
> anything, I'm complaining about.
Does anyone here have reliable contacts with nVidia that'll actually get
something done in a reasonable time? Faster than if nVidia just tested the
new kernels as they likely do quite often and found the problem themselves
and had all possible information avalible immiediately? Hmm...
>
> I deal with issues often day during the course of developing software for
my
> company that are often caused by other vendor's software, but does that
mean I
> can tell all my customers "I'm sorry, a change I made or a bug in your
vendor's
> software prevents this from functioning properly, and I can't help you at
all."
> My customers wouldn't accept that answer for a minute, they demand
something
*Customers* ? What customers? Where exactly is this guy paying anyone here
for support or to maintain the code?
> more than "sorry, it's not my fault." Often times we spend a good amount
of time
> researching and finding a way to work around the issues with that vendor's
> product, which sometimes even involve "fixes" to our own product that
exist for
Kernel developers spend a significant amount of time trying to work around
problems in third party products, or did you not notice the PCI quirks, and
other workarounds present in the kernel? Did you not notice the EXTENSIVE
discussions on the VIA KT133A problems? The extensive time spent trying to
track down what was going on? I spent probably 4 to 6 hours over the course
of a few days just collecting and looking at information, multiply that for
all the people who sent me reports for the time they spent trying to figure
out what the problem was, recompiling kernels, messing with hardware, trying
alternate CPU's, etc. etc. etc. comes out to about 240 to 360 man hours, 10
to 15 man days. This doesn't include the time several developers spent
trying new code, and all the people before my initial requests who spent
extensive time debugging and trying new code.
And, in that case, we had access to all the source for the code involved,
plus several applicable technical documents.
Now you're asking developers to debug a third-party driver that the source
is not avalible for, that we don't know exactly what it accesses, what it
does, what information it sends to the hardware, what information it gets
from the kernel, etc.
Could it be a one-liner and take 20 minutes to track down with one
developer? maybe, but then again, could be a hell of a lot more trouble, and
this is to fix a third-party driver that in the opinion of many people
shouldn't even be allowed to touch the kernel, much less make it the
responsability of Linux developers to deal with its problems.
> no other reason than because of that vendor's issues. And guess what, we
still
> have customers :) And considering we're a somewhat small business in a
dismal
> economy I attribute part of our success to that very thing...
Guess what? We don't have customers, never did. Companies like Red Hat have
customers, and those companies even employ some kernel developers, if they
want to have their employees work on the problem, fine, that's their
perogative, and I'm sure there would be people that are quite grateful, and
might even buy their product because of it. but in general, linux kernel
developers won't be able to, nor will they try to, fix a problem with a
binary-only driver.
[email protected] wrote:
> Secondly, I don't believe for a second that it isn't possible to trace things
> down even in a 'binary-only' driver.
Sure it is possible, for someone with lots of time to waste. And it
_is_ a
waste of time, because it can be traced down so much faster _with_ the
source.
But what would the point be? Even if the kernel developers discover
a problem in the nvidia driver - what could they do? Create a binary
patch?
> I trace things down in a 'binary-only'
> program every day practically when dealing with software, many times having the
> source to a program doesn't even help me. Often I find myself using strace or
> some other program to trace the execution flow of a program because it is often
> more informative then the poorly written source.
>
> I'm not complaining about the NVidia driver here. I'm simply stating that IMHO,
> I find it odd that for years microsoft has not only retained binary
> compatability within a release of windows but API compatability.
Lucky you. I have seen third-party software break on the transition
from
windows95 to windows95 osr2 (or whatever they called that update)
> There should
> not be a change to the kernel that would require changes in the driver in a
> "stable development" release tree, it's really that simple in my perhaps
> somewhat limited view. Admittedly, this breakage (which is still in doubt) that
> might have happened did happen with a "pre" version, but I feel this response
> would have been no different even if that was not the case.
>
It doesn't work that way. There is no "stable api" guarantee. People
try
for stable api's, but break them when doing so is useful.
> And as I've mentioned before, I know of specific cases (which I'm not allowed to
> divulge) where microsoft did not have access to the vendor's source to a
> specific driver, but they collected information that was then forwarded on to
> the vendor to handle the request. Nowhere during this entire 'discussion' did I
> see an offer to help the user possibly collect that information in a manner that
> would be helpful to the vendor, nor an offer of somewhat more information
> than "go cry to your vendor, you poor sap" effectively. That is what, if
> anything, I'm complaining about.
Nvidia has plenty of offers for help. I am sure they will get it if
they
ask about "how should we adapt to this changed API". No problem there.
And
there is an even better offer: GPL the driver, get it clean enough to
integrate it in the Linus tree, and this sort of thing won't happen!
Kernel internal API's change from time to time, but all affected drivers
in the Linus tree is usually fixed along with the change. But they
won't take that offer, so they have to do the work themselves.
Note that a partial solution is possible too. They could put their
secret
code in a binary module, and release source for a module that interface
to the secret one. Then they'll have a perfectly stable interface
between the modules, and people can adapt the GPL interface module
to changing kernels. They don't seem to do that either.
> I deal with issues often day during the course of developing software for my
> company that are often caused by other vendor's software, but does that mean I
> can tell all my customers "I'm sorry, a change I made or a bug in your vendor's
> software prevents this from functioning properly, and I can't help you at all."
> My customers wouldn't accept that answer for a minute, they demand something
> more than "sorry, it's not my fault." Often times we spend a good amount of time
> researching and finding a way to work around the issues with that vendor's
> product, which sometimes even involve "fixes" to our own product that exist for
> no other reason than because of that vendor's issues. And guess what, we still
> have customers :) And considering we're a somewhat small business in a dismal
> economy I attribute part of our success to that very thing...
Distributors can do what you want. They may stick to an older kernel
until
nvidia fix their driver, or undo the particular patch that broke nvidia.
Many distributions have their own patch-sets for this sort of thing.
The responsibility for this falls on you the moment you go and grab
the kernel source though. This is equivalent to getting the latest
daily build directly from the microsoft developers instead of buying
the released upgrades.
The difference is that youy actually _can_ get the latest linux build.
But you don't have to do that - you can stick to the larger distributors
who probably won't release a kernel without nvidia support. They care
about customers, so stick to them if you consider yourself one.
The raw kernel source is for "interested people", not for "customers".
Helge Hafting
[email protected] wrote:
> Hello,
>
> yes I know, you don't like modules without full sources available.
> But Nvidia is the leading vendor of video cards and all 2.4.x
> kernels up to 2.4.13-pre5 work nice with this module.
>
> Running pre6 I get
> (==) NVIDIA(0): Write-combining range (0xf0000000,0x2000000)
> (EE) NVIDIA(0): Failed to allocate LUT context DMA
> (EE) NVIDIA(0): *** Aborting ***
>
>
> This is Nvidia's 1.0-1541 version of its Linux drivers
I use the same version of the driver with my Geforce3 and I am also
running 2.4.13-pre6 and it works just fine so I don't agree with you
that it breaks...
You do know that there are a few files that need to be recompiled every
time you build a new kernel - right?
See "http://www.nvidia.com/docs/lo/1021/SUPP/README.txt" for details.
Here's a quote from that file explaining what I do myself - that should
work for you:
"
INSTALLING/UPGRADING BY TAR FILE Instructions for the Impatient:
$ tar xvzf NVIDIA_kernel.tar.gz
$ tar xvzf NVIDIA_GLX.tar.gz
$ cd NVIDIA_kernel
$ make install
$ cd ../NVIDIA_GLX
$ make install
Instructions:
To install from tar file, unpack each file:
$ tar xvzf NVIDIA_kernel.tar.gz
$ tar xvzf NVIDIA_GLX.tar.gz
cd into the NVIDIA_kernel directory. Type 'make install'. This will
compile the kernel interface to the NVdriver, link the NVdriver, copy
the NVdriver into place, and attempt to insert the NVdriver into the
running kernel:
$ cd NVIDIA_kernel
$ make install
Next, move into the NVIDIA_GLX directory. Type 'make install' -- this
will copy the needed OpenGL and XFree86 files into place:
$ cd ../NVIDIA_GLX
$ make install
Note that the "make install" for each package will remove any previously
installed NVIDIA drivers.
"
Best regards,
Jesper Juhl
[email protected] said:
> What I am advocating is a little bit more sanity. The OS should not
> break compatability with existing drivers so often for a 'stable'
> release.
Name a driver in the 2.4.13-pre6 tree which doesn't compile and work with
the 2.4.13-pre6 kernel.
We don't care about binary-only modules. That policy is fixed in stone - if
you don't like it, you are missing the point of what many of us are here
for. In which case, please go away and stop trolling.
On 7 Feb 1999, [email protected] wrote:
> I _refuse_ to even consider tying my hands over some binary-only module.
>
> <...>
>
> Basically, I want people to know that when they use binary-only modules,
> it's THEIR problem. I want people to know that in their bones, and I
> want it shouted out from the rooftops. I want people to wake up in a
> cold sweat every once in a while if they use binary-only modules.
(ref: http://lwn.net/1999/0211/a/lt-binary.html)
--
dwmw2
Exactly... read supplier's manuals pays well. 2.4.13-pre6+nvidia drvs
1541+GeForce2MX400 works for me perfectly.
But some other problem appeared - there's something strange probably in
nvidia framebuffer console code. Starts up nicely, X works too, including
"openuniverse", but after returning to console (regularly or by
Ctrl+Alt+Backspace), I see few standard messages and box gets frozen.
Background sound playing also stops (it repeats playing last data in
buffer). Keyboard driver works (num+scr+caps locks are reacting at least),
but is ignored by the system. Command line also doesn't appear.
I didn't try to log into via network, cause my second box is presently not
complete, anyway I wouldn't expect any reaction from such frozen box.
Well, I stopped using nvidia framebuffer console driver and all works
nicely.
---
Some time ago I had BIG troubles with AGP working at 4X - I had to degrade
AGP to 2X (in BIOS) and all works fine now (but slower, of course).Also
kernel compilation in X terminal made system freezed, but not so badly as
the console driver did - I was still able to login via network, just to see
that X server makes 100% load, is not killable and the system ignores
shutdown commands...
My GeForce card is manufactured by some Manli company, and I use it with ECS
K7VZA board (older 686A model).
Hard to say if problem is in card or motherboard. 250VA power source could
be strong enough to drive everything...
bye
Petr
>
>
> -----P?vodn? zpr?va-----
> Od: Jesper Juhl [SMTP:[email protected]]
> Odesl?no: 23. ??jna 2001 11:06
> Komu: [email protected]
> Kopie: [email protected]
> P?edm?t: Re: 2.4.13-pre6 breaks Nvidia's kernel module
>
>
> [email protected] wrote:
>
> > Hello,
> >
> > yes I know, you don't like modules without full sources available.
> > But Nvidia is the leading vendor of video cards and all 2.4.x
> > kernels up to 2.4.13-pre5 work nice with this module.
> >
> > Running pre6 I get
> > (==) NVIDIA(0): Write-combining range (0xf0000000,0x2000000)
> > (EE) NVIDIA(0): Failed to allocate LUT context DMA
> > (EE) NVIDIA(0): *** Aborting ***
> >
> >
> > This is Nvidia's 1.0-1541 version of its Linux drivers
>
> I use the same version of the driver with my Geforce3 and I am also
> running 2.4.13-pre6 and it works just fine so I don't agree with you
> that it breaks...
> You do know that there are a few files that need to be recompiled every
> time you build a new kernel - right?
>
> See "http://www.nvidia.com/docs/lo/1021/SUPP/README.txt" for details.
>
> Here's a quote from that file explaining what I do myself - that should
> work for you:
>
> "
> INSTALLING/UPGRADING BY TAR FILE Instructions for the Impatient:
>
> $ tar xvzf NVIDIA_kernel.tar.gz
> $ tar xvzf NVIDIA_GLX.tar.gz
> $ cd NVIDIA_kernel
> $ make install
> $ cd ../NVIDIA_GLX
> $ make install
>
> Instructions:
>
> To install from tar file, unpack each file:
> $ tar xvzf NVIDIA_kernel.tar.gz
> $ tar xvzf NVIDIA_GLX.tar.gz
>
> cd into the NVIDIA_kernel directory. Type 'make install'. This will
> compile the kernel interface to the NVdriver, link the NVdriver, copy
> the NVdriver into place, and attempt to insert the NVdriver into the
> running kernel:
>
> $ cd NVIDIA_kernel
> $ make install
>
> Next, move into the NVIDIA_GLX directory. Type 'make install' -- this
> will copy the needed OpenGL and XFree86 files into place:
> $ cd ../NVIDIA_GLX
> $ make install
>
> Note that the "make install" for each package will remove any previously
> installed NVIDIA drivers.
> "
>
>
> Best regards,
> Jesper Juhl
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, 22 Oct 2001, Cort Dougan wrote:
> If the binary only module in question sticks with the "published
> interface" (as is required) isn't it a problem in Linux then?
1) there is no published interface, except in source code
2) we have no idea which parts of the code the nvidia
driver "sticks with", since it's binary-only
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed)
http://www.surriel.com/ http://distro.conectiva.com/
--------- Received message begins Here ---------
>
> On Mon, Oct 22, 2001 at 09:24:11PM +0100, Alan Cox wrote:
> > Only Nvidia can help you
>
> With a problem caused by someone else and not them? Interesting viewpoint. I
> also find it interesting that people think NVidia is the sole company in control
> of whether or not ther drivers are opened considering SGI and other 3rd parties
> own code in the 'driver pie'. This is a simplistic naive view IMHO....
> -
Not really. Driver writers have always had to provide updates if/when other
parts of the kernel evolved. Especially if they inadvertently depended on
a bug in that other part.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
> with his current version of windows. Admittedly, some may not consider this a
> feature, but I think a lot do. Why should a 'stable' kernel series break
> existing drivers?
It probably shouldn't but we cant tell where the problem lies in a lump of
binary code.
> > I really doubt Nvidia will open their driver code. I've heard them explain
> > some of the reasons they don't and in part they make complete sense.
>
> Microsoft deals with companies that won't always give them access to the drivers
> directly, but often they will tell users workarounds, or at least attempt to
> gather enough knowledge since they are tehnically the OS vendor to give to the
> driver provider to fix the problem. If you are the OS provider, and a change you
> make breaks user drivers/programs generally I think it's a polite gesture to at
> least attempt to find out what's going on and then pass that information on to
> the people who can properly handle it...
If Nvidia would like to pay me as much as Microsoft is paid for driver
certification then I might be able to find the time
On Tue, Oct 23, 2001 at 08:57:06AM +0100, Alan Cox wrote:
> If Nvidia would like to pay me as much as Microsoft is paid for driver
> certification then I might be able to find the time
Well this has certainly be an interesting discussion and it is nice to see that
for the most part it was kept quite reasonable. People's viewpoints on this
particular issue I think are going to come to the forefront as Linux slowly
gains ground in the desktop market. These are obviously, as I stated before,
opinions of a somewhat limited software development view. Thanks to all for your
responses...
On Mon, 22 Oct 2001 [email protected] wrote:
> On Mon, Oct 22, 2001 at 11:50:59PM +0100, Alan Cox wrote:
> > I really doubt Nvidia will open their driver code. I've heard them explain
> > some of the reasons they don't and in part they make complete sense.
>
> Microsoft deals with companies that won't always give them access to the drivers
> directly, but often they will tell users workarounds, or at least attempt to
> gather enough knowledge since they are tehnically the OS vendor to give to the
> driver provider to fix the problem. If you are the OS provider, and a change you
> make breaks user drivers/programs generally I think it's a polite gesture to at
> least attempt to find out what's going on and then pass that information on to
> the people who can properly handle it...
Of course the Linux kernel developers provide information: they even provide
the sources of their kernel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
> If the binary only module in question sticks with the "published
> interface" (as is required) isn't it a problem in Linux then?
But if it stuck the published interface it would work. Clearly. 8)
Thats the problem - nobody knows why it breaks, and its a complex driver
doing trick memory management hacks (or at least the older version I
got bored enough to reverse engineer a bit to look at the problems did) and
may well do other horrible things
Alan
> I wouldn't be surprised if someone creates a LHQL process or
> business to qualify binary drivers on supportable kernels from
> distributions. I'd give it about a year.
For the vendors I think that is a reasonable expectation. Right now I know
of no vendor who supports a binary only driver at all. Its only feasible to
do that with partnership agreements, complex piles of SLA's that of course
all turn out useless when the binary vendor goes bankrupt (which happens
ask any Aureal user)
Alan
On approximately Tue, Oct 23, 2001 at 11:05:48AM +0200, Jesper Juhl wrote:
>
> I use the same version of the driver with my Geforce3 and I am also
> running 2.4.13-pre6 and it works just fine so I don't agree with you
> that it breaks...
> You do know that there are a few files that need to be recompiled every
> time you build a new kernel - right?
>
I have replied to this person personally a when this thread started with what I
think is the fix to his problem. I have seen this error on my machine before.
The problem arose when I compiled the running kernel with gcc-3.0. At first I
thought it was just gcc-3 breaking the kernel. Then I realized that the nvidia
modules use `cc` to compile. The symlink to cc was gcc-2.95. Changing the
symlink to gcc-3.0 made the problem go away.
Josh
--
Linux, the choice | The first Rotarian was the first man to
of a GNU generation -o) | call John the Baptist "Jack." -- H.L.
Kernel 2.4.12-ac5 /\ | Mencken
on a i586 _\_v |
|
On 20011023 Josh McKinney wrote:
>On approximately Tue, Oct 23, 2001 at 11:05:48AM +0200, Jesper Juhl wrote:
>>
>> I use the same version of the driver with my Geforce3 and I am also
>> running 2.4.13-pre6 and it works just fine so I don't agree with you
>> that it breaks...
>> You do know that there are a few files that need to be recompiled every
>> time you build a new kernel - right?
>>
>
>I have replied to this person personally a when this thread started with what I
>think is the fix to his problem. I have seen this error on my machine before.
>The problem arose when I compiled the running kernel with gcc-3.0. At first I
>thought it was just gcc-3 breaking the kernel. Then I realized that the nvidia
>modules use `cc` to compile. The symlink to cc was gcc-2.95. Changing the
>symlink to gcc-3.0 made the problem go away.
>
The first thing I did was to kach the horrible nVidia's Makefile. For example,
it had the bad intention of compiling and installing against the running kernel
(guess kernel with uname -r). So when you update the kernel, you have to reboot
and make nVidia drivers. I changed it to:
+KREL:=`grep UTS_RELEASE /usr/src/linux/include/linux/version.h | cut -d\" -f2`
-KERNDIR:=/lib/modules/$(shell uname -r)
+KERNDIR:=/lib/modules/$(KREL)
so it builds against a built but not-running kernel.
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.12-ac6-beo #1 SMP Tue Oct 23 21:24:30 CEST 2001 i686
On Tue, Oct 23, 2001 at 10:50:55AM +0100, David Woodhouse wrote:
>
> [email protected] said:
> > What I am advocating is a little bit more sanity. The OS should not
> > break compatability with existing drivers so often for a 'stable'
> > release.
>
> Name a driver in the 2.4.13-pre6 tree which doesn't compile and work with
> the 2.4.13-pre6 kernel.
Mitsumi (non-IDE CDROMs), broke at the 2.3.41-pre3 and 2.3.41-pre4
transition, and IIRC was still broken at 2.4.0 .. haven't got the drive here
so I can't test.
--
____/| Ragnar H?jland Freedom - Linux - OpenGL | Brainbench MVP
\ o.O| PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
=(_)= "Thou shalt not follow the NULL pointer for | (http://www.brainbench.com)
U chaos and madness await thee at its end."
J . A . Magallon wrote:
> The first thing I did was to kach the horrible nVidia's Makefile. For example,
> it had the bad intention of compiling and installing against the running kernel
> (guess kernel with uname -r). So when you update the kernel, you have to reboot
> and make nVidia drivers. I changed it to:
>
> +KREL:=`grep UTS_RELEASE /usr/src/linux/include/linux/version.h | cut -d\" -f2`
> -KERNDIR:=/lib/modules/$(shell uname -r)
> +KERNDIR:=/lib/modules/$(KREL)
>
> so it builds against a built but not-running kernel.
>
>
I thought use of /usr/src/linux was not recommended anymore. On my
distro, that file would point to the original kernel, the one that
glibc, et al. is compiled with, not my current running kernel or ones
I've not yet booted with. Perhaps a `uname -r` with command-line
override would be more appropriate?
Regards,
Reid
On 20011024 Reid Hekman wrote:
>J . A . Magallon wrote:
>
>> The first thing I did was to kach the horrible nVidia's Makefile. For example,
>> it had the bad intention of compiling and installing against the running kernel
>> (guess kernel with uname -r). So when you update the kernel, you have to reboot
>> and make nVidia drivers. I changed it to:
>>
>> +KREL:=`grep UTS_RELEASE /usr/src/linux/include/linux/version.h | cut -d\" -f2`
>> -KERNDIR:=/lib/modules/$(shell uname -r)
>> +KERNDIR:=/lib/modules/$(KREL)
>>
>> so it builds against a built but not-running kernel.
>>
>>
>
>I thought use of /usr/src/linux was not recommended anymore. On my
>distro, that file would point to the original kernel, the one that
>glibc, et al. is compiled with, not my current running kernel or ones
>I've not yet booted with. Perhaps a `uname -r` with command-line
>override would be more appropriate?
>
As I see it, that is exactly what should not be done. Lets suppose you are
running 2.4.12. You want to upgrade. So you unpack 2.4.13 and build it.
If you go now to build nVidia drivers, with the shipped Makefile they
still build and install against 2.4.12. Sou you have to reboot in runlevel
3 to have 2.4.13 running witoht X, and then install the driver. *grrr*
With the above change, you build your kernel, then you go to the nVidia
sources, build the driver and install on the proper 2.4.13 dir under
/lib/modules, and just reboot in X again.
About /usr/src/linux, what is not recommended is to symlink
/usr/include/asm -> /usr/src/linux/include/asm
/usr/include/linux -> /usr/src/linux/include/linux
but instead have a separate header package that installs under /usr/include.
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.13-beo #2 SMP Thu Oct 25 00:59:08 CEST 2001 i686
Dan Maas wrote:
>>As I see it, that is exactly what should not be done. Lets suppose you are
>>running 2.4.12. You want to upgrade. So you unpack 2.4.13 and build it.
>>If you go now to build nVidia drivers, with the shipped Makefile they
>>still build and install against 2.4.12.
>>
>
> You don't have to reboot into the new kernel, just do as the README says:
>
> If you want to build NVdriver for a system other than the compiling
> system, then you'll need to run the make as:
>
> $ make SYSINCLUDE=/src/kern/my-smp-kernel/include
>
> to generate an NVdriver that will work on the kernel whose include
> files are in /src/kern/my-smp-kernel/include. This kernel must
> have been completely configured (make menuconfig dep).
>
> So you still only need to reboot once when upgrading your kernel.
>
> The only thing I find annoying is that the kernel's 'make modules_install'
> wipes out /lib/modules/<version>, so when I'm in the compile/debug cycle on
> my own driver I have to keep reinstalling NVdriver.
>
> Regards,
> Dan
Thanks for the info. I hadn't looked at the makefile myself, but now
that you mention it do remember the SYSINCLUDE directive from before.
For me personally, I've always booted in runlevel 3, so it's no problem
for me to recompile NVdriver after the reboot. To each his own I guess.
Regards,
Reid