177.70 beta drivers and 2.6.27-rc3-mm1, -rc5-mmotm

valdis · 09-01-08, 06:34 PM

177.70 is working under 2.6.27-rc3-mm1 and a bleeding-edge 2.6.27-rc5-mmotm (as of 08/29) kernel, with only one minor speed bump - the API for cap_raise() is changed in recent -mm kernels. Fortunately, all it's doing is raising the RLIMIT_MEMLOCK limit, which is configurable via other means on Fedora and probably most other sane distributions...

I've attached the one trivial patch needed...

valdis · 09-01-08, 06:38 PM

OK.. Now to actually *attach* 8t.

valdis · 09-01-08, 06:40 PM

Blarg. I suck. Especially when Noscript nukes the javascript...

mathew.winters · 09-01-08, 07:57 PM

What is the problem you see with the driver (many of us have problems with that beta and various configurations) and is the patch for the driver or the kernel?

valdis · 09-03-08, 02:49 PM

The patch is against usr/src/nv/os-interface.c in the driver. It basically converts a '#if !CONFIG_XEN' into an '#if 0' around some code that sets a resource limit. That code include a call to cap_raise(), which has a different API in recent -mm kernels. The end result is that the driver can't automagically raise the user's ulimit for mem-lockable pages - fortunately, most distros allow you to configure that ulimit via other means.

A *proper* fix would be to check what cap_raise() API the kernel has, and do the appropriate #ifdef magic for both cases. I don't blame NVidia in the slightest if they insist on waiting for that API change to actually land in the mainline kernel before they do something - there's no such thing as a nailed-down API in the -mm tree

My patch was a quick one-liner so I could get a works-for-me driver so I could proceed to find all the *other* stuff busticated in current -mm.

The patch is totally useless unless you're either (a) trying to run a very recent (last 2-3 weeks) -mm kernel or (b) need a heads-up that there may be an API change future drivers need to worry about.

**zander** · 09-03-08, 03:53 PM

I briefly looked at this today, but didn't have much lock with the current mmotm kernel and the most recent -mm* kernel I found didn't have the problem described here. I'll take another look when the next -mm* kernel becomes available.

**zander** · 09-08-08, 06:38 PM

I was able to reproduce the problem with Linux 2.6.27-rc5-mm1 at the end of last week. It should be resolved in a future driver release.

09-01-08, 06:34 PM	#1
valdis Registered User Join Date: Apr 2003 Posts: 48	177.70 beta drivers and 2.6.27-rc3-mm1, -rc5-mmotm 177.70 is working under 2.6.27-rc3-mm1 and a bleeding-edge 2.6.27-rc5-mmotm (as of 08/29) kernel, with only one minor speed bump - the API for cap_raise() is changed in recent -mm kernels. Fortunately, all it's doing is raising the RLIMIT_MEMLOCK limit, which is configurable via other means on Fedora and probably most other sane distributions... I've attached the one trivial patch needed...

09-01-08, 06:38 PM	#2
valdis Registered User Join Date: Apr 2003 Posts: 48	Re: 177.70 beta drivers and 2.6.27-rc3-mm1, -rc5-mmotm OK.. Now to actually attach 8t.

09-01-08, 07:57 PM	#4
mathew.winters Registered User Join Date: Jul 2008 Location: CHristchurch, New Zealand Posts: 15	Re: 177.70 beta drivers and 2.6.27-rc3-mm1, -rc5-mmotm What is the problem you see with the driver (many of us have problems with that beta and various configurations) and is the patch for the driver or the kernel?

09-03-08, 02:49 PM	#5
valdis Registered User Join Date: Apr 2003 Posts: 48	Re: 177.70 beta drivers and 2.6.27-rc3-mm1, -rc5-mmotm The patch is against usr/src/nv/os-interface.c in the driver. It basically converts a '#if !CONFIG_XEN' into an '#if 0' around some code that sets a resource limit. That code include a call to cap_raise(), which has a different API in recent -mm kernels. The end result is that the driver can't automagically raise the user's ulimit for mem-lockable pages - fortunately, most distros allow you to configure that ulimit via other means. A proper fix would be to check what cap_raise() API the kernel has, and do the appropriate #ifdef magic for both cases. I don't blame NVidia in the slightest if they insist on waiting for that API change to actually land in the mainline kernel before they do something - there's no such thing as a nailed-down API in the -mm tree My patch was a quick one-liner so I could get a works-for-me driver so I could proceed to find all the other stuff busticated in current -mm. The patch is totally useless unless you're either (a) trying to run a very recent (last 2-3 weeks) -mm kernel or (b) need a heads-up that there may be an API change future drivers need to worry about.

09-03-08, 03:53 PM	#6
zander NVIDIA Corporation Join Date: Aug 2002 Posts: 3,740	Re: 177.70 beta drivers and 2.6.27-rc3-mm1, -rc5-mmotm I briefly looked at this today, but didn't have much lock with the current mmotm kernel and the most recent -mm* kernel I found didn't have the problem described here. I'll take another look when the next -mm* kernel becomes available.

09-08-08, 06:38 PM	#7
zander NVIDIA Corporation Join Date: Aug 2002 Posts: 3,740	Re: 177.70 beta drivers and 2.6.27-rc3-mm1, -rc5-mmotm I was able to reproduce the problem with Linux 2.6.27-rc5-mm1 at the end of last week. It should be resolved in a future driver release.