[SOLVED] kernel 3.14.3 and NVIDIA driver

WhiteWolf1776 · 05-09-2014, 06:00 PM

I can also verify building nvidia driver with bumblebee support no longer works for the -current kernel.

W4LK · 05-09-2014, 06:33 PM

willsr, Your comment about the 304.121 driver working for you is true for me, also. None of the newer versions worked for me. 304.121 has me back up and running. Thanks

metaschima · 05-09-2014, 06:49 PM

Quote:

Originally Posted by turtleli

The debug options also causes the broadcom-sta wl driver to fail as well (See this thread).

That's true, after researching it a bit more, many proprietary drivers are affected.

Darth Vader · 05-09-2014, 06:51 PM

OK, then...

I refined my kernel build, based on generic smp config of current 3.14.3, and looks like the minimal intervention path, if we do not want to disable entirely the kernel debug (and to stay entirely away of Linus debug jokes with the closed source developers), is to disable the following options:

CONFIG_DEBUG_WW_MUTEX_SLOWPATH
CONFIG_DEBUG_LOCK_ALLOC

The offending option is colored in red, but it is automatically selected also by the other option.

enorbet · 05-09-2014, 06:53 PM

Just FTR I have a custom built 3.12.0 RT Low-Latency kernel with

Code:

CONFIG_DEBUG_KERNEL=y

and have nVidia 331.67 installed from Runlevel 3 and working with zero problems. It is doubtful that this one line is the problem.

However

Code:

CONFIG_DEBUG_LOCK_ALLOC is not set

Darth Vader · 05-09-2014, 06:56 PM

Quote:

Originally Posted by enorbet

Just FTR I have a custom built 3.12.0 RT Low-Latency kernel with

Code:

CONFIG_DEBUG_KERNEL=y

and have nVidia 331.67 installed from Runlevel 3 and working with zero problems. It is doubtful that this one line is the problem.

Sure! But, you have CONFIG_DEBUG_LOCK_ALLOC enabled, also?

----

Edit: Also, follow up... Sorry, enorbet!

turtleli · 05-09-2014, 07:36 PM

CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK and CONFIG_LOCKDEP (not sure this can be manually selected) may also be the culprits, since they are selected by CONFIG_DEBUG_LOCK_ALLOC.

I didn't really test the options very thoroughly, I just suspected the problem was in the lock debugging options for the broadcom-sta driver and after reproducing the fault I decided that I didn't want to spend extra time on it.

EDIT: Okay, after scanning the source I think it's CONFIG_DEBUG_LOCK_ALLOC for the NVIDIA driver and CONFIG_LOCKDEP for the broadcom-sta driver that causes problems. For the nitty gritty details, CONFIG_DEBUG_LOCK_ALLOC changes mutex_lock calls to mutex_lock_nested, and CONFIG_LOCKDEP changes a no-op to lockdep_init_map. mutex_lock_nested and lockdep_init_map can only be used by GPL-compliant modules, whereas mutex_lock can be used by any external module. Other functions may also be affected in similar ways.

rg3 · 05-10-2014, 07:24 AM

I'm just dropping by to say I'm also affected by this problem. I couldn't build the NVIDIA driver after upgrading the kernel in my slackware64-current system today. Unfortunately, I don't have time at this moment to check a custom build with debugging disabled, but thanks to everyone who's investing time and helping here. I went the quick and dirty (and probably illegal?) route of running the installer with the -x option to extract the archive, changed the MODULE_LICENSE lines to GPL and ran the installer by hand.

Darth Vader · 05-10-2014, 08:46 AM

Another quick and dirty workaround, on NVIDIA Linux drivers vs. the Slackware kernel 3.14.3.

This time, it's about one unexpected and full GPL driver...

If you have a NVIDIA chipset motherboard and, while using kernel 3.14.3, your hibernation kicked the bucket, you have to disable the serial port on motherboard, or to rebuild the kernel... without serial port support.

Yep, I talk about that little remnant from 90', and almost unchanged from this era, used to connect serial modems or other lovely things like debugging an another computer...

