2009/11/1 Nick Kossifidis <mickflemm@xxxxxxxxx>: > 2009/10/31 Bob Copeland <me@xxxxxxxxxxxxxxx>: >> On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote: >>> Ok, to sum up some discussion from IRC: >>> >>> The initial packets that fail are not pings, but ARPs. Which are broadcast >>> frames. The access point simply fails to notify the station via DTIM for the >>> pending multicast frames, so it stays in PS. Unicast and the corresponding >>> TIM bitmap works properly, which also explains why it works once we got a >>> successful ARP (and it didn't expire, yet). >> >> I don't think this fixes everything (I'm still seeing some mishandled >> PS-poll frames) but this seemed to help pinging the PS client from the AP >> side. >> >> [Although we agreed beacon-sent-gated without a ready time component >> is the right way to go on the queue configuration, it seems badly >> broken in practice unless I'm missing some enable bit somewhere. So >> this is what ath9k does.] >> > > Well ready time is not disabled right now ! > > 416 ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL - > 417 (AR5K_TUNE_SW_BEACON_RESP - > 418 AR5K_TUNE_DMA_BEACON_RESP) - > 419 AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) | > 420 AR5K_QCU_RDYTIMECFG_ENABLE, > 421 AR5K_QUEUE_RDYTIMECFG(queue)); > > notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue > starts on time and we miss sync because we wait an extra ready-time > period. > Also i think we must use AR5K_DCU_MISC_ARBLOCK_IGNORE as we do for beacon frames so that CAB queue gets on top no matter what queues are pending (it already has the AR5K_DCU_MISC_ARBLOCK_CTL_GLOBAL). -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
