From owner-freebsd-current@FreeBSD.ORG Wed Sep 23 21:24:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBF8C1065672 for ; Wed, 23 Sep 2009 21:24:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 9EDF88FC21 for ; Wed, 23 Sep 2009 21:24:32 +0000 (UTC) Received: by qyk6 with SMTP id 6so290240qyk.3 for ; Wed, 23 Sep 2009 14:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=d0JvWe+P92d44vk4XTcXNypWZqLkh1u/g3AUdR9UwyI=; b=vfaaf7a4T/UDzS7fQ+QVUi3SK7JaiBpxOhwxa9376fpbjm493E5pv1D5ADnI8AzesI HMKD8t3PvBxqCQtKFigN3Vo9iKkHOW0EdzZCUuL2MvHny3OBetTIqiV5KaN2y3gTL1uL MVvzDe0ewVlBPel34wNfsBiSg6QipWUcghBDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=c3w/Q+ADgdyDiHDcOrjdwTNjNAiuAjxdK6T8uYISlzXxmWlCOwYInaVz/TGERi2ofk 7QX0OWxG/eOjFt1Jtf/hYmYyx2dsQSkmbABcrXKowc5aQm1dOxKyKDhoXisJ/5qjjX1P b9E/xaDRBCdzkl4+7srrAwbhsg33R80wYsOjs= Received: by 10.224.92.194 with SMTP id s2mr2393685qam.383.1253737536817; Wed, 23 Sep 2009 13:25:36 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 5sm54004qwg.46.2009.09.23.13.25.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Sep 2009 13:25:34 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 23 Sep 2009 13:24:48 -0700 From: Pyun YongHyeon Date: Wed, 23 Sep 2009 13:24:48 -0700 To: Kristof Provost Message-ID: <20090923202448.GD1099@michelle.cdnetworks.com> References: <20090922211012.GE19069@nereid> <20090922235350.GB1520@michelle.cdnetworks.com> <20090923184149.GF19069@nereid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090923184149.GF19069@nereid> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: mge, mii/e1000phy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 21:24:33 -0000 On Wed, Sep 23, 2009 at 08:41:54PM +0200, Kristof Provost wrote: > On 2009-09-22 16:53:50 (-0700), Pyun YongHyeon wrote: > > On Tue, Sep 22, 2009 at 11:10:18PM +0200, Kristof Provost wrote: > > > I've been trying to get CURRENT running on a TS-7800 [1]. > > > It's based around a Marvell Orion SoC, with a Marvell 88E1118 PHY. > > > > > > It boots and tries to do bootpc_init. This fails because there are no > > > packets coming in or going out. > > > > > > A few thing's I've noticed: > > > - The PHY is misdetected as an 88E1116. Changing sys/dev/mii/miidevs so > > > it's detected as the 88E1118 it really is doesn't help. > > > > Please show me the output of "devinfo -rv | grep phy". > > > A little difficult as I need networking to get the root file system. > Instead I've got the content of the PHY ID 1 & 2 registers: > mii_id1: 0x0141, mii_id2: 0x0e11 > This seems to translate to a mii_model of 0x21, which corresponds to a > 'Marvell 88E1116 Gigabit PHY' according to sys/dev/mii/miidevs. > I'm pretty sure the device id for 88E1116 PHY is 0x21. Do you see printed model number 88E1118 on your hardware? If so I have no idea why Marvell use the same device id. Do you have access to 88E1118 HY data sheet? > > > - sys/dev/mii/e1000phy.c appears to contain a bug: > > > e1000phy_reset performs a switch on MII_MODEL(esc->mii_model) while > > > the rest of the code just uses esc->mii_model. This seems to be wrong > > > as the cases for 1118 (or 1116) are not triggered. Changing this also > > > doesn't appear to help. > > > > It's not a bug. First, I have to see your PHY id to know why you > > think so. > > > The switch on line 251 in e1000phy.c [1] is the only place the MII_MODEL > macro is used. The rest of the file (even in an earlier switch in the > same function) uses esc->mii_model directly. I've also confirmed the code > falls into the default case instead of the case MII_MODEL_MARVELL_E1116 > as I'd expect (because it detects the PHY as an E1116). > > The esc->mii_model value is already translated by MII_MODEL on line 147. > Ah, you're right, mii_model was already translated. Thanks for pointing out. > > > - Forcing the mge driver to IFM_100_TX (in mge_set_port_serial_control) > > > does work. The system manages to acquire a DHCP address. > > > > Would you also show me the output of "ifconfig -m mge0"? > > > What are you looking for? I can't run ifconfig obviously, but I can > probably extract the required information with a few strategic printfs. > I wanted to know advertised PHY capabilities as mge(4) explicitly disabled 1000baseT/half-duplex mode in driver layer. But MV88F5182 data sheet said it supports 1000baseT/half-duplex mode. > > I'm not author of mge(4) so I'm not familiar with mge(4). But it > > seems that mge(4) lacks link state change handler. Normally NICs > > are required to reprogram MAC to match resolved speed/duplex/ > > flow-control of link when it know it established a valid link which > > is notified from mii(4). > > > If that's the case I'd expect the driver not to work on my Sheevaplug > either. The only difference I see is the PHY. > Could be, but if you manually set media it reinitializes PHY and it will call mge_ifmedia_upd() which in turn reinitializes the controller. I guess this is workaround in mge(4). > Thanks, > Kristof > > [1] http://svn.freebsd.org/viewvc/base/head/sys/dev/mii/e1000phy.c?annotate=196366