The most common problem with Ndiswrapper is that it requires more than a 4k stack. The result you are getting may be coming from a stack overflow caused by a combination of Wine and Ndiswrapper. Compile and install the native drivers for your lan card and see if that makes a difference. The signal strength icon will also start working.
On Tue, 11 Jul 2006, gslink wrote:
The most common problem with Ndiswrapper is that it requires more than a 4k stack. The result you are getting may be coming from a stack overflow caused by a combination of Wine and Ndiswrapper.
The 4k stack issue you are talking about is a kernel stack. Wine is a user space application so anything Wine does with its stacks will have no impact on the kernel stack.
Now it is possible that Wine makes system calls that cause the kernel to recurse and blow its stack, but these calls could just as well happen in any run-of-the-mill Linux application. And in any case, this would be a kernel bug.
Francois Gouget wrote:
On Tue, 11 Jul 2006, gslink wrote:
The most common problem with Ndiswrapper is that it requires more than a 4k stack. The result you are getting may be coming from a stack overflow caused by a combination of Wine and Ndiswrapper.
The 4k stack issue you are talking about is a kernel stack. Wine is a user space application so anything Wine does with its stacks will have no impact on the kernel stack.
Now it is possible that Wine makes system calls that cause the kernel to recurse and blow its stack, but these calls could just as well happen in any run-of-the-mill Linux application. And in any case, this would be a kernel bug.
What you say is correct but the result is the same. The combination of NDISWRAPPER and any other program fails. In this case it is Wine. This is not the fault of Wine in any way but it happens. It is a good idea to keep this behavior in mind as NDISWRAPPER is not the only program that uses too much stack under some conditions and blows Wine.
On 7/24/06, gslink gslink@one.net wrote:
What you say is correct but the result is the same. The combination of NDISWRAPPER and any other program fails. In this case it is Wine. This is not the fault of Wine in any way but it happens. It is a good idea to keep this behavior in mind as NDISWRAPPER is not the only program that uses too much stack under some conditions and blows Wine.
NDISWRAPPER is not a program. It is a kernel driver. There is a huge difference: there's no protection to keep kernel driver bugs from killing the kernel or apps. And indeed, that's what you're seeing here. There should be *absolutely no* userspace app that can crash Wine (except by using up all swap space). Were there one, it would not be the app's fault, but rather a kernel bug.
If you want to use NDISWRAPPER, you probably have to configure your kernel with larger kernel thread stacks. See http://lwn.net/Articles/149977/ - Dan
Dan Kegel wrote:
On 7/24/06, gslink gslink@one.net wrote:
What you say is correct but the result is the same. The combination of NDISWRAPPER and any other program fails. In this case it is Wine. This is not the fault of Wine in any way but it happens. It is a good idea to keep this behavior in mind as NDISWRAPPER is not the only program that uses too much stack under some conditions and blows Wine.
NDISWRAPPER is not a program. It is a kernel driver. There is a huge difference: there's no protection to keep kernel driver bugs from killing the kernel or apps. And indeed, that's what you're seeing here. There should be *absolutely no* userspace app that can crash Wine (except by using up all swap space). Were there one, it would not be the app's fault, but rather a kernel bug.
If you want to use NDISWRAPPER, you probably have to configure your kernel with larger kernel thread stacks. See http://lwn.net/Articles/149977/
- Dan
You miss my point. Somebody puts a defective driver in Linux and Wine gets the blame. If you recompile your kernel with a larger stack you will have no problems. This particular stack bug has been responsible for numerous complaints about several programs that ran perfectly. It is not confined to NDISWRAPPER. If Wine or some other program starts doing this kind of thing it is best to look in the kernel. The problem is that it is hard to detect. I suspect we will be seeing more of this problem because when it happens it makes whatever program the user is running seem defective. If you can't figure out what is wrong with Wine then this is one place to look because there may not be anything wrong with Wine.