Thread: [Ndiswrapper-general] Ndiswrapper + Qemu = 32-bit drivers in 64-bit mode?
Status: Beta
Brought to you by:
pgiri
From: Maxim G. <max...@gm...> - 2006-04-16 07:52:35
|
Wikipedia says about qemu: "* User mode emulation: QEMU can launch Linux processes compiled for one CPU on another CPU. Linux system calls are converted because of endianness and 32/64 bit mismatches. Wine and Dosemu are the main targets for QEMU." Isn't it what we need to launch 32-bit drivers in 64-bit mode? |
From: Maxim G. <max...@gm...> - 2006-04-16 08:30:40
|
Another option is to load 32-bit kernel with qemu and use ndiswrapper with it? Can somebody create such qemu image? |
From: Hans D. <han...@ta...> - 2006-04-16 09:28:57
|
It is of course a minor detail, but when I switched from 1.13 to svn = version of today, I noticed the signal level was no longer reported to iwconfig; only reporting this because perhaps other parts are disturbed. The changes with respect to the Atheros chipset in 1.13 are great, where high traffic volumes used to crash my machine (e.g. with p2p networking active) almost immediately, it now stays up more than a day; then it suddenly stops with a: Apr 16 10:28:09 videoserver kernel: ndiswrapper (free_tx_packet:470): = packet dropped: C0010002 and a page fault I'm upgrading to todays svn to see whether problem perhaps has been = solved. Keep up the good work, Giri! |
From: Giridhar P. <gi...@lm...> - 2006-04-16 13:31:08
|
On Sun, 16 Apr 2006 11:28:34 +0200, "Hans Dingemans" <han...@ta...> said: Hans> (e.g. with p2p networking active) almost immediately, it now Hans> stays up more than a day; then it suddenly stops with a: Hans> Apr 16 10:28:09 videoserver kernel: ndiswrapper Hans> (free_tx_packet:470): packet dropped: C0010002 and a page Hans> fault Hans> Keep up the good work, Giri! I have said it too often: Submit debug trace showing what caused this. Without trace, it is not possible to fix (I have never encountered this bug). And do some debugging yourself; e.g., try a different Windows driver. I have used blkwgn (for a device from Belkin - I don't remember which) version 06/01/2005,4.1.2.56 Error C0010002 means adapter is closing; in the absence of any clues (debug trace), I can only guess that somehow device is being removed (either physically or kernel decides to call ndis_remove_device). -- Giri |
From: Giridhar P. <gi...@lm...> - 2006-04-16 13:22:54
|
ndiswrapper runs in kernel space where switching between 32 and 64 bit is not possible. Hence no conceivable way to use 32 bit drivers in 64 bit kernel. Period. -- Giri |
From: Maxim G. <max...@gm...> - 2006-04-16 13:47:11
|
You can run another 32-bit kernel in qemu and 32-bit ndiswrapper in it. Or you can run windows driver in userspace 32-bit process and use it from 64-bit kernel. I think both scenarios are possible On 4/16/06, Giridhar Pemmasani <gi...@lm...> wrote: > > ndiswrapper runs in kernel space where switching between 32 and 64 bit > is not possible. Hence no conceivable way to use 32 bit drivers in 64 > bit kernel. Period. > > -- > Giri > |
From: Milan <em...@gm...> - 2006-04-16 19:09:00
|
On Ne, 2006-04-16 at 17:39 +0359, Maxim Grechkin wrote: > You can run another 32-bit kernel in qemu and 32-bit ndiswrapper in > it. Or you can run windows driver in userspace 32-bit process and use > it from 64-bit kernel. I think both scenarios are possible Nothing is impossible, that's right. But your scenario is, I'm afraid, very close to impossible. Some time ago, I had the same idea - run linux and ndiswrapper in qemu and somehow provide access to raw pci device. But, there are few problems: In first scenario, you run both linux and ndiswrapper in qemu. Which is nice, there is even pciproxy patch for qemu, which can help you with few things. BUT - problem is with DMA, which the card uses to access data in memory. You can provide qemu MMIO space and even interrupts from the card, but there it stops. You are running separate linux kernel instance and therefore, you have no knowlege about physical memory of the host. For DMA, you need linear portion of physical memory and provide pointer to physical memory to your adapter. Which is nearly impossible in emulated environment. Second scenario is in theory more real. You should be able to run an userspace 32bit driver, but still - it's already an userspace process, running within virtual memory environment. You can mmap /dev/mem to access MMIO of the card (or even have ndiswrapper to map it into your memory space). But again - if driver requests memory allocation, there is no guarantee that allocated memory will be contiguous - that should then handle kernelspace ndiswrapper too, and that's quite ugly IMHO. Not mentioning, that reading physical address of DMA buffer would be also work of kernel. Resulting software would be some hybrid between userspace and kernel-space program, probably hard to both code and maintain, and will likely cause a lot of problems. These are just few problems which came to my mind now; there might be (and probably are) other problems. The second scenario is a bit more possible than first one, but still is in highly theoretical plane. Although I'm not ndiswrapper developer, I think this would require changing a many parts ndiswrapper. So I agree with Giridhar: > > On 4/16/06, Giridhar Pemmasani <gi...@lm...> wrote: > > > > ndiswrapper runs in kernel space where switching between 32 and 64 bit > > is not possible. Hence no conceivable way to use 32 bit drivers in 64 > > bit kernel. Period. > > > > -- > > Giri > > > Milan Plzik |
From: Marcel W. <bal...@we...> - 2006-04-16 22:09:46
|
I had the same idea, but for usb-devices. Qemu can access real usb-devices. Can't you run a complete Linux and using ndiswrapper in it?? Then you can route it over a virtual network to the "real" 64bit-Linux. I now I'm crazy but is this possible?? |
From: Maxim G. <max...@gm...> - 2006-04-17 11:30:40
|
1) I whant to do it for usb devices too. I agree that there are many problems with pci cards but usb should be much easier. I think I'll try to do it. So I need image of 32-bit OS with 32-bit kernel and ndiswrapper. I tried Damn Small linux and Puppy linux but they use too old ndiswrapper to support my card. So I will try to create such image based on gentoo stage3 for i686. 2) scenario with userspace part could be implemented in ndiswrapper 2.0 so you will have reason for incrementing major version number. It will change only part of loading driver. All NDIS emulation could remain from ndiswrapper 1.x . And of course it will be better if ndiswrapper 2.0 will support both types (all in kernel space, driver in userspace and working with hardware in kernel space). I think problem with memory maps and over things could be solved. Userspace part will only provide translator from 32-bit calling convention to 64-bit one. On 4/17/06, Marcel Witte <bal...@we...> wrote: > I had the same idea, but for usb-devices. Qemu can access real > usb-devices. Can't you run a complete Linux and using ndiswrapper in > it?? Then you can route it over a virtual network to the "real" > 64bit-Linux. I now I'm crazy but is this possible?? > |
From: Maxim G. <max...@gm...> - 2006-04-19 15:44:15
|
No luck with 32-bit kernel in qemu. Qemu usb support isn't complete enogh. So I will try to use VMWare Player for this task I think they have better support for usb devices. On 4/17/06, Maxim Grechkin <max...@gm...> wrote: > 1) I whant to do it for usb devices too. I agree that there are many > problems with pci cards but usb should be much easier. I think I'll > try to do it. So I need image of 32-bit OS with 32-bit kernel and > ndiswrapper. I tried Damn Small linux and Puppy linux but they use too > old ndiswrapper to support my card. So I will try to create such image > based on gentoo stage3 for i686. > 2) scenario with userspace part could be implemented in ndiswrapper > 2.0 so you will have reason for incrementing major version number. It > will change only part of loading driver. All NDIS emulation could > remain from ndiswrapper 1.x . And of course it will be better if > ndiswrapper 2.0 will support both types (all in kernel space, driver > in userspace and working with hardware in kernel space). I think > problem with memory maps and over things could be solved. Userspace > part will only provide translator from 32-bit calling convention to > 64-bit one. > On 4/17/06, Marcel Witte <bal...@we...> wrote: > > I had the same idea, but for usb-devices. Qemu can access real > > usb-devices. Can't you run a complete Linux and using ndiswrapper in > > it?? Then you can route it over a virtual network to the "real" > > 64bit-Linux. I now I'm crazy but is this possible?? > > > |
From: Maxim G. <max...@gm...> - 2006-04-19 16:28:09
|
On vmware player ndiswrapper found devices but I cannot configure it. And normal blue led isn't working. Is someone other than me interested in it? On 4/19/06, Maxim Grechkin <max...@gm...> wrote: > No luck with 32-bit kernel in qemu. Qemu usb support isn't complete > enogh. So I will try to use VMWare Player for this task I think they > have better support for usb devices. > > On 4/17/06, Maxim Grechkin <max...@gm...> wrote: > > 1) I whant to do it for usb devices too. I agree that there are many > > problems with pci cards but usb should be much easier. I think I'll > > try to do it. So I need image of 32-bit OS with 32-bit kernel and > > ndiswrapper. I tried Damn Small linux and Puppy linux but they use too > > old ndiswrapper to support my card. So I will try to create such image > > based on gentoo stage3 for i686. > > 2) scenario with userspace part could be implemented in ndiswrapper > > 2.0 so you will have reason for incrementing major version number. It > > will change only part of loading driver. All NDIS emulation could > > remain from ndiswrapper 1.x . And of course it will be better if > > ndiswrapper 2.0 will support both types (all in kernel space, driver > > in userspace and working with hardware in kernel space). I think > > problem with memory maps and over things could be solved. Userspace > > part will only provide translator from 32-bit calling convention to > > 64-bit one. > > On 4/17/06, Marcel Witte <bal...@we...> wrote: > > > I had the same idea, but for usb-devices. Qemu can access real > > > usb-devices. Can't you run a complete Linux and using ndiswrapper in > > > it?? Then you can route it over a virtual network to the "real" > > > 64bit-Linux. I now I'm crazy but is this possible?? > > > > > > |