Hi Adrian, On Thursday 31 May 2012 12:18 AM, Adrian Chadd wrote:
(Yes, this is a public response.) Hi, That has me a bit concerned. Waiting for the STA to be associated is really just some kind of "settling" delay. You're still TX/RXing at that point.
yeah, but i am pretty sure in the STA mode we have this PLL registers having sane values once the STA is associated. i checked if i am missing hardware code/init_pll routine or if its actually overwritten by INI values, but no. i also checked this issue with IBSS and monitor mode even under shield room, still it did not show much improvements or more clue.
I think we need to speak to the baseband/clock teams and figure out why this is actually occuring.
oh yes and i had been already sending some mails internally, checking with people who might have good knowledge about this.
Can we please leave this out of the tree (but in the bug report) until this gets root caused internally?
one thing i observed was this rx hang detection is based on the 'delta of rx unicast packets' for a particular time. if its lesser than 5 this rx hang detection kicks off. another system expert told me this rx hang itself can be specific to AP rather than STA.
finally i would check with one system expert and another Engineer to get some thoughts, then send it as a PATCH.
Thanks, adrian
-- thanks, shafi -- 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
