Hide Forgot
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.
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 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.