I'm trying to figure out the Wi-Fi issue that I'm encountering for my E8450 and came across this 'anomaly' which I couldn't figure out at the moment, so I thot maybe I would bounce this off folks here to pick your brains.
@tohojo, you may be able to cast some lights on it I would think.
So I added debug logs for my E8450 builds to the mac80211 backport driver, specifically to the ieee80211_txq_airtime_check() function. In this function, there's this section of code:
if (atomic_read(&air_info->aql_tx_pending) < air_info->aql_limit_low)
return true;
if (atomic_read(&local->aql_total_pending_airtime) <
local->aql_threshold &&
atomic_read(&air_info->aql_tx_pending) < air_info->aql_limit_high)
return true;
net_info_ratelimited("%s: returning false - txq->sta[0x%px], aql_tx_pend[%d], aql_ttl_pend_at[%d]\n",
__func__, txq, txq->sta,
atomic_read(&air_info->aql_tx_pending), atomic_read(&local->aql_total_pending_airtime));
return false;
I added debug statement to this function, just before the return false; statement to find out why it is returning false.
I get this sample output:
[ 3353.510831] ieee80211_txq_airtime_check: returning false - txq->sta[0xffffff8003b020f0], aql_tx_pend[61885024], aql_ttl_pend_at[12008]
It looks like the station's txq's aql_tx_pending value is computed using airtime in us (i.e. total time in us this station's queue has transmitted), while the interface's aql_total_pending_airtime value is computed using AQL's queue limit (which I assumed is in the unit of number of queued packets.)
Naturally, this will result in the ieee80211_txq_airtime_check() function returning false a lot, which shows up as this log:
[ 3353.482872] net_ratelimit: 37036 callbacks suppressed
The aql_total_pending_airtime and aql_tx_pending are both 32 bits integer, so aql_tx_pending will roll-over in a matters of days if the station is always transmitting. Could this be the reason why I start seeing issues after 3-4 days of use?
The ieee80211_tx_dequeue() function calls ieee80211_txq_airtime_check() and so my sole Wi-Fi client connected to the E8450 will be denied transmission, but somehow I'm still able to use the client to surf the Internet. I would assume that this will perpetually block transmission.
What I couldn't understand is that both aql_total_pending_airtime and aql_tx_pending are incremented using the same values, but it somehow shows up as vastly differently in value.
Maybe the experts in this forum can shed some lights?
Edit: Some users reported that setting aql_enable to '0' via debug_fs seems to solve the issue for them, as that would essentially make the ieee80211_txq_airtime_check() function always returning true and therefore will pass the first check in ieee80211_tx_dequeue(), among others. Coincidence?
Edit 2: I'm an idiot. Apologies. There's a bug with the debug statement. There was an addition argument passed into the printout causing the printout to output a pointer instead of the value. Now I get this, which is as expected:
[ 206.251919] ieee80211_txq_airtime_check: returning false - txq->sta[0xffffff80034dba60], aql_tx_pend[12040], aql_ttl_pend_at[12040]
[ 245.604440] net_ratelimit: 4435 callbacks suppressed
Back to square one.
