linux/smp_lock.h needs to be included to define the kernel_locked() MACRO, acts like an undefined symbol while loading ndiswrapper. Patches attached...
Created attachment 40805 [details, diff] ndiswrapper 0.10 header patch patch for ndiswrapper 0.10 source tree. Put in net-wireless/ndiswrapper/files/
Created attachment 40806 [details, diff] ndiswrapper 0.10 ebuild patch patch for the ebuild of ndiswrapper 0.10 (it just applies the header patch via epatch after unpack)
Brad: What kernel are you running? I have pre-empt on both my systems and one system has an SMP kernel as well and it works fine without this patch. It looks to me like an issue with the 2.6.9_re/_pre kernels. There's a patch to what I believe addresses this issue in the kernel here.. http://marc.theaimsgroup.com/?l=linux-kernel&m=109492950330587&w=2 Let me know about the kernel version.
yep, 2.6.9_rc2 eitherway, this fixes it without patching the kernel source tree ...
However this is an incorrect fix. The problem is not with ndiswrapper. The problem is the fact that the kernel developers muck with the Linux kernel tree and commit changes and push them out to the public without testing them. The fact that in rc2 a developer got illiterate and as a result has a typo doesn't mean we're patching other patches to support their un-released versions. Reproduce the error with gentoo-sources, gentoo-dev-sources, vanilla-dev-sources, or development-sources. These are the 4 kernel trees that mobile@g.o supports directly. When 2.6.9 is released then we'll talk. Until then, it's an upstream issue. Take it up with kernel dev.
heh, well, I got a laugh out of the comments you made ... whatever, i could care less ...
simple fact: it's a bug in the kernel patching ndiswrapper (and every other kernel module that happens to break because of this) is the *wrong* way to do things if you want your kernel modules to compile normally and us to help fix them, stop using pre-release kernels
wow, thought this matter was closed ... now another comment ... didn't I get 'fired' for excessive comments like that?
Okay, I think *everyone* has gotten a little out of hand on this bug. I don't need to point out who, or why they maybe did. It doesn't matter. Let's keep this to the technicals please. The _pre/_rc kernels have a bug, that affects this package. We can't change all of our kernel module packages to reflect the latest changes (potentially breakages) in every _rc, mm-, _pre, etc kernel. If a release kernel shows up with a significant change, we'll fix the kernel modules packages to reflect that. We don't have the resources, or even the motivation to try to track the aformentioned kernel changes. Consider this bug resolved. (it already was). Please no more unneeded sniping here from anyone.
