From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6AC6521F0C8 for ; Fri, 25 May 2012 04:11:37 -0700 (PDT) Received: by wejx9 with SMTP id x9so1032422wej.16 for ; Fri, 25 May 2012 04:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TX8VeUN5IKEoYfZO81I8touB3OPg/YjrqrC+/V2Gbyw=; b=zzhlhrI/lcJKqPD7nE6fyA5bZj3Z3dn6Tkmh2vNtthAV26nNhuGKi5ehqnGQ6xDDae fia0ux3r+Qzf3dxIdg1AVfSdUJvntP3my7hpjUHhYWb0lQA2RlxIwCuEamv5YJiVusGd fxutFHN4OS0OR82QDe4MYnfLxL6N1tY7prWQTNjQKQRDI4xHN24OB43/Oo1Hm3nNQcFx 68NGnTR18w8tM0JmOAh+zTWCKPvJ/9/1DXDJOq3WyEahPKVezuGpCAszdhCDWkFxFy8l tU+a/NlMZoixjLTzuX+OvooZcR7xERKU2vH78OzqNuYfqV4itm8IaiNfqxkozD+7z1G9 w0WQ== MIME-Version: 1.0 Received: by 10.180.82.161 with SMTP id j1mr235657wiy.21.1337944295176; Fri, 25 May 2012 04:11:35 -0700 (PDT) Received: by 10.223.157.144 with HTTP; Fri, 25 May 2012 04:11:35 -0700 (PDT) In-Reply-To: <61BEA217-79A6-47C8-888D-101BC0EAFB45@gmx.de> References: <00404BC8-3761-409D-A1C8-9213D7D9A3DF@gmx.de> <1E435715-5C95-49AF-99D0-E8AD6EAD5B44@gmx.de> <4FBE5767.6080704@gmail.com> <4D0F5C65-2401-470F-A6D8-BE18E8BA25C7@gmx.de> <4FBE6290.9000701@freedesktop.org> <0E4C11DB-2B8A-411B-A61F-34B2A6BF57B9@gmx.de> <4FBE7AAB.5080307@freedesktop.org> <4FBE84C4.80607@gmail.com> <61BEA217-79A6-47C8-888D-101BC0EAFB45@gmx.de> Date: Fri, 25 May 2012 12:11:35 +0100 Message-ID: From: Robert Bradley To: Sebastian Moeller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] 3.3.6-2 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 11:11:38 -0000 On 25 May 2012 07:41, Sebastian Moeller wrote: > > Hi Robert, > > since I see the same log file on my router as Jim, I just want to report > my observations below. > > On May 24, 2012, at 11:58 AM, Robert Bradley wrote: (re. guest interfaces on wireless) > > Are these disabled on your routers at the moment? =C2=A0I suppose in th= e > > worst case you could try setting an explicit channel for both of the > > non-mesh guest interfaces and see if the logs clear up (or somehow pass= "-L > > /dev/null" to babeld). > > =C2=A0 =C2=A0 =C2=A0 =C2=A0After setting the 2.4GHz channel to 1 instead = of auto > /tmp/babeld.log still grows with the same entries. And on a WNDR3700v2 th= ere > are 30840 KB of tmpfs on /tmp so the babeld.log size of 256KB should not = by > itself cause the router to crash. That said, while testing this hypothesi= s > by filling most of /tmp (dd if=3D/dev/zero of=3D/tmp/delete_me bs=3D1024 > count=3D30000, so that around 340KB stayed free) the router reliably went > first into OOM and the rebooted itself. Might it be that the size of the > /tmp filesystem is too large if actually used? If I naively add the VSZs = of > most processes I end up at around 90% of available memory, so worst case > there actually only seems to be room for a much smaller /tmp than 30MB. . > Maybe restricting /tmp to 6000 KB might make this problem go away (or > hooking up a swap device). Does this reasoning sound sane? Once I figure = out > how to reduce the size of /tmp I will test this. > Using "mount -o remount -o size=3D6000k /tmp" should apparently work for that. The reasoning sounds good to me, too. That said, unless we can find an obvious reason for /tmp overfilling, I'm not sure we should do that, since it will cause problems upgrading. There's also the issue that in bug #379, only wireless traffic caused problems. I think that even if excessive logs are the problem, the real issue must be somewhere within the wireless driver, but I could well be wrong... I'm thinking that maybe flooding wireless->wired with UDP traffic for 5-10 minutes is the right approach, and then vice-versa (restarting the router inbetween?). If there are problems like infinite retries or packet memory leaks, that might show them up quickly. -- Robert Bradley