On Thu, 13 Oct 2005, Connie Sieh wrote:

> > 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.
[...]

OK...  thanks for the feedback.

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

Exactly!  The problem is not with the ndiswrapper code itself, but 
with the binary-only Windows drivers which it wraps.

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

Well, ndiswrapper-1.1 worked great with SL3.0.3 (and doubtless with 
other SL3.0.x versions), with a number of different cards that I 
tried: a cheap Edimax card - EW-7108PCg - based on the rt2500 chipset; 
a cheap unbranded card based on the ti1130 chipsest; and some rather 
expensive branded cards that I borrowed from others a while back.  In 
each case I was guided in the choice of driver by their then-current 
Wiki entry, see 
http://ndiswrapper.sourceforge.net/mediawiki/index.php/List

ndiswrapper-1.2 source did not build correctly in SL303, but, as I was 
happily using -1.1, I didn't worry about it.  Version -1.3 had already 
been superseded before I spotted it.  ndiswrapper-1.4 is just out, and 
initial indications are that it works fine for me.

So much for SL303...

Current, limited, experience so far with SL4 was that the 
rt2500-based card works, with the same driver as was used in 
SL303, even with the distributed kernel (4KSTACKS, as discussed).

But the ti1130 driver that I had used in SL303, as I mentioned above, 
causes a hang in SL4. This seems to be true whether I used 
ndiswrapper-1.1 or -1.4 (no surprises there, really).

See also 
http://ndiswrapper.sourceforge.net/mediawiki/index.php/Fedora#4k_kernel_stack_size.2Ffreezing_issue
(the ndiswrapper pages don't discuss RHEL as such).

As far as I can see, their writeups are based entirely on the plan of 
building a kernel without the 4KSTACKS option, rather than on 
selecting a driver which is compatible with 4K stack size.  But there 
are several drivers mentioned on their list for this chipset, so I've 
got scope to try others yet, if one wants to avoid rebuilding the 
kernel.  I've an open mind at the moment as to which way to go.

Was that helpful at all?  Cheers