Kernel panic in ieee80211_calculate_rx_timestamp

Kernel panic in ieee80211_calculate_rx_timestamp

[Thomas Lindroth]

I recently got a ath9k_htc based dongle and running kismet for a few
hours results in a kernel panic (divide error) in
ieee80211_calculate_rx_timestamp with kernel 3.11.0.

The problem seems to occur when the call to cfg80211_calculate_bitrate
returns 0. I've used this patch to temporarily works around the problem.

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 2265445..037b737 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2156,6 +2156,9 @@ u64 ieee80211_calculate_rx_timestamp(struct
ieee80211_local *local,

        rate = cfg80211_calculate_bitrate(&ri);

+       if (WARN_ON(!rate))
+               return 0;
+
        /* rewind from end of MPDU */
        if (status->flag & RX_FLAG_MACTIME_END)
                ts -= mpdu_len * 8 * 10 / rate;


http://i.imgur.com/BrpaCgI.jpg here is the output of the panic.

/Thomas Lindroth

Re: Kernel panic in ieee80211_calculate_rx_timestamp

[Johannes Berg]

On Thu, 2013-09-19 at 20:01 +0200, Thomas Lindroth wrote:
> I recently got a ath9k_htc based dongle and running kismet for a few
> hours results in a kernel panic (divide error) in
> ieee80211_calculate_rx_timestamp with kernel 3.11.0.
> 
> The problem seems to occur when the call to cfg80211_calculate_bitrate
> returns 0. I've used this patch to temporarily works around the problem.

Seems fair, but maybe it should print out the rate info so you can see
what was actually received - most likely this is a driver bug though.

If you submit a patch that can be applied with signed-off-by etc. I can
apply it.

johannes

Re: Kernel panic in ieee80211_calculate_rx_timestamp

[Thomas Lindroth]

On 09/30/2013 04:27 PM, Johannes Berg wrote:
> On Thu, 2013-09-19 at 20:01 +0200, Thomas Lindroth wrote:
>> I recently got a ath9k_htc based dongle and running kismet for a few
>> hours results in a kernel panic (divide error) in
>> ieee80211_calculate_rx_timestamp with kernel 3.11.0.
>>
>> The problem seems to occur when the call to cfg80211_calculate_bitrate
>> returns 0. I've used this patch to temporarily works around the problem.
> 
> Seems fair, but maybe it should print out the rate info so you can see
> what was actually received - most likely this is a driver bug though.
> 
> If you submit a patch that can be applied with signed-off-by etc. I can
> apply it.

Sorry for the late reply. My first post was mostly meant as a bug
report. I don't have the insight needed for a proper fix but that patch
should point a developer in the right direction.

/Thomas Lindroth