* 2.4.13-pre6 breaks Nvidia's kernel module @ 2001-10-22 18:45 jarausch 2001-10-22 18:51 ` Benjamin LaHaise ` (6 more replies) 0 siblings, 7 replies; 37+ messages in thread From: jarausch @ 2001-10-22 18:45 UTC (permalink / raw) To: linux-kernel 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 jarausch@belgacom.net ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 18:45 2.4.13-pre6 breaks Nvidia's kernel module jarausch @ 2001-10-22 18:51 ` Benjamin LaHaise 2001-10-22 18:51 ` Alexander Viro ` (5 subsequent siblings) 6 siblings, 0 replies; 37+ messages in thread From: Benjamin LaHaise @ 2001-10-22 18:51 UTC (permalink / raw) To: jarausch, support; +Cc: linux-kernel 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, jarausch@belgacom.net 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 > > jarausch@belgacom.net > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > 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." ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 18:45 2.4.13-pre6 breaks Nvidia's kernel module jarausch 2001-10-22 18:51 ` Benjamin LaHaise @ 2001-10-22 18:51 ` Alexander Viro 2001-10-22 19:35 ` Rik van Riel ` (4 subsequent siblings) 6 siblings, 0 replies; 37+ messages in thread From: Alexander Viro @ 2001-10-22 18:51 UTC (permalink / raw) To: jarausch; +Cc: linux-kernel On Mon, 22 Oct 2001 jarausch@belgacom.net 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 18:45 2.4.13-pre6 breaks Nvidia's kernel module jarausch 2001-10-22 18:51 ` Benjamin LaHaise 2001-10-22 18:51 ` Alexander Viro @ 2001-10-22 19:35 ` Rik van Riel 2001-10-22 19:46 ` Christopher Friesen 2001-10-22 19:53 ` 2.4.13-pre6 breaks Nvidia's kernel module, or not? Stephan von Krawczynski ` (3 subsequent siblings) 6 siblings, 1 reply; 37+ messages in thread From: Rik van Riel @ 2001-10-22 19:35 UTC (permalink / raw) To: jarausch; +Cc: linux-kernel On Mon, 22 Oct 2001 jarausch@belgacom.net 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/ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 19:35 ` Rik van Riel @ 2001-10-22 19:46 ` Christopher Friesen 2001-10-22 19:53 ` Daniel T. Chen 0 siblings, 1 reply; 37+ messages in thread From: Christopher Friesen @ 2001-10-22 19:46 UTC (permalink / raw) To: Rik van Riel; +Cc: jarausch, linux-kernel Rik van Riel wrote: > > On Mon, 22 Oct 2001 jarausch@belgacom.net 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: cfriesen@nortelnetworks.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 19:46 ` Christopher Friesen @ 2001-10-22 19:53 ` Daniel T. Chen 0 siblings, 0 replies; 37+ messages in thread From: Daniel T. Chen @ 2001-10-22 19:53 UTC (permalink / raw) To: linux-kernel 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 crimsun@email.unc.edu GPG key: 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module, or not? 2001-10-22 18:45 2.4.13-pre6 breaks Nvidia's kernel module jarausch ` (2 preceding siblings ...) 2001-10-22 19:35 ` Rik van Riel @ 2001-10-22 19:53 ` Stephan von Krawczynski 2001-10-22 20:24 ` 2.4.13-pre6 breaks Nvidia's kernel module Alan Cox ` (2 subsequent siblings) 6 siblings, 0 replies; 37+ messages in thread From: Stephan von Krawczynski @ 2001-10-22 19:53 UTC (permalink / raw) To: jarausch; +Cc: linux-kernel On Mon, 22 Oct 2001 20:45:22 +0200 (CEST) jarausch@belgacom.net 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 18:45 2.4.13-pre6 breaks Nvidia's kernel module jarausch ` (3 preceding siblings ...) 2001-10-22 19:53 ` 2.4.13-pre6 breaks Nvidia's kernel module, or not? Stephan von Krawczynski @ 2001-10-22 20:24 ` Alan Cox 2001-10-22 22:27 ` drevil 2001-10-22 23:53 ` Horst von Brand 2001-10-23 9:05 ` Jesper Juhl 6 siblings, 1 reply; 37+ messages in thread From: Alan Cox @ 2001-10-22 20:24 UTC (permalink / raw) To: jarausch; +Cc: linux-kernel > Please keep this driver going during the 2.4.x series of the > kernel if at all possible. Only Nvidia can help you ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 20:24 ` 2.4.13-pre6 breaks Nvidia's kernel module Alan Cox @ 2001-10-22 22:27 ` drevil 2001-10-22 22:43 ` Charles Cazabon ` (3 more replies) 0 siblings, 4 replies; 37+ messages in thread From: drevil @ 2001-10-22 22:27 UTC (permalink / raw) To: linux-kernel 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.... ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 22:27 ` drevil @ 2001-10-22 22:43 ` Charles Cazabon 2001-10-22 22:46 ` Doug McNaught ` (2 subsequent siblings) 3 siblings, 0 replies; 37+ messages in thread From: Charles Cazabon @ 2001-10-22 22:43 UTC (permalink / raw) To: linux-kernel drevil@warpcore.org <drevil@warpcore.org> 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 <linux@discworld.dyndns.org> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ----------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 22:27 ` drevil 2001-10-22 22:43 ` Charles Cazabon @ 2001-10-22 22:46 ` Doug McNaught 2001-10-22 22:50 ` Alan Cox 2001-10-22 23:48 ` Jeff Golds 3 siblings, 0 replies; 37+ messages in thread From: Doug McNaught @ 2001-10-22 22:46 UTC (permalink / raw) To: drevil; +Cc: linux-kernel drevil@warpcore.org 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 22:27 ` drevil 2001-10-22 22:43 ` Charles Cazabon 2001-10-22 22:46 ` Doug McNaught @ 2001-10-22 22:50 ` Alan Cox 2001-10-23 1:31 ` drevil 2001-10-22 23:48 ` Jeff Golds 3 siblings, 1 reply; 37+ messages in thread From: Alan Cox @ 2001-10-22 22:50 UTC (permalink / raw) To: drevil; +Cc: linux-kernel > > 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 22:50 ` Alan Cox @ 2001-10-23 1:31 ` drevil 2001-10-23 1:43 ` Michael H. Warfield ` (2 more replies) 0 siblings, 3 replies; 37+ messages in thread From: drevil @ 2001-10-23 1:31 UTC (permalink / raw) To: linux-kernel 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... ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 1:31 ` drevil @ 2001-10-23 1:43 ` Michael H. Warfield 2001-10-23 2:16 ` drevil ` (2 more replies) 2001-10-23 7:57 ` Alan Cox 2001-10-23 16:01 ` Geert Uytterhoeven 2 siblings, 3 replies; 37+ messages in thread From: Michael H. Warfield @ 2001-10-23 1:43 UTC (permalink / raw) To: linux-kernel On Mon, Oct 22, 2001 at 08:31:59PM -0500, drevil@warpcore.org 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 | mhw@WittsEnd.com /\/\|=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! ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 1:43 ` Michael H. Warfield @ 2001-10-23 2:16 ` drevil 2001-10-23 4:44 ` Nicholas Knight 2001-10-23 5:35 ` Matt D. Robinson 2001-10-23 9:50 ` David Woodhouse 2 siblings, 1 reply; 37+ messages in thread From: drevil @ 2001-10-23 2:16 UTC (permalink / raw) To: linux-kernel 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... ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 2:16 ` drevil @ 2001-10-23 4:44 ` Nicholas Knight 2001-10-23 5:06 ` Cort Dougan 2001-10-23 5:08 ` drevil 0 siblings, 2 replies; 37+ messages in thread From: Nicholas Knight @ 2001-10-23 4:44 UTC (permalink / raw) To: drevil, linux-kernel ----- Original Message ----- From: <drevil@warpcore.org> To: <linux-kernel@vger.kernel.org> 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 4:44 ` Nicholas Knight @ 2001-10-23 5:06 ` Cort Dougan 2001-10-23 11:36 ` Rik van Riel 2001-10-23 16:13 ` Alan Cox 2001-10-23 5:08 ` drevil 1 sibling, 2 replies; 37+ messages in thread From: Cort Dougan @ 2001-10-23 5:06 UTC (permalink / raw) To: Nicholas Knight; +Cc: drevil, linux-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 5:06 ` Cort Dougan @ 2001-10-23 11:36 ` Rik van Riel 2001-10-23 16:13 ` Alan Cox 1 sibling, 0 replies; 37+ messages in thread From: Rik van Riel @ 2001-10-23 11:36 UTC (permalink / raw) To: Cort Dougan; +Cc: Nicholas Knight, drevil, linux-kernel 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/ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 5:06 ` Cort Dougan 2001-10-23 11:36 ` Rik van Riel @ 2001-10-23 16:13 ` Alan Cox 1 sibling, 0 replies; 37+ messages in thread From: Alan Cox @ 2001-10-23 16:13 UTC (permalink / raw) To: Cort Dougan; +Cc: Nicholas Knight, drevil, linux-kernel > 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 4:44 ` Nicholas Knight 2001-10-23 5:06 ` Cort Dougan @ 2001-10-23 5:08 ` drevil 2001-10-23 5:18 ` J Sloan ` (2 more replies) 1 sibling, 3 replies; 37+ messages in thread From: drevil @ 2001-10-23 5:08 UTC (permalink / raw) To: linux-kernel; +Cc: tegeran 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... ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 5:08 ` drevil @ 2001-10-23 5:18 ` J Sloan 2001-10-23 5:59 ` Nicholas Knight 2001-10-23 7:21 ` Helge Hafting 2 siblings, 0 replies; 37+ messages in thread From: J Sloan @ 2001-10-23 5:18 UTC (permalink / raw) To: drevil; +Cc: linux-kernel drevil@warpcore.org 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 5:08 ` drevil 2001-10-23 5:18 ` J Sloan @ 2001-10-23 5:59 ` Nicholas Knight 2001-10-23 7:21 ` Helge Hafting 2 siblings, 0 replies; 37+ messages in thread From: Nicholas Knight @ 2001-10-23 5:59 UTC (permalink / raw) To: drevil, linux-kernel ----- Original Message ----- From: <drevil@warpcore.org> To: <linux-kernel@vger.kernel.org> Cc: <tegeran@home.com> 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 5:08 ` drevil 2001-10-23 5:18 ` J Sloan 2001-10-23 5:59 ` Nicholas Knight @ 2001-10-23 7:21 ` Helge Hafting 2 siblings, 0 replies; 37+ messages in thread From: Helge Hafting @ 2001-10-23 7:21 UTC (permalink / raw) To: drevil; +Cc: linux-kernel drevil@warpcore.org 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 1:43 ` Michael H. Warfield 2001-10-23 2:16 ` drevil @ 2001-10-23 5:35 ` Matt D. Robinson 2001-10-23 16:16 ` Alan Cox 2001-10-23 9:50 ` David Woodhouse 2 siblings, 1 reply; 37+ messages in thread From: Matt D. Robinson @ 2001-10-23 5:35 UTC (permalink / raw) To: Michael H. Warfield; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 5:35 ` Matt D. Robinson @ 2001-10-23 16:16 ` Alan Cox 0 siblings, 0 replies; 37+ messages in thread From: Alan Cox @ 2001-10-23 16:16 UTC (permalink / raw) To: Matt D. Robinson; +Cc: Michael H. Warfield, linux-kernel > 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 1:43 ` Michael H. Warfield 2001-10-23 2:16 ` drevil 2001-10-23 5:35 ` Matt D. Robinson @ 2001-10-23 9:50 ` David Woodhouse 2001-10-23 23:45 ` Ragnar Hojland Espinosa 2 siblings, 1 reply; 37+ messages in thread From: David Woodhouse @ 2001-10-23 9:50 UTC (permalink / raw) To: drevil; +Cc: linux-kernel drevil@warpcore.org 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, torvalds@transmeta.com 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 9:50 ` David Woodhouse @ 2001-10-23 23:45 ` Ragnar Hojland Espinosa 0 siblings, 0 replies; 37+ messages in thread From: Ragnar Hojland Espinosa @ 2001-10-23 23:45 UTC (permalink / raw) To: David Woodhouse; +Cc: drevil, linux-kernel On Tue, Oct 23, 2001 at 10:50:55AM +0100, David Woodhouse wrote: > > drevil@warpcore.org 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 | (www.brainbench.com) U chaos and madness await thee at its end." ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 1:31 ` drevil 2001-10-23 1:43 ` Michael H. Warfield @ 2001-10-23 7:57 ` Alan Cox 2001-10-23 14:18 ` drevil 2001-10-23 16:01 ` Geert Uytterhoeven 2 siblings, 1 reply; 37+ messages in thread From: Alan Cox @ 2001-10-23 7:57 UTC (permalink / raw) To: drevil; +Cc: linux-kernel > 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 7:57 ` Alan Cox @ 2001-10-23 14:18 ` drevil 0 siblings, 0 replies; 37+ messages in thread From: drevil @ 2001-10-23 14:18 UTC (permalink / raw) To: linux-kernel 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... ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 1:31 ` drevil 2001-10-23 1:43 ` Michael H. Warfield 2001-10-23 7:57 ` Alan Cox @ 2001-10-23 16:01 ` Geert Uytterhoeven 2 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2001-10-23 16:01 UTC (permalink / raw) To: drevil; +Cc: Linux Kernel Development On Mon, 22 Oct 2001 drevil@warpcore.org 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 -- geert@linux-m68k.org 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 22:27 ` drevil ` (2 preceding siblings ...) 2001-10-22 22:50 ` Alan Cox @ 2001-10-22 23:48 ` Jeff Golds 3 siblings, 0 replies; 37+ messages in thread From: Jeff Golds @ 2001-10-22 23:48 UTC (permalink / raw) To: drevil; +Cc: linux-kernel drevil@warpcore.org 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 jgolds@resilience.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 18:45 2.4.13-pre6 breaks Nvidia's kernel module jarausch ` (4 preceding siblings ...) 2001-10-22 20:24 ` 2.4.13-pre6 breaks Nvidia's kernel module Alan Cox @ 2001-10-22 23:53 ` Horst von Brand 2001-10-23 9:05 ` Jesper Juhl 6 siblings, 0 replies; 37+ messages in thread From: Horst von Brand @ 2001-10-22 23:53 UTC (permalink / raw) To: jarausch; +Cc: linux-kernel jarausch@belgacom.net 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 vonbrand@sleipnir.valparaiso.cl Casilla 9G, Vin~a del Mar, Chile +56 32 672616 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-22 18:45 2.4.13-pre6 breaks Nvidia's kernel module jarausch ` (5 preceding siblings ...) 2001-10-22 23:53 ` Horst von Brand @ 2001-10-23 9:05 ` Jesper Juhl 2001-10-23 18:07 ` Josh McKinney 6 siblings, 1 reply; 37+ messages in thread From: Jesper Juhl @ 2001-10-23 9:05 UTC (permalink / raw) To: jarausch; +Cc: linux-kernel jarausch@belgacom.net 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 9:05 ` Jesper Juhl @ 2001-10-23 18:07 ` Josh McKinney 2001-10-23 22:51 ` J . A . Magallon 0 siblings, 1 reply; 37+ messages in thread From: Josh McKinney @ 2001-10-23 18:07 UTC (permalink / raw) To: linux-kernel 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 | | ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 18:07 ` Josh McKinney @ 2001-10-23 22:51 ` J . A . Magallon 2001-10-24 21:06 ` Reid Hekman 0 siblings, 1 reply; 37+ messages in thread From: J . A . Magallon @ 2001-10-23 22:51 UTC (permalink / raw) To: Josh McKinney; +Cc: linux-kernel 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:jamagallon@able.es 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-23 22:51 ` J . A . Magallon @ 2001-10-24 21:06 ` Reid Hekman 2001-10-25 0:19 ` J . A . Magallon 0 siblings, 1 reply; 37+ messages in thread From: Reid Hekman @ 2001-10-24 21:06 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.4.13-pre6 breaks Nvidia's kernel module 2001-10-24 21:06 ` Reid Hekman @ 2001-10-25 0:19 ` J . A . Magallon 0 siblings, 0 replies; 37+ messages in thread From: J . A . Magallon @ 2001-10-25 0:19 UTC (permalink / raw) To: Reid Hekman; +Cc: linux-kernel 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:jamagallon@able.es 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2001-10-25 0:19 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-10-22 18:45 2.4.13-pre6 breaks Nvidia's kernel module jarausch 2001-10-22 18:51 ` Benjamin LaHaise 2001-10-22 18:51 ` Alexander Viro 2001-10-22 19:35 ` Rik van Riel 2001-10-22 19:46 ` Christopher Friesen 2001-10-22 19:53 ` Daniel T. Chen 2001-10-22 19:53 ` 2.4.13-pre6 breaks Nvidia's kernel module, or not? Stephan von Krawczynski 2001-10-22 20:24 ` 2.4.13-pre6 breaks Nvidia's kernel module Alan Cox 2001-10-22 22:27 ` drevil 2001-10-22 22:43 ` Charles Cazabon 2001-10-22 22:46 ` Doug McNaught 2001-10-22 22:50 ` Alan Cox 2001-10-23 1:31 ` drevil 2001-10-23 1:43 ` Michael H. Warfield 2001-10-23 2:16 ` drevil 2001-10-23 4:44 ` Nicholas Knight 2001-10-23 5:06 ` Cort Dougan 2001-10-23 11:36 ` Rik van Riel 2001-10-23 16:13 ` Alan Cox 2001-10-23 5:08 ` drevil 2001-10-23 5:18 ` J Sloan 2001-10-23 5:59 ` Nicholas Knight 2001-10-23 7:21 ` Helge Hafting 2001-10-23 5:35 ` Matt D. Robinson 2001-10-23 16:16 ` Alan Cox 2001-10-23 9:50 ` David Woodhouse 2001-10-23 23:45 ` Ragnar Hojland Espinosa 2001-10-23 7:57 ` Alan Cox 2001-10-23 14:18 ` drevil 2001-10-23 16:01 ` Geert Uytterhoeven 2001-10-22 23:48 ` Jeff Golds 2001-10-22 23:53 ` Horst von Brand 2001-10-23 9:05 ` Jesper Juhl 2001-10-23 18:07 ` Josh McKinney 2001-10-23 22:51 ` J . A . Magallon 2001-10-24 21:06 ` Reid Hekman 2001-10-25 0:19 ` J . A . Magallon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).