[Cerowrt-devel] Fwd: 3.3.6-2

[Jim Gettys]

On 05/24/2012 12:18 PM, Sebastian Moeller wrote:
> Hi Robert,
>
> On May 24, 2012, at 8:44 AM, Robert Bradley wrote:
>
>> On 24/05/12 04:48, Sebastian Moeller wrote:
>>> A) under moderate wireless stress I get a lot of allocation failures from slub, like:
>>> [ 1221.664062] ath: skbuff alloc of size 1926 failed
>>> In the routers dmesg. And every now and then the router crashes and reboots (I have not yet found a way to make this happen reliably, it seems to require some uptime)
>> This looks to me like a possible memory leak somewhere, but I'm no expert.
> 	Not being an expert I concur.

My router's /tmp/log/babeld.log had grown to almost 256k. (and my router
had been flaky).

So I suspect that's making grim trouble as /tmp is a tmpfs: e.g. coming
out of ram.
-rw-r--r--    1 root     root        247936 May 24 12:27 babeld.log

Tail on the babeld file had:

Couldn't determine channel of interface gw00: Invalid argument.
Couldn't determine channel of interface gw10: Invalid argument.
Couldn't determine channel of interface gw00: Invalid argument.
Couldn't determine channel of interface gw10: Invalid argument.
Couldn't determine channel of interface gw00: Invalid argument.
Couldn't determine channel of interface gw10: Invalid argument.
Couldn't determine channel of interface gw00: Invalid argument.
Couldn't determine channel of interface gw10: Invalid argument.
Couldn't determine channel of interface gw00: Invalid argument.
Couldn't determine channel of interface gw10: Invalid argument.

I should probably have grabbed a copy before nuking the file.  /me bad....

Will put into redmine...

                          - Jim

>>  (Unless cerowrt is using tmpfs and filling up memory with logs, of course.)  
> 	I tried to check that, but since I can nor reproduce the crashes easily yet I have not been able to test that hypothesis (when I checked "df -h"  on the router there always was some room left, but heck for all I know it might be the log entries for the allocation failures that quickly eat up all the remaining memory) I will try to test this hypothesis. Currently I tried to check dmesg and free in rapid succession during the test runs that are prone to cause the crash free memory fluctuates some but I never saw it reach 0 just before crashing.
>
>> Is UDP from the wired side to the Internet also OK?  I'm assuming it is, but it would be nice to prove that it is actually a leak in ath9k and/or the wireless stack first!
> 	Actually I have not tested that yet (again with the crash somewhat hard to reproduce I will have to take the wireless out of use for 24 to 48 hours to be reasonably sure that the issue does not occur under wired connections). That said, I will go and work on that. So I have my testing work charted out and will post again once I have more data.
>
> Best
> 	Sebastian
>
>
>
>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel