From owner-freebsd-mips@FreeBSD.ORG Sat May 25 14:36:01 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AA7DDD2D; Sat, 25 May 2013 14:36:01 +0000 (UTC) (envelope-from freebsd-mips@dino.sk) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) by mx1.freebsd.org (Postfix) with ESMTP id DCC6A34C; Sat, 25 May 2013 14:36:00 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by mailhost.netlab.sk with ESMTPSA; Sat, 25 May 2013 16:35:55 +0200 id 004EB523.51A0CC4B.00006E8D Date: Sat, 25 May 2013 16:35:45 +0200 From: Milan Obuch To: Juli Mallett Subject: Re: Ubiquiti EdgeRouter Lite works multi-user with -CURRENT. Message-ID: <20130525163545.1fb37ea5@zeta.dino.sk> In-Reply-To: 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> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 14:36:01 -0000 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. Regards, Milan