Bug 145549 - CONFIG_DEBUG_SPINLOCK option in kernel causes panic with modprobe ndiswrapper
CONFIG_DEBUG_SPINLOCK option in kernel causes panic with modprobe ndiswrapper
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-19 11:43 EST by Jonathan Berry
Modified: 2015-01-04 17:15 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-19 17:38:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan Berry 2005-01-19 11:43:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

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
installed)

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
x86_64.

Version-Release number of selected component (if applicable):
kernel-2.6.10-1.741_FC3.x86_64

How reproducible:
Always

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.

Additional info:

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.
Comment 1 Dave Jones 2005-01-19 17:38:32 EST
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.
Comment 2 Jonathan Berry 2005-01-22 23:26:40 EST
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 :).
Comment 3 Dave Jones 2005-01-22 23:35:48 EST
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
twice, etc

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.

Note You need to log in before you can comment on or make changes to this bug.