It should be 3.14

Do not worry, I use the generic smp kernel with a standard (for me) initrd.

It's very clear that the problem is something about 3.14.3's debugging combined with closed source nvidia driver.

In other words, this time, Linus said: no kernel debugging for you, if you want the closed source driver made by NVIDIA. As if the kernel debugging worked previous, when it see nvidia.ko loaded... :P

That's a good question. The CONFIG_KERNEL_DEBUG option has only been active for about 4 years, and was off previously. Seems a bit strange that the option would interfere with the nVidia driver, though, as nearly all distributions enable it.

But why is that? The only possible clue I see in the ChangeLog is something about "improving kernel module compatibility".

It seems like this option might also introduce a performance hit.

If I can get any confirmation that unsetting this option fixes the proprietary driver for some more people, we'll try turning it off in the next round of kernels. Unless anyone can remember why it was turned on in the first place, and that turns out to still be a good idea.

2 members found this post helpful.

I don't think a debugging feature will cause a broken driver installation as i used 3.14.3 on my desktop and i'm able to install 304.121 driver on my system without having the above problem.
FYI i'm using generic kernel as well

I believe that kernel debugging is very useful for a kernel developer or an advanced system builder/package developer. Also, I believe that those persons known very well how to build a debug kernel.

And, we are in the middle of the Linus's Holly War Against The Closed Source Drivers. Weapon of choice, debugging.

That's an fine broken build, not a broken installation. Something like:

I don't quite know what you mean by this, but if a proprietary (GPL incompatible) kernel module is trying to load something in the kernel in a way that would violate the kernel's license, the kernel has every right to block this. But, if that is what's happening here, I still fail to see what the kernel debugging option has to do it.

1 members found this post helpful.

OK, then we have to wait a little... Or another fellow slacker will find a better solution.

In other hand, I re-verified that I used for my custom build, the generic smp config as template, etc...

Yet again, the NVIDIA 331.67 kernel module builds fine, and works fine on kernel without debugging. Also, it builds fine and works fine on the standard smp generic kernel, IF we fake the driver license as GPL.

Then, like I said, disabling the entire debugging was a strong hand, and, of course, the build can be refined to right identify which debugging option create head-caches to the current NVIDIA driver.

I think debug should stay on. Why ?

1) Not everyone uses the nvidia drivers.
2) The nvidia drivers do NOT come with Slackware.
3) The nouveau driver works fine with most nvidia cards.
4) The nvidia devs can fix this bug, and they should.

I confirm that rebuilding the kernel with CONFIG_KERNEL_DEBUG option set to off is solving the problem.

Cases when older versions of NVIDIA driver used are not relevant here - it's probably simply that offending mutex_lock_nested() call is not used in these drivers source code, and that this is why the older version of the driver will compile fine even when kernel built with CONFIG_KERNEL_DEBUG set to on.

I've posted a message to the relevant NVIDIA forum about this: https://devtalk.nvidia.com/default/t...-build-option/. Don't know are they going to care about it, and I'm not sure either what exactly CONFIG_KERNEL_DEBUG has to do with all of this, but in any case I'd vote for reverting this option to off for now in Slackware kernels.

The nouveau driver is probably nowhere near NVIDIA proprietary driver with regards to 3D graphics capabilities and performance. Besides, there doesn't exist any sort of support for using NVIDIA GPUs for GPGPU calculations besides NVIDIA proprietary driver (in particular, this is my use case). So it's not that simple.

Well, the behavior of the NVIDIA driver as good kernel citizen, can be criticized by the kernel developers and can be defended by NVIDIA, so, I can't comment much on that problem...

But, everyone know that Linus Torvalds do not love the closed source drivers. And I agree with his POV, even strongly, after I started to walk on the ARM jungle, where we have wars on closed drivers, with almost all SOC companies...

But, also I arrived at conclusion that Linus love to make headcaches to closed source developers, i.e. NVIDIA or AMD/ATI, and he use the kernel debugging support as an innocent and smiling way to do it.

I believe that the NVIDIA kernel module in the latest iterations, tries to use for his debugging, an debugging function that is now, on 3.14.3, reserved only for GPL drivers. You know, the closed source driver taints the kernel so the right debugging is not possible, etc...

BUT, when you used that kernel debugging? You are kindly, then, to say when you are used the GDB to debug the kernel, last time?

Well, ok, I guess turning it off won't affect most people, and the people it will affect usually build their own kernels, so looking at it that way, turn it off.

I checked my custom kernel config and it is off although I did turn it on for a while in the past as I was debugging some kernel issues.

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