From owner-freebsd-mips@freebsd.org Tue Jul 31 23:21:18 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4207310680ED for ; Tue, 31 Jul 2018 23:21:18 +0000 (UTC) (envelope-from mail.gery@gmail.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEB9B83048; Tue, 31 Jul 2018 23:21:17 +0000 (UTC) (envelope-from mail.gery@gmail.com) Received: by mail-it0-x244.google.com with SMTP id e14-v6so7079668itf.1; Tue, 31 Jul 2018 16:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fyzTYtC7x4PeORQKny9YMgG0P/RAIt3NS4pYZ6AQfRk=; b=bWUQLPG6Z03HHKEqSVklFKov7/RBJa0Owh8Um8I6d8YazqfcT8/Eft0pT5PKmobIbk 8AgwNEKgqhDYZcqn1wTTy7QI2SAJB9EcNBVWFKm3iTrGCP4wOdYCj2EwRa8zSsATn+m5 2k0sg3+yhQ7TkPROdw+NbG/w0lKlFM6YXsD0nOvtJqCSx7rYMpAulI6KwN9VQtLOaSFK ncbitKN5Ts9Fy8J/QPJFVnhBht2ebloB9CVEWmEjHBPyFmqP15F/0flql6MjGKZ8NoCy CPiuW2y2xAQFmPXEuqL5MdxzwhUDasSnfa6OKRJ1+ZSWB2LEiImqdQxmObLbeQuNlUI3 e8hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fyzTYtC7x4PeORQKny9YMgG0P/RAIt3NS4pYZ6AQfRk=; b=qMe8UMPcrKwY1PNb3TNB4ok4VJPQsa91ZAL840Y3e2I5IRZRCt8auNJTh8jj/7G4jA wPkhdVwBSGoFUjgzaa4rTrWweM/mbdvdJaAV50iqV3aB7/HExAKP2nmJp/9DC5csgrZU KJmEzeCO9CcfGFbG9vd0DN5WrQwuNlCHvrFPbiMINRlVT+qFva5jaQ2RgvXLHC7tIAjm m3VPFzmaXHpnwVtNBzYRWPYpR3o6Bl0WGTEW1djm4FW67LPGmvc2W2DQVNBsWI0rrUJu /MPnKDdfUqc9eL6cqQC1Bs1Rbs+SiDbom9tq4Lz1c9PPcjsvBFLgQQtyc7jPg0aNgmMc OYAw== X-Gm-Message-State: AOUpUlFAeMgt3L9ebFIjk0wU5gf2c6y5wdKeGmjpKHQBxQ1P/swfrW66 8Lc55mWKzzzXH0xAYztPFEXMbPiLRsWF78IZuNepDK0R X-Google-Smtp-Source: AAOMgpclyMCTOxw3POW9hjvuBdm5WdpjH+MOfSSH3lG5Nx7EFJIvCtFcrEAjcJ67xDWGEebPYVI30rfhRUcplGclh5A= X-Received: by 2002:a24:f5c2:: with SMTP id k185-v6mr1576177ith.106.1533079276958; Tue, 31 Jul 2018 16:21:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:c4ca:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 16:21:16 -0700 (PDT) In-Reply-To: References: From: Gergely Kiss Date: Wed, 1 Aug 2018 01:21:16 +0200 Message-ID: Subject: Re: Possible arge driver bug - interrupt storm on int2 To: freebsd-mips@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 23:21:18 -0000 On 31 July 2018 at 15:45, Gergely Kiss wrote: > > Hi, > > I'm working on improving the freebsd-wifi-build project to have an out-of= -the-box gateway solution built on FreeBSD for SOHO routers. For more infor= mation, please see below link: > > https://github.com/kissg1988/freebsd-wifi-build > > I've created a build script that should simplify creating a build environ= ment from scratch: > > https://github.com/kissg1988/freebsd-wifi-build/blob/buildscript/scripts/= build.sh > > The goal is to make the distribution easy to build and use so it can be f= lashed just as simple as OpenWrt or DD-WRT. > > The device I'm working with is a TP-Link WN-1043ND v1.8 which has a Realt= ek RTL8366RB switch and is built around the AR9132 SoC. The board runs 11.2= -RELEASE currently. > > The ethernet controller works perfectly with a static or DHCP provided IP= address, however it seems something is wrong with the way the driver handl= es the TX queue in case 802.1Q tagging is in use and the system tries sendi= ng PPP frames over the tagged interface (eg. vlan2). > > Once ppp starts establishing the connection, packets to be sent are queue= d but not being transmitted by the controller and an interrupt storm is gen= erated with only the TX_UNDERRUN flag set (without the TX_PKT_SENT flag). > > This might be related to an issue seen a few years back: > > https://lists.freebsd.org/pipermail/freebsd-mips/2015-October/004137.html > > As PPPoE has an 8-byte overhead and VLAN tagging needs an additional 4-by= te field, I have lowered the MTU on arge0 and vlan2 to 1488 bytes but it di= dn't make any difference, the interrupt storm still happens and it's always= reproducible. Once it starts, the only way to stop the storm is to bring d= own arge0. > > If I destroy the vlan interface, and put the WAN port to an access VLAN w= ith no tagging, the PPPoE connection works fine. > > I'll make some more tests later today with -HEAD to see if it makes any d= ifference. > > Any help or ideas would be much appreciated in the meantime. > > Thanks, > Gergely > I have made some tests with -CURRENT and could reproduce the isssue exactly the same way as with 11.2-RELEASE. The version used for my tests is: FreeBSD 12.0-CURRENT #0 409735e6b1a(master)-dirty: Tue Jul 31 22:12:37 CEST= 2018 After setting sysctl dev.arge.0.debug=3D0x16 (ARGE_DBG_INTR | ARGE_DBG_TX | ARGE_DBG_ERR), this is what I see on the console a few seconds after starting the PPPoE connection: interrupt storm detected on "int2"; throttling interrupt source arge0: int mask(filter) =3D db arge0: status(filter) =3D 2 arge0: int status(intr) =3D 2 arge0: arge_intr: TX underrun; tx_cnt=3D18 tx_cnt keeps increasing every few seconds and never resets while the console is flooded with the lines above. The only way to stop the storm is to bring down arge0 (or power cycling the device, of course). I have noticed that setting the CPU port untagged for VLAN2 (ie. the WAN interface) solves the issue, so it's possible to have a workaround where VLAN1 is tagged on the CPU port (this works fine with "standard" Ethernet frames) and VLAN2 is untagged. However, I think this would not be an elegant way to handle this issue so I think about it as a last resort only. Please someone assist me with this as I'm not a driver developer, just an enthusiastic guy trying to improve what you guys (especially Adrian) have created, so far. Thanks, Gergely