> > Thanks. Yes, I do realize that this is a bit intrusive. On the other > > hand, I can't see the code holding the spinlock for longer code/periods > > of time (nor should it). Or do you think the driver is allowed to call > > into the AMPDU TX setup path while being called from the AMPDU RX setup > > path? That would be a bit weird. > > > > TX and RX BA sessions are triggered from different threads of > execution namely rate scaling and RX path. The protected sections are > quite long IMHO including call outs to underlying driver. It is very > likely that both sides decides for BA session at the same times. Yes, but I still can't see how the driver would be calling both RX and TX aggregation functions /within each other/. That's the only thing that really matters since all the frame TX/RX is synchronized and thus the spinlock can't really be contended. Anyway, I need to look deeper into the code or just try or something. > > > Do you have any setup to check your these changes? > > > > Unfortunately not quite yet. I have an 11n AP now though, but broke of > > one of the antennas, I'll need to see how well it works. > > That's bad 11n is too sensitive on antennas setup. Yeah, I know. I don't know why my router has three antennas though knowing that the Broadcom HW only has two chains. > > > Currently there is known possible deadlock when unloading driver while > > > heavy HT traffic. This is happening while trearing down BA session. I > > > need to solve this as well. > > > > Interesting, where does it deadlock? > > IIRC there is nice loop including queue lock need to dig the > description tomorrow to satisfy your curiosity. Not too important so don't bother. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
