From owner-freebsd-mips@FreeBSD.ORG Sun May 26 16:31:26 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 50159405; Sun, 26 May 2013 16:31:26 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id D0B6C1DF; Sun, 26 May 2013 16:31:25 +0000 (UTC) Received: from [172.16.9.23] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3bJRdt3kGHzvB; Sun, 26 May 2013 17:31:14 +0100 (BST) Message-ID: <51A238C1.1020900@rewt.org.uk> Date: Sun, 26 May 2013 17:30:57 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Juli Mallett Subject: Re: Ubiquiti EdgeRouter Lite works multi-user with -CURRENT. References: <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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Sun, 26 May 2013 16:31:26 -0000 Juli Mallett wrote: > 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. Just gave that a shot - results in unknown link type and no connectivity From owner-freebsd-mips@FreeBSD.ORG Mon May 27 11:06:49 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 EB378364 for ; Mon, 27 May 2013 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DC7E36CC for ; Mon, 27 May 2013 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4RB6nvv016083 for ; Mon, 27 May 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4RB6nJc016081 for freebsd-mips@FreeBSD.org; Mon, 27 May 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 May 2013 11:06:49 GMT Message-Id: <201305271106.r4RB6nJc016081@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-mips@FreeBSD.org Subject: Current problem reports assigned to 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: Mon, 27 May 2013 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/178319 mips [patch] [arge] arge_stop() doesn't clean the tx ring p o kern/178318 mips [patch] [arge] if_arge/bootp race under some circunsta o kern/177876 mips [mips] kernel stack overflow panic on mips64, EdgeRout o kern/177832 mips [mips] [gpio] [patch] GPIO and RF LED do not function o kern/177032 mips [arge] arge1 fails to attach on UBNT Routerstation o kern/165951 mips [ar913x] [ath] DDR flush isn't being done for the WMAC p kern/163670 mips [mips][arge] arge can't allocate ring buffer on multip 7 problems total. From owner-freebsd-mips@FreeBSD.ORG Wed May 29 13:34:33 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 89DF2832 for ; Wed, 29 May 2013 13:34:33 +0000 (UTC) (envelope-from onlinesjournals@gmail.com) Received: from mail-bk0-x241.google.com (mail-bk0-x241.google.com [IPv6:2a00:1450:4008:c01::241]) by mx1.freebsd.org (Postfix) with ESMTP id 0A58CE9B for ; Wed, 29 May 2013 13:34:32 +0000 (UTC) Received: by mail-bk0-f65.google.com with SMTP id ji1so1137941bkc.0 for ; Wed, 29 May 2013 06:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:reply-to:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority; bh=dsyZItvfVn5IylE6yrlPUKZwt/glDkRaYG4rLG/wUpU=; b=FaK7EZMyPBAtvkNdeoE/hX/x88SOl9b+xVyfHh7EwH4K7zjxjaKPzicXc95imG41lk tokE6LlncGVDlfJeZs2E/l3mFfzmWsq9NP1ky2u7KIhA7LBaw9rf+cItdcjGCvdsPi+9 1TiEydG10Knb7kwY7pMkQ2w4m6ES1IzMmpaTaLATDSvPpIATcRlwqlo7cRWFuSN5HOng Ije6KevSVMyfRJltqBdgZjdU2ugzfSRFtbyGpdEyAtFKeV0pOS6WOthVUy8db/mFNY37 ZexTqd6bMtkO7g6hZ5S0jqtyzYxlsAuJ6N1N+ce5RRVeh3Jgyh8Tk3BZNtx7rTHz9PSS f8xw== X-Received: by 10.204.188.70 with SMTP id cz6mr692901bkb.122.1369834472058; Wed, 29 May 2013 06:34:32 -0700 (PDT) Received: from Benyamin-PC ([2.187.52.102]) by mx.google.com with ESMTPSA id rj5sm11172351bkb.1.2013.05.29.06.34.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 29 May 2013 06:34:31 -0700 (PDT) Message-ID: <0324beaf-41423-01ff2738864815@benyamin-pc> From: "Sjournals" To: freebsd-mips@freebsd.org Subject: Sjournals Services (Open Journal Management system, Sjournals Index, ...) Date: Wed, 29 May 2013 06:33:36 -0700 X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Sjournals List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:34:33 -0000 Dear Researchers We provide high quality services and strive to ease all steps from submission to publication of high quality research work. 1. [1]Sjournals Manager (FREE of charge) The [2]Sjournals Manager manages the overall publishing system. The [3]Sjournals Manager does the setup for the journal, and enrolls the Editors, Section Editors, Copyeditors, Layout Editors, Proofreaders, and Reviewers. The [4]Sjournals Manager cordially invites you to join the peer reviewed journals of the Open Journal Management system and help us to produce good quality research in your area of expertise. With Sjournals Manager you can easily start your own journal. Scholars, institutions, conference organizers and scientific societies can all propose and launch new scientific journals. 2. Call for Paper (Vol 2 | Issue 6 | June 2013) We invite you to submit your manuscript(s) at [5]http://www.sjournals.com for rapid publication (via online submission system). Our objective is to inform author(s) of the decision on their manuscript (s) within one week of submission (All of Fields). Some of Indexing/Abstracting DOAJ, CABI Abstract, Global health, TEEAL (Cornell University), HINARI, CAS, ISC, Genamic JournalSeek, JournalTOCs, Academic Journals Database, PKP, Google scholar, SCIRUS, Index Copernicus, Academic keys, ResearchBib, Newjour, Electronic journals library, WorldCat, ProQuest, Open J-gate, library information service, GIF, Free journals act, etc. Submit your thesis abstract (*FREE*) Abstracts of all Master, Doctoral thesis will be submitted for inclusion in Sjournals Thesis, an online database used by researchers around the world. ST can be searched by author name, subject terms, and all words in the title and abstract. 3. [6]Sjournals Index (FREE of charge) The [7]Sjournals Index provides quantitative and qualitative tool for ranking, evaluating and categorizing the journals for academic evaluation and excellence. This factor is used for evaluating the prestige of journals. The evaluation is carried out by considering the factors like peer review originality, scientific quality, technical editing quality, editorial quality and regularity. 4. [8]Sjournals Conference Management System (FREE of charge) [9]Sjournals Conference Management System (SCMS) is a Web publishing tool that will create a complete Web presence for your scholarly conference. Don't hesitate to contact us if you have any questions. --- Kind Regards Sjournals Team Email: [10]Onlinesjournals@gmail.com [11]Onlinesjournals@yahoo.com [12]www.sjournals.com [13]www.sjournals.net [14]http://sjournals.net/ojs/index.php/index/about (Sjournals Manager) [15]http://sjournals.net/onlineconferencesystem/ (Sjournals Conference Management System) [16]http://sjournals.net/sjournalsindex (Sjournals Index) --------------------------------------------------------------------- ----------------------------------- P Think Green - don't print this email unless you really need to References 1. http://sjournals.net/ojs/ 2. http://sjournals.net/ojs/ 3. http://sjournals.net/ojs/ 4. http://sjournals.net/ojs/ 5. http://www.sjournals.com/ 6. http://sjournals.net/sjournalsindex/ 7. http://sjournals.net/sjournalsindex/ 8. http://sjournals.net/onlineconferencesystem 9. http://sjournals.net/onlineconferencesystem 10. mailto:Onlinesjournals@gmail.com 11. mailto:Onlinesjournals@gmail.com 12. http://www.sjournals.com/ 13. http://www.sjournals.net/ 14. http://sjournals.net/ojs/index.php/index/about 15. http://sjournals.net/onlineconferencesystem/ 16. http://sjournals.net/sjournalsindex From owner-freebsd-mips@FreeBSD.ORG Fri May 31 16:57:31 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 1ADB73F7; Fri, 31 May 2013 16:57:31 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAE7F9B; Fri, 31 May 2013 16:57:30 +0000 (UTC) Received: from [172.16.9.23] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3bMWzk6zjKzFM; Fri, 31 May 2013 17:57:22 +0100 (BST) Message-ID: <51A8D671.3000206@rewt.org.uk> Date: Fri, 31 May 2013 17:57:21 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Juli Mallett Subject: Re: Ubiquiti EdgeRouter Lite works multi-user with -CURRENT. References: <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> <51A238C1.1020900@rewt.org.uk> In-Reply-To: <51A238C1.1020900@rewt.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Fri, 31 May 2013 16:57:31 -0000 Joe Holden wrote: > Juli Mallett wrote: >> 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. > Just gave that a shot - results in unknown link type and no connectivity > _______________________________________________ Hm, one thing I have noticed is that when using carp, packets destined for the virtual mac address never reach the kernel - is this due to the hardware acceleration, and if so, is it possible to disable checking or some such without losing that ability (although at this point it may be futile anyway, since vlans and bridges seem to impair it's usefulness anyway) Thanks, Joe