Hi,
I'm new here so I apologize ahead of time if this is a known issue. In
my defense, I did a quick search on the archives.
My client machine (running wireless-testing kernel updated with git
today) panics when connecting to a hostapd access point (also running
ath9k) only when 802.11n is enabled on the access point.
More specifically, here is the hostapd configuration that causes the
client to crash:
ieee80211n=0
ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40]
If I disable 802.11n on the access point everything works ok.
Interesting enough, access point machine never crashes. At one point
both access point and client machine ran identical code and client
would always crash while the access point box would stay up. So
upgraded client to the latest and greatest and tried a few versions in
between, this panic has been very consistent. It always panics right
after 1st attempt to associate.
I was able to narrow down the panic to this assert ath_rc_ratefind_ht() in rc.c:
ASSERT((rate_table->info[rate].valid && !ath_rc_priv->single_stream) ||
(rate_table->info[rate].valid_single_stream &&
ath_rc_priv->single_stream));
When I ifdef'ed this assert panic went away and everything sort of
worked (haven't tested it heavily), but the performance dropped to
about 700Kbps. I usually get 10x when 802.11n is off and there is no
panic.
Has anyone else seen this?
I'm not including panic printk's because several routines get inlined
so panic printout points to the ath_get_rate(), but if you disass that
at the right offset you'll see the trap instruction and I'm pretty
sure I am barking up the right assert here :)
Here is the lspci output:
0c:00.0 Network controller [0280]: Atheros Communications, Inc.
Unknown device [168c:002a] (rev 01)
This client is a dell E1705 laptop with mini-pcie.
--
Regards,
Vladimir
Sujith wrote:
> Vladimir Senkov wrote:
> > My client machine (running wireless-testing kernel updated with git
> > today) panics when connecting to a hostapd access point (also running
> > ath9k) only when 802.11n is enabled on the access point.
> > More specifically, here is the hostapd configuration that causes the
> > client to crash:
> > ieee80211n=0
> > ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40]
>
> ieee80211n should be 1 to enable 11n.
>
> > If I disable 802.11n on the access point everything works ok.
> > Interesting enough, access point machine never crashes. At one point
> > both access point and client machine ran identical code and client
> > would always crash while the access point box would stay up. So
> > upgraded client to the latest and greatest and tried a few versions in
> > between, this panic has been very consistent. It always panics right
> > after 1st attempt to associate.
> >
> > I was able to narrow down the panic to this assert ath_rc_ratefind_ht() in rc.c:
> > ASSERT((rate_table->info[rate].valid && !ath_rc_priv->single_stream) ||
> > (rate_table->info[rate].valid_single_stream &&
> > ath_rc_priv->single_stream));
> > When I ifdef'ed this assert panic went away and everything sort of
> > worked (haven't tested it heavily), but the performance dropped to
> > about 700Kbps. I usually get 10x when 802.11n is off and there is no
> > panic.
> >
> > Has anyone else seen this?
>
> A couple of bugs were fixed dealing with this issue, but looks like more
> lurk around. Can you attach the hostapd.conf, hostapd logs (hostapd -d),
> client side kernel logs [1] ?, from loading the driver to the point when you associate
> and get the panic.
>
> [1]: See http://wireless.kernel.org/en/users/Drivers/ath9k on how to enable debug.
>
Oh, and using debug=0x2000 would be sufficient.
Sujith
Vladimir Senkov wrote:
> My client machine (running wireless-testing kernel updated with git
> today) panics when connecting to a hostapd access point (also running
> ath9k) only when 802.11n is enabled on the access point.
> More specifically, here is the hostapd configuration that causes the
> client to crash:
> ieee80211n=0
> ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40]
ieee80211n should be 1 to enable 11n.
> If I disable 802.11n on the access point everything works ok.
> Interesting enough, access point machine never crashes. At one point
> both access point and client machine ran identical code and client
> would always crash while the access point box would stay up. So
> upgraded client to the latest and greatest and tried a few versions in
> between, this panic has been very consistent. It always panics right
> after 1st attempt to associate.
>
> I was able to narrow down the panic to this assert ath_rc_ratefind_ht() in rc.c:
> ASSERT((rate_table->info[rate].valid && !ath_rc_priv->single_stream) ||
> (rate_table->info[rate].valid_single_stream &&
> ath_rc_priv->single_stream));
> When I ifdef'ed this assert panic went away and everything sort of
> worked (haven't tested it heavily), but the performance dropped to
> about 700Kbps. I usually get 10x when 802.11n is off and there is no
> panic.
>
> Has anyone else seen this?
A couple of bugs were fixed dealing with this issue, but looks like more
lurk around. Can you attach the hostapd.conf, hostapd logs (hostapd -d),
client side kernel logs [1] ?, from loading the driver to the point when you associate
and get the panic.
[1]: See http://wireless.kernel.org/en/users/Drivers/ath9k on how to enable debug.
Sujith