Attempting to modprobe ndiswrapper-0.11-r1 on mm-sources-2.6.10-rc2-mm2 results in error, and message "Unknown symbol task_nice" in dmesg. This is fixable by following advice at http://article.gmane.org/gmane.linux.drivers.ndiswrapper.general/3555, then recompiling kernel. This results in the mods below to kernel/sched.c, starting at line 3210: /** * task_nice - return the nice value of a given task. * @p: the task in question. */ int task_nice(const task_t *p) { return TASK_NICE(p); } /* Below added by aja, per http://article.gmane.org/gmane.linux.drivers.ndiswrapper.general/3555 */ EXPORT_SYMBOL(task_nice); Reproducible: Always Steps to Reproduce: 1. 2. 3.
This is a known issue with ndiswrapper. I believe that Cardoe answered this *extremely* well. As a result, Im snipping his response. <!-- Snipped from bug 69586 without permission (and shamelessly) --> Unfortunately contrarry to popular belief, the Mobile herd (and me especially) do not support RCs or PREs of the kernel as there are usually several show stopper bugs that need to get addressed by us on LKML prior to a stable kernel release. I already have one on there prior to 2.6.10. ndiswrapper is also another package that mobile won't support RCs for. <!-- End snip of Cardoe's response --> I believe that this bug should be marked as a duplicate of bug #69586
Sorry, didnt read far enough to see that a solution was provided. Maybe this bug can be used instead of the other one then. Sorry about responding too fast AJ.
AJ: What you're reporting here is a kernel bug in an RC of the MM sources... which are a known unstable testing/proving ground for new code. The proposed fix is the edit the kernel sources? What exactly would your like the ndiswrapper ebuild to do? Editing kernel sources is well outside the spec of the ndiswrapper ebuild.
Really this looks invalid.
Well, perhaps I wasn't as clear I could have been in the report, but I'm not sure the sarcasm is warranted. I have no issues with this bug being marked as "won't fix" - although I do disagree with "invalid". The "bug" is the fact that two packages that are not hard masked will not currently work together. I realize that mm-sources are testing platform, but I also realize that there are a large number of Gentoo users that want to use both, if only because many of them (like me) run newer laptops for which hardware support demands it. The reason that I posted the bug was (1) to document a _valid_ bug and (2) to report the results of my investigation and testing which was that there was a workaround, although it does involve modifying kernel sources. My primary goal was to document this information in the hopes that it might prove useful to others who encounter the problem. A secondary goal was to let the ndiswrapper and mm-sources maintainers know that this was in the pipeline (and might become an issue with the next version of the kernel, as mm-sources issues do frequently show up in the main kernel stream in a version or so). I apologise if that wasn't clear. Perhaps I am confused about the purpose of bugzilla. I suppose I resent (just a little) the implication that spending the time to do this here was somehow inappropriate.
The Gentoo Linux Kernel Guide lists the supported kernel packages. Please see http://www.gentoo.org/doc/en/gentoo-kernel.xml - it explicitly lists mm-sources as unsupported.
