Send users mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com

or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."


Today's Topics:

   1. Re: Panic in rt2x00lib (Helmut Schaa)
   2. Re: Panic in rt2x00lib (Helmut Schaa)
   3. Re: Panic in rt2x00lib (TJ)


----------------------------------------------------------------------

Message: 1
Date: Mon, 10 Dec 2012 08:58:36 +0100
From: Helmut Schaa <[email protected]>
To: TJ <[email protected]>
Cc: [email protected]
Subject: Re: [rt2x00-users] Panic in rt2x00lib
Message-ID:
        <CAGXE3d8fNWakd=0ol1dfst2zog7oyq_azajuuqukugzcr95...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Him

On Sun, Dec 9, 2012 at 11:22 AM, TJ <[email protected]> wrote:
> Using Linksys WMP600N "05:01.0 Network controller [0280]: Ralink corp. RT2800 
> 802.11n PCI [1814:0601]" with hostapd in 802.11n mode is causing 
> unpredictable but guaranteed kernel panics. The panics
> occur when 802.11g (not n) devices are communicating. There's no guaranteed 
> way to reproduce but eventually the panic will occur.
>
> Using Ubuntu 12.04 with kernel 3.2.0-34-generic on 32-bit Pentium 4 hardware 
> originally, this also affects 3.7rc8 (3.7.0-030700rc8-generic Ubuntu mainline 
> build).

Are you using compat-wireless for mac80211/rt2x00?

> I noticed a discussion in this list back in November 2010 that seems to 
> describe the fault, as best as I can understand it, may be related to 
> adjusting the packet padding when packet resends are required.
>
> http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2010-November/002457.html

The patch in question didn't get in, so this must be something
different. Could you try to do a bisect
to find the commit introducing this crash?

Helmut



------------------------------

Message: 2
Date: Mon, 10 Dec 2012 09:17:52 +0100
From: Helmut Schaa <[email protected]>
To: TJ <[email protected]>
Cc: [email protected]
Subject: Re: [rt2x00-users] Panic in rt2x00lib
Message-ID:
        <cagxe3d-l9jhpe0nhlgp9fpcqgxxutjr_9t+vlqhqfisiyto...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 10, 2012 at 8:58 AM, Helmut Schaa
<[email protected]> wrote:
> Him
>
> On Sun, Dec 9, 2012 at 11:22 AM, TJ <[email protected]> wrote:
>> Using Linksys WMP600N "05:01.0 Network controller [0280]: Ralink corp. 
>> RT2800 802.11n PCI [1814:0601]" with hostapd in 802.11n mode is causing 
>> unpredictable but guaranteed kernel panics. The panics
>> occur when 802.11g (not n) devices are communicating. There's no guaranteed 
>> way to reproduce but eventually the panic will occur.
>>
>> Using Ubuntu 12.04 with kernel 3.2.0-34-generic on 32-bit Pentium 4 hardware 
>> originally, this also affects 3.7rc8 (3.7.0-030700rc8-generic Ubuntu 
>> mainline build).
>
> Are you using compat-wireless for mac80211/rt2x00?
>
>> I noticed a discussion in this list back in November 2010 that seems to 
>> describe the fault, as best as I can understand it, may be related to 
>> adjusting the packet padding when packet resends are required.
>>
>> http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2010-November/002457.html
>
> The patch in question didn't get in, so this must be something
> different. Could you try to do a bisect
> to find the commit introducing this crash?

Actually I just checked insert_l2_pad and remove_l2_pad. And it seems possible
that insert_l2_pad moves both, the header and the payload while remove_l2_pad
will only move the header. Hence, if the skb is resent by mac80211 after passing
a failed tx status of such a "header+data moved skb" it might happen
that we don't
have enough headroom in the skb anymore for the resend.

Mind to give [1] a try?

Thanks,
Helmut

[1] 
https://github.com/mirrors/openwrt/blob/master/package/mac80211/patches/606-rt2x00_no_realign.patch



------------------------------

Message: 3
Date: Mon, 10 Dec 2012 18:19:02 +0000
From: TJ <[email protected]>
To: [email protected]
Subject: Re: [rt2x00-users] Panic in rt2x00lib
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8

On 10/12/12 08:17, Helmut Schaa wrote:
> 
> Actually I just checked insert_l2_pad and remove_l2_pad. And it seems possible
> that insert_l2_pad moves both, the header and the payload while remove_l2_pad
> will only move the header. Hence, if the skb is resent by mac80211 after 
> passing
> a failed tx status of such a "header+data moved skb" it might happen
> that we don't
> have enough headroom in the skb anymore for the resend.
> 
> Mind to give [1] a try?
> 
> [1] 
> https://github.com/mirrors/openwrt/blob/master/package/mac80211/patches/606-rt2x00_no_realign.patch
> 

I shall do. It might be a few days until I get an opportunity since the 
affected system is a primary gateway server.

> Are you using compat-wireless for mac80211/rt2x00?

It's using the main-line kernel modules (no Ubuntu -cw- packages installed):

$ modinfo rt2x00lib
filename:       
/lib/modules/3.7.0-030700rc8-generic/kernel/drivers/net/wireless/rt2x00/rt2x00lib.ko
license:        GPL
description:    rt2x00 library
version:        2.3.0
author:         http://rt2x00.serialmonkey.com
srcversion:     9939FEA8C39CF23244C5DE0
depends:        mac80211,cfg80211
intree:         Y
vermagic:       3.7.0-030700rc8-generic SMP mod_unload modversions 686

$ modinfo mac80211
filename:       
/lib/modules/3.7.0-030700rc8-generic/kernel/net/mac80211/mac80211.ko
license:        GPL
description:    IEEE 802.11 subsystem
srcversion:     A7530D5435D8711D00F7434
depends:        cfg80211
intree:         Y
vermagic:       3.7.0-030700rc8-generic SMP mod_unload modversions 686
parm:           max_nullfunc_tries:Maximum nullfunc tx tries before 
disconnecting (reason 4). (int)
parm:           max_probe_tries:Maximum probe tries before disconnecting 
(reason 4). (int)
parm:           probe_wait_ms:Maximum time(ms) to wait for probe response 
before disconnecting (reason 4). (int)
parm:           ieee80211_default_rc_algo:Default rate control algorithm for 
mac80211 to use (charp)



------------------------------

Subject: Digest Footer

_______________________________________________
users mailing list
[email protected]
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com


------------------------------

End of users Digest, Vol 46, Issue 11
*************************************

Reply via email to