From owner-freebsd-mips@FreeBSD.ORG Thu May 23 17:56:26 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 28909DAF for ; Thu, 23 May 2013 17:56:26 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 9E982603 for ; Thu, 23 May 2013 17:56:25 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id er20so3504289lab.5 for ; Thu, 23 May 2013 10:56:24 -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=vF0WwZdX3oe+R8di/9drep9yVR0rr/R7+UMMzA57+NI=; b=lKGnoRsHtKUtTKVt7CSQB41AeZRw0qmTlxGl0SJvnjFVBV5EFievksyEttmxQluqLr epBEU81oCn4uvA5s8PLXrL4RotgKzwNHmYTgO6AGUuvK7NXwdU/7XsFiCHZL5bl5tKC9 ZQkShSLVZzA7wJN50sQdX1L1OwOiyZFbCY6gGktS2kgScFzy8EchgRAbxh4jkpjZI/Is YXHhSjMzQNMDRhJf66Hsfxe58bBX4FXHGwbgJvWzuuJtx8VI2FXaxZGy1gwtwYoz6MXk 32reaOFMbkQzCJhMBTgvlIkiLyk8p7ammDuOkmRo0edtms13i8UcTUPlP4314+PfcXRy v6BQ== X-Received: by 10.112.132.105 with SMTP id ot9mr284071lbb.66.1369331784444; Thu, 23 May 2013 10:56:24 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.129.195 with HTTP; Thu, 23 May 2013 10:56:04 -0700 (PDT) In-Reply-To: <07C411D8-C5D3-4CD4-896B-844F6514C3DF@bsdimp.com> References: <20130516111059.38543d57@wind.dino.sk> <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> From: Juli Mallett Date: Thu, 23 May 2013 10:56:04 -0700 X-Google-Sender-Auth: w7YjUXRbjw1jM-dTf6gTNbwvn-s Message-ID: Subject: Re: Ubiquiti EdgeRouter Lite works multi-user with -CURRENT. To: Warner Losh Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnh/xxPbpFJ5RVrvI/OQ8/ZsBNZGBizjMVxCW898IXPi8el6BsDiDviAWO2CECa2FKY9y/0 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: Thu, 23 May 2013 17:56:26 -0000 On Thu, May 23, 2013 at 10:43 AM, Warner Losh wrote: > > On May 23, 2013, at 5:42 AM, Milan Obuch wrote: > >> On Wed, 22 May 2013 22:59:36 -0700, Juli Mallett >> wrote: >> >>> On Wed, May 22, 2013 at 10:55 PM, Milan Obuch >>> wrote: >>>> Yes, you are right - now I checked with octe0 connected to 100 >>>> megabit switch and it initializes correctly when booting. When I >>>> plug gigabit card now instead, it does not work - no communication >>>> on interface. Even if I do ifconfig octe down/ifconfig octe up, it >>>> does not transmit/receive packets. So I think problem is phy link >>>> speed change on live system. Reboot in this case is a big hackish >>>> 'workaround' for now - good for tests, not yet fully for real work >>>> (but if you know there will be no link speed change it is OK). >>> >>> The link state management is crappy, I concede. I kept it as it was >>> in the Linux code because I wanted to be able to merge driver updates >>> from Cavium, but that's not viable given how much they've changed the >>> driver anyway. How long did you wait? It could take between 5 >>> seconds and a minute for link state to change at runtime in my >>> experience. I looked into making this faster at one point and even >>> had a patch, but don't know where it is or why I didn't commit it. >>> >>> If either of you wants to take a crack at fixing it I can explain what >>> to instrument in the driver and what's likely to be the problem. Let >>> me know if that might be useful. (Apologies of the latency is high on >>> my responding.) >>> >>> Thanks, >>> Juli. >> >> If you have any patches to test, some how-to what to look for and try >> to change etc... I could try to work a bit on it. It seems there is not >> much freely available resources for Cavium CPUs (I found cnusers.org is >> of interest, it seems) so some leading will be good to have :) > > cnusers is Cavium's release vehicle for GPL'd code... There's lots of code available for the Cavium processor, but the docs are kinda hard to get a hold of... And I'd add that the code is fairly complete and heavily-documented (well-documented is a different question; it can be a little obtuse.) Some people find code as useful or more useful than documentation, and in that case the code Cavium puts out is useful-enough, although most of it is already in src/sys/contrib/octeon-sdk, although I sometimes have found looking at the U-Boot code helpful, too. I've never found Cavium's documentation to be as useful as their code, but that's just me. 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); 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. Thanks, Juli.