K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-09-29T17:13:23.237233Z
K 7
svn:log
V 1377
Put in a temporary workaround for the strange rx behaviour I was seeing
when RXEOL occured.

Normally, I'd expect RXEOL to be followed by a dequeue of ATH_RXBUF number
of packets (here 512 for 11n.) But I'd occasionally see this only service
a handful at a time (and sometimes it'd service 0 frames!)

Since the RX descriptor list should be consistent and correctly linked
together after being processed, I gathered that something was interfering
with this process (eg rxlink was being set to NULL.)

I gathered that kickpcu and the interrupt mask update was racing.
So to work around it (and it's stopped the issue appearing so far) :

* clear kickpcu after the queue reset has been re-established and
  the RX has recommenced. This likely won't be very good for
  SMP machines as the taskqueue and ath_intr() calls can occur
  simultaneously on different CPUs. This means I'll have to
  eventually correctly lock this (or use atomics here.)

* If a MIB interrupt also pops in at the same time and kickpcu
  is currently 1, don't reset the interrupt mask. This stops the
  RXEOL/RXORN interrupt from being triggered until we've handled
  and cleared the original case.

As mentioned, this is only somewhat correct (read: not correct) for
the single CPU case, and definitely still very racy for the SMP case.
I'll need to come up with a better solution for this kickpcu stuff.

END