Kernel Crashs - interessting ?

[Paul Iadonisi]

On Fri, 2004-11-26 at 08:51 -0600, Otto Haliburton wrote:

[snip]

> my problem is that people are being instructed to go to nvidia and
> report a problem that they won't respond to.  You are a daydreamer if
> you think that if this driver is not theirs then they will respond, if
> they haven't written a linux driver your complaint is going into the bit
> bucket.  The second part of this is if the problem is not occuring in
> windoze then what makes you think that it is a problem with nvidia
> driver and that you need to take a deeper look at what is happening in
> linux.  You always get these tyype responses from a simple let's
> investigate the problem as a linux problem and come up with the facts to
> present to nvidia!!!!!!

  Read up a little on the 'tainted' bit in the kernel.  It was
implemented for a reason, and binary-only vendors are (or should be)
100% aware of it, and its purpose.  Once a non-GPL compliant component
is loaded into the kernel, ALL bets are off.  Period.  End of story.
  There's no telling what a closed source binary module will do to
internal structures in the kernel.  That's true for GPLed code, too, but
in that case, it's reasonably debuggable by the kernel developers.
  That tainted bit is there so the kernel developers can take a look at
an Oops, see the tainted bit is set, and dump the report into the bit
bucket.  Once that bit is set, it's time to go to the providers of those
binary only kernel components.  No linux kernel developer whom I know of
will waste any of his valuable time investigating.  The only fact(s)
that I know of that you can provide to nVidia is your kernel version /
distribution release and the Oops (or whatever other problem anyone's
having).
-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets