Alan,

On Thu, 13 Oct 2005, Alan J. Flavell wrote:

> This is just a comment.  I'm not saying anything is necessarily wrong.
> 
> When I attempt to build ndiswrapper (e.g versions 1.1 or 1.4, it 
> doesn't matter which) for SL4, the following warning is emitted:
> 
>  *** WARNING:  Kernel is compiled with 4K stack size option 
>  (CONFIG_4KSTACKS); many Windows drivers will not work with this 
>  option enabled. Disable CONFIG_4KSTACKS option, recompile and 
>  install kernel
> 
> Checking the configuration (/boot/config-*) for the kernels in 
> question, one can see indeed that CONFIG_4KSTACKS=y is set.
> 
> I suppose that this kernel build option is deliberate (same as the 
> "upstream vendor", whatever)...?

Yep and alot of the users of that vendors release wine about this too.

> 
> I can report that for at least one wireless card that I have tried 
> with ndiswrapper, the driver seems to work OK, despite this warning. 
> WIth a different card and its driver, however, the kernel hangs and 
> the machine has to be forcibly shut down.
> 
> In other respects I've been quite happy with ndiswrapper, as I've said 
> on this list before, and I'd recommend it as a solution, particularly 
> to folks who have occasion to use different wireless cards at 
> different times, irrespective of the availability of "native" linux 
> drivers for them.  (Version 1.2, now outdated, did not build on SL303, 
> however).
> 
> But it would be quite a nuisance if every kernel had to be rebuilt to 
> accommodate it.

Last week while on vacation I went to a Linux conference.  Andrew Morton 
was a speaker.  I asked him and Ted Tso about why RedHat would want to 
have the kernel use 4k kernel stacks vs 8k kernel stacks.  The answer was
it uses less memory.  Andrew said that kernel modules/drivers should be 
coded in such a way as to work in the 4k kernel stack space, and if they 
did not then it would be considered a bug in that module.

So based on that the ndiswrapper people should fix their code.  Now it may 
not be possible to do that because ndiswrapper is wrapping a binary driver 
which ndiswrapper has no control over.

If others find a combination of ndiswrapper that works please let us know 
so that we can include it.

 > > Comments, please? > 

-Connie Sieh