nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   Nvidia driver 180.60 will not install on kernel-rt (http://www.nvnews.net/vbulletin/showthread.php?t=133342)

davelaser 05-22-09 04:36 AM

Nvidia driver 180.60 will not install on kernel-rt
 
2 Attachment(s)
Hi.

I'm currently using Ubuntu Jaunty and I wanted to try out the linux kernel with Ingo Molnar's realtime kernel preemption patch to try and reduce the problems I have with pulseaudio skipping.

I installed the version from the Jaunty repositories (linux-image-2.6.27-3-rt) along with the header files but the nviida driver fails to install on this kernel. I have attached a nvidia-bug-report file and a copy of the installer log, perhaps someone can tell me what the problem is. Is the nvidia driver compatible with real time kernels?

Sam

thefirstm 05-22-09 05:47 AM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
The nvidia driver is not compatible with rt kernels by default. I believe the nvidia driver in Ubuntu already has a patch to make this work properly. If you want to use the latest driver, you could try out the one in my Launchpad PPA. It should also have the patch, because it is directly based off the driver in Jaunty.

davelaser 05-22-09 06:15 AM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
Thanks for that, got the rt kernel and nvidia driver playing nicely now.

Unfortunately it still hasn't actually fixed my pulseaudio stuttering problems :-(.

Sam

JaXXoN 05-22-09 06:55 AM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
Quote:

Originally Posted by thefirstm (Post 2013535)
The nvidia driver is not compatible with rt kernels by default.

Interesting, a couple of years ago, the nvidia driver worked nicely together with rt-preemption.
At that time, I did a lot of investigations to make sure that the driver doesn't include
high latency paths. However, a couple of weeks ago I briefly tried out 2.6.29.1-rt9
with Fedora 10: installing the nvidia driver worked ootb, but I experienced a system
freeze. Didn't had time to do further investigations, but maybe it's a related problem,
I will check.

Thanks for the hint

regards

Bernhard

JaXXoN 05-22-09 07:05 AM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
Quote:

Originally Posted by davelaser (Post 2013543)
Unfortunately it still hasn't actually fixed my pulseaudio stuttering problems :-(.

Pulseaudio in Fedora 10 is a disaster, too! In general, the sound environment
consisting of OSS, ALSA, ESD, ARTS, openal, SDL, Pulseaudio, Jack, etc.
violates the KISS principle! Therefore i decided to go "back to the roots" and
just use ALSA wherever possible :-) However, for X-Plane, I still had stuttering
until I selected "alsa native" as sound device in /etc/openalrc (instead of
the default "sdl") - seems like on Fedora 10, sdl uses OSS by default which
uses ALSA-based OSS-emualtion in turn, potentially causing stuttering.

Does somebody know a very good overview (including diagrams, etc.) that
shows how all that sound stuff interacts and how to configure it? So far, I only
found documents that handle one aspect, but not the whole picture.

regards

Bernhard

pootle 05-22-09 07:24 AM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
Quote:

Originally Posted by JaXXoN (Post 2013563)
Does somebody know a very good overview (including diagrams, etc.) that
shows how all that sound stuff interacts and how to configure it? So far, I only
found documents that handle one aspect, but not the whole picture.
Bernhard

I've been looking for the same info myself, and found this, which is a good start.

So unless you want the application specific volume settings pulse does, it probably makes more sense to go straight to alsa.

Also this is a good overview of sound in Jaunty, with some really useful info on setup and testing. It is 64 bit, but 90% of it applies to 32 bit as well. (I run 32 bit 'cos the BBC player uses Adobe air which is a real pain to setup in 64bit, but just works in 32bit)

In particular I found the stuff on getting the latest alsa version very helpful as my laptop (asus 6930G) soundcard was hopeless with the default Jaunty alsa version (seems to be prehistoric in laptop timescales).

JaXXoN 05-22-09 10:13 AM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
Quote:

Originally Posted by pootle (Post 2013577)
So unless you want the application specific volume settings pulse does, it probably makes more sense to go straight to alsa.

I typically have just one sound generating application running at a time
(did I already mention that I like to keep things simple?).

But on the other hand, I'm wondering that the individual volume setting
hasn't yet been implemented on ALSA level. I'm not an ALSA expert, but
from what I have seen so far in the code, there is nothing that would
prevent somebody to implement this.

I understand that apart from the individual volume setting, pulseaudio
acts as a networked sound server. A typical "local" user (the "L-user"
aka luser, SCNR), doesn't need this functionality, so the sound system
should be hierarchical! Means: for each local sound applications, an
ALSA channels is opened that can be volume controlled individually.
And for each remote application, the (multi-threaded) sound server also
opens individual ALSA channels that can also be volume controlled
individually. The sound server could be started on demand i.e. via xinetd.
I think this would be the much better approach!

So from that perspective, pulseaudio is the plain wrong approach, IMHO!

We are getting a little bit off-topic, here :-)