Now, the full native & GPL NVIDIA serial driver do not accept to be disabled, so your hibernation will go south.

BTW, talking about hibernation, if still, the hibernation (on disk) work, I believe that do the things now, maybe making a 32678 bits RSA checksum for every byte of memory, because now spend few minutes to go to sleep. Tested on NVIDIA and AMD chipsets. Both with 8G RAM and quad-cores...

cwizardone · 05-10-2014, 09:45 AM

Quote:

Originally Posted by willysr

lucky me then
304.121 works OK with Linux Kernel 3.14.3

I was surprised to see that the 304.xxx driver had been "tweaked" as recently as two months ago, resulting in the 304.121 version, so I tried it and and it did build and worked... to a point.
However, now WINE refuses to work. Interestingly, wine-pipelight works, but regular WINE does not. Re-installing WINE doesn't fix the problem.

At this point I'm going back to the previous kernel and will wait until the Gurus

work out a solution.

mlangdn · 05-10-2014, 10:12 AM

304.121 works for me as well. I don't do wine, but wine-pipelight is fine. I'm golden for now. Then again, I have an older card - Geforce 9 series.

cwizardone · 05-10-2014, 11:41 AM

Well, I'm back to the 3.10.30 kernel and the NVIDIA 325.15 driver.

Both the 331.49 and 331.67 drivers worked, without a problem, prior to trying the 3.14.3 kernel, but now, after reverting to the 3.10.30 kernel, neither driver will install without issuing errors during the installation of the 32-bit compatible drivers. The error, repeated 4 or 5 times, was,

Quote:

Unable to determine the architecture of the file '/usr/lib64/libEGL.la,' which has an architecture-specific conflict.

So I worked my way back to the 325.15 driver which installed without error and WINE is now working as it should.

One interesting side note, I thought. After installing the 3.14.3 kernel it was necessary, of course, to re-install VirtualBox. However, after reverting to the 3.10.30 kernel it was not necessary to re-install VirtualBox and it is running just fine. Odd, I thought.

Emerson · 05-10-2014, 11:58 AM

Methinks 304.121 is kind of long-life support version. 337.19 builds fine with 3.14.

cwizardone · 05-10-2014, 12:05 PM

I've tried the 337.19 driver, which NVIDIA has labeled as, "BETA," and it didn't build with the 3.14.3 kernel.

Emerson · 05-10-2014, 12:33 PM

Works here ...

Code:

$ modinfo nvidia
filename:       /lib/modules/3.14.3-gentoo/video/nvidia.ko
alias:          char-major-195-*
version:        337.19
supported:      external
license:        NVIDIA
alias:          pci:v000010DEd00000E00sv*sd*bc04sc80i00*
alias:          pci:v000010DEd00000AA3sv*sd*bc0Bsc40i00*
alias:          pci:v000010DEd*sv*sd*bc03sc02i00*
alias:          pci:v000010DEd*sv*sd*bc03sc00i00*
depends:        
vermagic:       3.14.3-gentoo SMP mod_unload 
parm:           NVreg_Mobile:int
parm:           NVreg_ResmanDebugLevel:int
parm:           NVreg_RmLogonRC:int
parm:           NVreg_ModifyDeviceFiles:int
parm:           NVreg_DeviceFileUID:int
parm:           NVreg_DeviceFileGID:int
parm:           NVreg_DeviceFileMode:int
parm:           NVreg_RemapLimit:int
parm:           NVreg_UpdateMemoryTypes:int
parm:           NVreg_InitializeSystemMemoryAllocations:int
parm:           NVreg_RMEdgeIntrCheck:int
parm:           NVreg_UsePageAttributeTable:int
parm:           NVreg_MapRegistersEarly:int
parm:           NVreg_RegisterForACPIEvents:int
parm:           NVreg_CheckPCIConfigSpace:int
parm:           NVreg_EnablePCIeGen3:int
parm:           NVreg_EnableMSI:int
parm:           NVreg_MemoryPoolSize:int
parm:           NVreg_RegistryDwords:charp
parm:           NVreg_RmMsg:charp
parm:           NVreg_AssignGpus:charp