[Cerowrt-devel] Fwd: 3.3.6-2

[Sebastian Moeller]

Hi Jim,

good point, I will go and see whether that is the cause for my crashes… Will return to this post if/when I have new data in either direction…

best
	Sebastian



On May 24, 2012, at 9:32 AM, Jim Gettys wrote:

> 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
>