Red Hat Bugzilla – Bug 145549
CONFIG_DEBUG_SPINLOCK option in kernel causes panic with modprobe ndiswrapper
Last modified: 2015-01-04 17:15:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5)
Description of problem:
After building the latest release of ndiswrapper (1.0rc3), attempting
to run "modprobe ndiswrapper" results in a kernel panic and a complete
lock of the system. I have tried this with the 10-1.741 kernel and
the 9-1.724_FC3 kernel. A custom compiled 9-1.724_FC3 kernel
configured without CONFIG_DEBUG_SPINLOCK does not exhibit this panic.
The only other differences are:
removal of some unneeded modules
configured psmouse as a module
configured building of the NTFS driver (stock kernel has NTFS rpm
ndiswrapper claims to have a workaround for the CONFIG_DEBUG_SPINLOCK
option, but it does not seem to work.
This probably applies to the ix86 kernels as well, but I am running
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Get ndiswrapper 1.0rc3 and perform make; make install (install as root)
2. As root /sbin/modprobe ndiswrapper
Actual Results: Complete system freeze: no mouse, no keyboard, can
only poweroff by holding down power button
Expected Results: ndiswrapper module loads and allows me to use my
Broadcom wireless device. This has worked with the custom kernel
configured to not have the CONFIG_DEBUG_SPINLOCK option.
I would like to see the Fedora Core kernels configured by default
without the CONFIG_DEBUG_SPINLOCK. I do not see a purpose in building
production kernels with the option. If there is a reason for this,
please let me know. I can compile a custom kernel without this
option, but that becomes tedious with the frequency of kernel updates.
the purpose is so that buggy out of tree drivers get fixed.
it might work with the option turned off, but the driver is doing
something *bad* that could cause problems at any time.
Complain to the ndiswrapper authors, as anything the DEBUG_SPINLOCK
triggers is their bug.
Thanks Dave. I mostly wanted to see if there was a reason for having
this flag; I figured it couldn't hurt to ask :). I guess perhaps this
is somewhat an artifact of the nature of Fedora, being a testing
ground for the RHEL releases. Otherwise, I would think it to be
better to just have this in testing kernels, not official releases.
Can I ask what kind of things trigger the DEBUG_SPINLOCK and what this
triggering should do? Seems like a hard freeze of the system isn't
exactly the ideal reaction.
I have told the ndiswrapper authors about the issue, but I'm not sure
how much they can do. I think it may have to do with the Windows
binary drivers that ndiswrapper wraps (which I realize is not your
problem). So, if I have to recompile my kernel, I guess I won't mind
too much :).
it's not a fedora specific thing, it's enabled for RHEL too.
Its so low overhead, and catches so many really dumb bugs, it doesn't
make sense to not have it on.
It'll trigger if a whole bunch of silly things happen, like trying to
take a lock that hasn't been initialised, trying to take the same lock
It panics and does the hard freeze, because in many situations its too
dangerous to continue. Locking up early is preferred, rather than
silently corrupting data, and eventually crashing.