regards

Bernhard

damentz 05-22-09 01:56 PM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
Actually, just rebuild the stock kernel of your distro with kernel preemption instead of voluntary preemption. This will provide the response time needed without the disadvantages of a real RT kernel.

Code:

# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y


JaXXoN 05-22-09 04:05 PM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
Quote:

Originally Posted by damentz (Post 2013789)
Actually, just rebuild the stock kernel of your distro with kernel preemption instead of voluntary preemption.

Thanks for the feedback! CONFIG_PREEMPT_VOLUNTARY is set
by default for the Fedora 10 kernels (2.6.27.21-170.2.56.fc10.i686.PAE).
Same result with real time preemption, btw.

Quote:

Originally Posted by damentz (Post 2013789)
This will provide the response time needed without the disadvantages of a real RT kernel.

Can you please specify those disadvantages?

regards

Bernhard

damentz 05-22-09 04:42 PM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
Well, you don't need to patch the kernel, just change a configuration option.

You don't experience reduced throughput due to the overhead of a RT kernel.

and lastly, proprietary modules continue to build correctly against the kernel as if you were using a stock distribution kernel anyway.

I don't understand why this option is not default on most desktop distributions. Distributions such as sidux use kernel preemption plus rcu preemption by default and everyone always exclaims about how much faster it is in comparison to Ubuntu or Fedora when in actuality, the software isn't optimized anymore than other distributions.

Though a note, RCU preemption will often preempt graphics applications you're running it seems and cause the "choppy" or "hiccup" effects when playing games - don't enable it.

JaXXoN 05-22-09 05:34 PM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
Quote:

Originally Posted by damentz (Post 2013892)
Well, you don't need to patch the kernel, just change a configuration option.

As mentioned, a kernel with real time preemption also stuttered and the stuttering
only disappeared after modifying /etc/openalrc. So I don't think a standard preemption
would help in this case!

Quote:

Originally Posted by damentz (Post 2013892)
You don't experience reduced throughput due to the overhead of a RT kernel.

While it is true that the overhead of an RT kernel reduces throughput
(maybe by 5%, so not really an issue for desktop operations), it will
not harm low bandwidth applications such as sound playback.

Quote:

Originally Posted by damentz (Post 2013892)
and lastly, proprietary modules continue to build correctly against the kernel as if you were using a stock distribution kernel anyway.

It happened to me a couple of times that vanilla or stock distribution kernels didn't
compiled with proprietary modules. Also, i hope it's only a question of time until
real-time preemption gets into mainline.

Quote:

Originally Posted by damentz (Post 2013892)
I don't understand why this option is not default on most desktop distributions.

You already mentioned the reason: decreased throughput!

The more real-time capabilities you want, the more throughput you have to
sacrifice. So the user can select between certain preemption variants
to find his personal trade-off between real-time and throughput.
I for one don't have a problem loosing 5% performance, but for a
data base admin, this would be a desaster :-) And since many
Linux distros are still mainly targeted for servers, low preemption
variants are prefered. Also, full and real-time preemption still have
sometimes have negative effects on stability.

regards

Bernhard

damentz 05-22-09 06:58 PM

Re: Nvidia driver 180.60 will not install on kernel-rt
 
Quote:

Originally Posted by JaXXoN (Post 2013908)
You already mentioned the reason: decreased throughput!

No I didn't.

I was speaking of the invasive RT patches. Kernel preemption already included the mainline kernel already has a negligible performance impact. I have done a gaming benchmark in the past using phoronix benchmark suite to discover the performance parity between voluntary and kernel preempt.

Performance loss is negligible. Ingo's RT patches are a different story though - I have not benchmarked those and have no need to currently.

Quote:

It happened to me a couple of times that vanilla or stock distribution kernels didn't
compiled with proprietary modules. Also, i hope it's only a question of time until
real-time preemption gets into mainline.
My car does not look green. Irrelevant, you didn't even specify which modules, their versions, and which kernel version. Building proprietary modules can be completely variable depending on how new your kernel is and how often the source provider of the module you are using stays up2date - you can't shotgun this predicament with, oh well it didn't work when i tried it. ??????


All times are GMT -5. The time now is 03:20 PM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.