[Cerowrt-devel] Fwd: 3.3.6-2

[Sebastian Moeller]

Hi Jim,



On May 24, 2012, at 11:15 AM, Jim Gettys wrote:

> On 05/24/2012 02:12 PM, Sebastian Moeller wrote:
>> 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…
> 
> If you do, see if you can grab the babeld.conf file and add it to:
> https://www.bufferbloat.net/issues/392

	Done, attached to your issue.
	Turns out my babeld.log has grown to a similar size over 16:38 hours uptime. But:
root at nacktmulle:~# df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                    5.8M    940.0K      4.9M  16% /
/dev/root                 8.8M      8.8M         0 100% /rom
tmpfs                    30.1M    688.0K     29.4M   2% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock4            5.8M    940.0K      4.9M  16% /overlay
overlayfs:/overlay        5.8M    940.0K      4.9M  16% /

root at nacktmulle:~# free
             total         used         free       shared      buffers
Mem:         61676        59868         1808            0         6388
-/+ buffers:              53480         8196
Swap:            0            0            0

(No allocation failure logged yet)

Best
	Sebastian


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