From: David Levitan (david_at_dlevitan.com)
Date: 2002-07-25 05:16:44 UTC
I download the latest CVS version - compiles fine and works well. I
dind't get much of a chance to test it, but I did transfer around 90 MB
at 315 KB/sec with no crash. Looks like its working fine so far. I'll
let you know if I find any problems.
Thanks for the fix,
David Levitan
Jouni Malinen wrote:
> At least some of the problems causing total hang on SMP hosts has now
> been fixed. I was unable to hang my test setup with yesterday's version.
> There were some further bugs that caused card resets, but I think these
> are now fixed. I have been unable to crash either the card or the host
> computer when flooding the system with few stations and performing
> management operations at the same time. I would appreciate if those who
> have seen crashes or kernel hangs on SMP platform with the older
> versions, could test this new version (i.e., the latest CVS snapshot
> from http://hostap.epitest.fi/).
>
> I'm not 100% sure what was causing the hang, but most probably one
> reason was in AP code sending management frames without using the same
> serialization mechanism as the data frames. Other reason could well have
> been in complex code used with command completion events only for
> transmit commands.
>
> I changed the management frames to use netdevice queue just like the
> data packets. This will guarantee that the frames will be subject to
> same restrictions than other packets (i.e., they do not perform BAP
> transfers or transmit commands within a data frame transmit). This made
> prism2_send_mgmt() function a much cleaner since it can now use the code
> of prism2_tx() for TX and host encryption. It should also be noted, that
> from now on, the net device has to be UP also for management frames
> (i.e., AP will see auth/assoc messages even with device down, but it
> will be able to reply to them only after the device has been set up).
>
> I did not get any TX timeouts during flood tests, but noticed some
> problems with manually forced card resets. It's possible that the driver
> is not able to reset the card in all situations, but at least this did
> not hang the host computer. Anyway, this is not much of a problem, if
> the card does not end up in state requiring resetting.
>