On Thu, 2006-11-09 at 17:07 -0600, Jonathan Berry wrote:
> > First of all, thanks once again for introducing the red herring concept
> > of me running a test kernel. If you keep repeating a red herring,
> > sooner or later some people might get confused, but not really.
>
> No, the fact you were running a testing kernel is very relevant to
> this. Things break in testing kernels.
Well, contrary to your argument, the Nvidia drive built under kernel
2835. The problem was that installing the new kernel killed nvidia from
working under kernel 2798. As far as I am concerned that is a no no.
The second issue in all of this is that we have to BUILD drivers in the
first place.
> If you are running a testing
> kernel, it is assumed that you know what you are doing.
Well, I've built a few kernels in my day.
> If you do
> not, you will likely run into problems. Also (this will make more
> sense later in the email) Livna does not build nvidia kernel modules
> for testing kernels. Things change too quickly and they cannot keep
> up.
I understand that, but the real issue is that we should need to depend
on a single website to provide nvidia drivers !
> > If you read my original post, you'll note that I had problems building a
> > driver for kernel 2798. As far as I know that kernel is considered
> > stable. After all, it is running on most fc6 boxes.
>
> That doesn't seem to be what you were claiming here. It seems like
> you were fine until you upgraded to the testing kernel...
Yes, installing the new kernel disabled the nvidia driver for the old
kernel. As far as I know, that happens for ever kernel or at least it
has for ever kernel that I have installed for the last two years !
> > And the fact that the build failed is also irrelevant.
> >
> > THE RELEVANT POINT IN THIS WHOLE DISCUSSION IS THAT USERS HAVE TO
> > *BUILD* A DRIVER IN ORDER TO RUN THE NVIDIA HARDWARE, unless they can
> > live with what the non proprietary driver does. (Caps for emphasis, not
> > shouting !)
>
> The problem with this argument is that users do *not* have to build a
> driver if they use the Livna driver. It's very easy, install an RPM
> to add the repo, run a command to install the driver.
First of all, to use a livna driver, you have to know that livna exists
and then you have to be able to set livna up as a repository. Now, take
your average computer user and tell me that that it is a reasonable
expectation that they are able to to do that. It isn't.
Secondly, livna is not always up and its drivers have not always worked.
Then what ?
> The driver then
> upgrades itself with the kernel if the packages are available (which
> may take a couple days for Livna to build).
In the mean time, make sure you set yum up to ignore the kernel
updates.
> > > But once again, you fail to
> > > comprehend that. You want to run test kernels, that's fine. But don't
> > > expect everything to work, otherwise it wouldn't be a test kernel.
> >
> > This has NOTHING to do with being a test kernel. Are you dense ? The
> > nvidia driver has to be built for EVERY kernel and for me the failure
> > rate on that build is probably 50%.
>
> During the time I used the package from nVidia, it worked most of the
> time.
Yeah, most of the time. Great.
> The times it did not, I usually found a fix fairly quickly.
Just like I did this morning. How how about my mom, could she find a
fix quickly ?
> Then I switched to the Livna package and have had even fewer issues.
Even fewer means some ?
> The problem, especially when you throw in test kernels, is that the
> kernel changes quickly (and Fedora updates to those changes quickly)
> and nVidia cannot keep up with those changes.
Even test kernels aside, you are telling us you had issues.
> > Funny, I run ntfs on our server and I don't know a darn thing about how
> > it ties into the kernel ! I run yum update on the server, it does its
> > thing and I'm done. ntfs has never failed to run when I've rebooted.
> > That is the way software is supposed to work.
>
> That's really funny, 'cause if you are doing this, then you can do
> this with the nvidia driver as well.
I've gotten the nvidia driver working every single time ! And I was one
of the first ones to get it running on the zd7000 laptops and I wrote a
HOWTO about it and educated lots of other people.
> > Here is the thing... as far as I know, one can only build an Nvidia
> > driver for the kernel that they are running. Maybe the wizards know a
> > way around this, but, like I said before, I have a life outside of
> > Linux ! So what happens is you boot with the Nvidia driver and then you
> > build it and that is when you find out if it works or not.
>
> You most certainly can build the drivers before updating your kernel.
> Check the command options that the nvidia script gives you. That is,
> you can at least build them before you reboot into the new kernel once
> the update has been installed. And you can always boot into the old
> kernel if you need to work on things. And yes, I have rebuild the
> nvidia driver many times
I have never been able to boot into a previous kernel. As a matter of
fact, the installer script goes like this for me:
"-> There appears to already be a driver installed on your system
(version: 1.0-
8776). As part of installing this driver (version: 1.0-9629), the
existing
driver will be uninstalled. Are you sure you want to continue? ('no'
will a
bort installation) (Answer: Yes)"
That is straight from /var/log/nvidia-installer.log from this mornings
install. So how do you get it to keep the driver installed so you could
reboot with a previous kernel ?
> Especially
> when the things you are complaining about are a non-issue.
Now that there is very indicative of an issue in the Linux community.
Who is the Nvidia driver situation a non issue for ? Its an issue for
me. It wastes my time and it pisses me off. It has for 2 years. YOU
judge this as a non issue. To you it probably is a non issue. If you
put yourself in other peoples shoes, people who don't even know this
forum exists and know little about Linux, stuff like this is definitely
an issue.
--
Kim Lux, Diesel Research Inc.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
