From owner-freebsd-mips@FreeBSD.ORG Sat May 25 17:33:16 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A3F20D7B for ; Sat, 25 May 2013 17:33:16 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 1166DB9E for ; Sat, 25 May 2013 17:33:15 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id fp13so5338474lab.22 for ; Sat, 25 May 2013 10:33:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=JipubX75Qb6cG/vanHiqdUC/9J9De76xBZQts6RmbIw=; b=jOgjts7w4H6HKlsLuRhzs06EdFFxcUOhntjQaMtS/DB1k87TXgPp2ZymYz9hhV0jb7 sz69JJRSm3kA26kTWBSTg/+U/DYDImI8FAOGtInhBSp0UyebLN0EMiUTdqK/L38ukI+T lJnV3NRw84L7no+1FzAnuevWROosr0zlHK2p1zAmSPl50sool7sXuBp1FFAE5ByPRT8h m7nco+Du3kbjTNztOCUzSPEM/TmHSW+In9l7iRdmProhStPQQZfx8n2RRegRQR7ScXFA MfcVLdfTMY7RQ2c8T/scdrTBJDq9HXfB8Kl2ITVJ0bWunsYoJS1AxdRb09o73syk8ALL GXUQ== X-Received: by 10.112.180.232 with SMTP id dr8mr11225498lbc.67.1369503194800; Sat, 25 May 2013 10:33:14 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.129.195 with HTTP; Sat, 25 May 2013 10:32:54 -0700 (PDT) In-Reply-To: <20130525163545.1fb37ea5@zeta.dino.sk> References: <20130516131642.adfae355aa3bf7767e9b56e5@ddteam.net> <20130516124248.33ae4e05@wind.dino.sk> <51952112.9010607@rewt.org.uk> <20130517192206.5db0533f@zeta.dino.sk> <51966CB6.2040701@rewt.org.uk> <20130520110659.1d1d2165@zeta.dino.sk> <20130520164001.5f7d99b8@zeta.dino.sk> <20130520172508.087daf7b@zeta.dino.sk> <20130523070225.4d9a3a59@zeta.dino.sk> <519DA801.2090205@rewt.org.uk> <20130523075537.37e4bcba@zeta.dino.sk> <20130523134206.69ea6994@zeta.dino.sk> <07C411D8-C5D3-4CD4-896B-844F6514C3DF@bsdimp.com> <20130525163545.1fb37ea5@zeta.dino.sk> From: Juli Mallett Date: Sat, 25 May 2013 10:32:54 -0700 X-Google-Sender-Auth: s3GCpblWs4gTpJ1xEvjO8sC2GMc Message-ID: Subject: Re: Ubiquiti EdgeRouter Lite works multi-user with -CURRENT. To: Milan Obuch X-Gm-Message-State: ALoCoQkF+ZXchgoTjdGEJe9PQK7ROli9YA/8QYtwrvDyNKmYQa1SRd8hID7JLLFfPnKXjkE9Sq1f Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Aleksandr Rybalko , "freebsd-mips@FreeBSD.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 17:33:16 -0000 On Sat, May 25, 2013 at 7:35 AM, Milan Obuch wrote: > On Thu, 23 May 2013 10:56:04 -0700, Juli Mallett > wrote: > > [ snip ] > > > In this case, I'd say that the most useful thing to instrument is > > likely cvm_do_timer in sys/mips/cavium/octe/ethernet.c. I'd suggest > > first changing: > > > > 138 if (priv->need_link_update) { > > 139 updated++; > > 140 taskqueue_enqueue(cvm_oct_link_taskq, &priv->link_task); > > 141 } > > > > To be just > > > > taskqueue_enqueue(cvm_oct_link_taskq, &priv->link_task); > > > > It took me some time to respond for some reasons, anyway I built a > kernel with this change and there is something clearly wrong. There is > basically no change in behavior, if booted with gigabit connection, it > works with gigabit speed but not with 100 megabit and vice versa. Just > some cometic change - once per two seconds or so I keep getting on > console following > > octe0: Link down > octe1: Link down > octe2: Link down > > It looks like some phy register is not read correctly or not correct > phy register is read and acted upon. Just a guess, of course. > Interesting thing also not yet mentioned here - ifconfig octeN output > show correct speed in its media: line. > > Also, when changing cables, I got following printed on console: > > Port 0 receive error code 13, packet dropped > > No idea it if shows something, for now. > > > If that helps, then I think there's two things that need to be done: > > > > First, we shouldn't use slow-polling to do that anyway, we should just > > call taskqueue_enqueue whenever we set need_link_update to 1 if it was > > not 1 already. This is mostly a structural-cosmetic kind of thing. > > > > Second, cvm_oct_rgmii_poll in ethernet-rgmii.c is probably wrong in > > some way. Instrumenting it to print out the various register states > > and see if a human can see link status changes even if it can't may be > > helpful. Alternately, you may want/need to look at UBNT's patches for > > the ERLite. I may have missed some change it requires (if so, please > > let me know rather than just committing the changes; I've tried to > > isolate and keep minimal vendor-specific changes since we support so > > many vendors; not every vendor shares my concern, and a lot of them > > make the code too complex, or other things we don't want.) It could > > be just a matter of not using/programming/undermining RGMII in the way > > the hardware wants, or it could be that we need a PHY driver or > > something else. > > > > Actually, looking at how the hardware is set up, it looks like we > > should be using a PHY driver already, so it may be that none of that > > is helpful (since the internal link status management is only used if > > we don't have a PHY) and the real fix needs to happen in atphy.c. Or > > that for this hardware we should just use the internal link status > > management rather than using the PHY. > > > > In dmesg, following is relevant to ethernet, I think: > > octebus0: on ciu0 > Interface 0 has 3 ports (RGMII) > Warning: Enabling IPD when IPD already enabled. > Warning: Enabling PKO when PKO already enabled. > octe0: on octebus0 > miibus0: on octe0 > atphy0: PHY 7 on miibus0 > atphy0: OUI 0x00c82e, model 0x0007, rev. 2 > atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseSX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto octe0: bpf > attached octe0: Ethernet address: dc:9f:db:29:a3:92 > octe1: on octebus0 > miibus1: on octe1 > atphy1: PHY 6 on miibus1 > atphy1: OUI 0x00c82e, model 0x0007, rev. 2 > atphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseSX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto octe1: bpf > attached octe1: Ethernet address: dc:9f:db:29:a3:93 > octe2: on octebus0 > miibus2: on octe2 > atphy2: PHY 5 on miibus2 > atphy2: OUI 0x00c82e, model 0x0007, rev. 2 > atphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseSX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto octe2: bpf > attached octe2: Ethernet address: dc:9f:db:29:a3:94 > > so maybe something should be done in atphy driver as someone mentioned > later in this thread or between phy driver and some cavium code... I am > going to try to undestand the code in cavium/octe directory, but any > hint would be welcome for sure. > Ok, well, I have a slightly-radical hint :) In cvm_oct_mdio_setup_device, set phy_id to -1 instead of to cvmx_helper_board_get_mii_address(...). It's a silly thought, but I think there's a chance it might work. This would be using the internal link state management rather than using a PHY. (This isn't the right change to make to effect that, but it's worth a shot.) Thanks, Juli.