Thread: [Ndiswrapper-general] Re: ndiswrapper centrino
Status: Beta
Brought to you by:
pgiri
From: Stefan <ste...@gm...> - 2003-12-15 11:25:39
|
Hello, > On Mon, 2003-12-15 at 12:24, Stefan D=C3=B6singer wrote: > > Hello Pontus, > > This are the results of my test: > > The ping time is very fine, it's the same as with Window$ and it's only > > the half I got with driverloader: > > 64 bytes from 192.168.50.6: icmp_seq=3D5 ttl=3D64 time=3D2.85 ms > > 64 bytes from 192.168.50.6: icmp_seq=3D6 ttl=3D64 time=3D2.86 ms > > 64 bytes from 192.168.50.6: icmp_seq=3D7 ttl=3D64 time=3D2.63 ms > > 64 bytes from 192.168.50.6: icmp_seq=3D8 ttl=3D64 time=3D0.904 ms > > 64 bytes from 192.168.50.6: icmp_seq=3D9 ttl=3D64 time=3D1.19 ms > > 64 bytes from 192.168.50.6: icmp_seq=3D10 ttl=3D64 time=3D2.93 ms > > 64 bytes from 192.168.50.6: icmp_seq=3D11 ttl=3D64 time=3D2.76 ms > > > > Wep does not work yet. I can set a key, and if it's correct I get > > connected to the ap without setting an essid - that's more than > > driverloader could do. But I cannot ping anything(computer or AP), > > sending fails. The dmesg claims that sending succeeds, but the remoute = PC > > receives nothing. I will look at it. > > This is Giri's territory. > > > setinfo locks keventd up if the wait_event is enabled, but with > > wait_event disabled everything seems to work fine(also setting something > > with iwconfig) > > What command are you issuing that causes the call to setinfo. My driver calls set_int, your driver works(the workquere is not blocked whi= le=20 waiting for a result) > > > The driver seems stable to me, I loaded it 30 min. ago and it has not > > crashed yet, but it has flooded my logs. /var/log/messages grew to 1 MB > > since then. I will disable debug as soon as the problems are solved > > > :) Unloading also works fine! > : > > What was wrong before? Where did the receive fail? I tried with your > > driver yesterday and I got a lockup when sending something. > > The driver was not content with the packet flags, and the flags was read > using a macro so I had to dig deep into the disassembly and these things > tend to take a lot of time :( > > > I have an idea where my driver has a problem. It does not use the > > NdisGetFirstBufferFromPacketSafe you wrote. Maybe it's unused, but I > > think it's a macro for my driver. The MSDN also mentions > > NdisGetFirstBufferFromPacketSafe as a macro. This macro might not be > > content > > On My DDK it is a macro and it seems like it's not on newer DDKs. I just got the newest drivers for my NB and will try them now. > > > with our structures. I found that our ndis_packet structure disagrees > > with the one from mingw and reactos(the ndis_packet structures from min= gw > > and reactos are the same). > > Out packet struct should be compatible. What is the difference? The private part in the middle differs, but now I think that the mingw priv= ate=20 part is bigger because we have the oob data which is stored in the private= =20 char[X*sizeof(pvoid)] in mingw. > > > If you post a message to the list attach your driver because at least t= he > > driver of my acer travelmate 803 fails. Anyway, I am now ready to answer > > questions from others. /Stefan |
From: Giridhar P. <gi...@lm...> - 2003-12-15 14:22:24
|
Wow, thats great news. Pontus, party! I will not add any more features. I would like to make PM SMP safe. I guess that shouldn't be a problem. I will try to commit the changes soon. I don't have a way of testing for SMP, either. -- Giri |
From: Pontus F. <pon...@ta...> - 2003-12-15 11:36:33
|
> > Out packet struct should be compatible. What is the difference? > The private part in the middle differs, but now I think that the mingw private > part is bigger because we have the oob data which is stored in the private > char[X*sizeof(pvoid)] in mingw. This should be ok. Pontus |