From owner-freebsd-current@FreeBSD.ORG Thu Apr 9 06:34:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98384106566B for ; Thu, 9 Apr 2009 06:34:14 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id F05188FC15 for ; Thu, 9 Apr 2009 06:34:13 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by fxm11 with SMTP id 11so425284fxm.43 for ; Wed, 08 Apr 2009 23:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VAUrDwISfzXz/QD4Zva5u8FTGv+xocn98/QF/91u7T8=; b=GvfYwT3D93JDWTMJ/5fKnyTI/Ij+qKJ5/Xp5Ilc4AYzAJYirwMJttmXVL0RUb2Z3Fc JNIyu1tjbVgj+/sCiw5TJqkUR6BPFI7J4ul0heFSkta4XQlwD8jQtC1O49f3XXSzkyaW I3g5yfVQKnd1Kwrxn2HVlaFpHC34SziInGFyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nw4Bdphg88QH14NUsA8aKQFLnjRY/Io7Q1jQoqDGOp1ZN/S95oZoomojghwipNlUv4 8He+YCtrVkArGbsWLLZQ8hIeqHYXVzY2ZouUCWKsFs0DyP2WRA4dVaGeYmuX47VZNGAh UiOkf9g+j4HmqnBh5EKra3tOA21bYmhHNj/z4= MIME-Version: 1.0 Received: by 10.223.122.70 with SMTP id k6mr628648far.26.1239258852931; Wed, 08 Apr 2009 23:34:12 -0700 (PDT) In-Reply-To: <20090409010953.GE37714@michelle.cdnetworks.co.kr> References: <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> <20090330024748.GF7076@michelle.cdnetworks.co.kr> <2e77fc10904071315q66d725bl76229d9bffd92f35@mail.gmail.com> <20090408024901.GC37714@michelle.cdnetworks.co.kr> <2e77fc10904072345o4d8215dcg561931ede528bcd6@mail.gmail.com> <20090409010953.GE37714@michelle.cdnetworks.co.kr> Date: Thu, 9 Apr 2009 09:34:12 +0300 Message-ID: <2e77fc10904082334v3fc9676cy97ad97f4e7fe6d0a@mail.gmail.com> From: Niki Denev To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 06:34:14 -0000 On Thu, Apr 9, 2009 at 4:09 AM, Pyun YongHyeon wrote: > On Wed, Apr 08, 2009 at 09:45:26AM +0300, Niki Denev wrote: >> Hi Pyun, >> >> On Wed, Apr 8, 2009 at 5:49 AM, Pyun YongHyeon wrote: >> > On Tue, Apr 07, 2009 at 11:15:47PM +0300, Niki Denev wrote: >> > >> > [...] >> > >> > I've read the datasheet but I still don't understand why dsp >> > programming in truephy_reset is required. Anyway would you try >> > attached patch? And show me dmesg output generated by truephy(4). >> >> Here is the dmesg output with the latest patch. >> >> truephy0: PHY 1 on miibus0 >> truephy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> >> >> > >> >> I have temporarily replaced the belkin USB ethernet interface with an >> >> Apple USB ethernet, >> >> which also uses the axe(4) driver, but is only 100Mbit/s. >> >> As I suspected the negotiation problems do not exist with it, and >> >> everything seemed ok, until >> >> it started to stop working exactly like the previous adapter. >> >> Pings start to return "buffer space not available" and replugging or >> >> "usbconfig reset" the interface >> >> returns it to normal status. >> >> >> > >> > This sounds like different issue to me. Let's focus on the >> > truephy(4) until axe(4) get a valid link report. >> > >> >> Ok. >> With this patch the old problems still persist. >> > > Can you add a couple of printf()s in if_axe.c:axe_miibus_statchg > and see how link state/speed reports are generated? Does it > cycle between 1000baseT-FDX and 100baseTX-HDX? > And the UTP cable you used was proven to work without problems with > gigabit link? It seems ET1011C performs automatic-downshifting so > I'd like to rule out it. > There are two switch statements in axe_miibus_statchg, and I've put printfs in each case in both of them, and the results is and in each call it matches once the two cases for 1000T and then, 100T and it repeats. I guess this means it cycles between 1000baseT-FXD and 100baseTX-FDX? As for the cables, I've also suspected this, and tried several Cat 5e cable= s, and right now I'm testing with Cat 6 cable which works with other gige hard= ware without problems. Also I've tried different switch ports on the ProCurve 18= 00-8G >> >> It looks like that the packet loss that I've experienced with the >> >> Belkin gigabit adabter is one problem, >> >> and the interface stopping to work another. >> >> >> >> P.S.: I don't know if it could be my USB hardware, because the machin= e >> >> is a little bit "exotic", >> >> an HP ex470 MediaSmartServer, which was supposedly designed to run >> >> only embedded version of >> >> Windows and has a nasty SiS chipset in it (with the unsupported sis19= 1 >> >> gigabit adapter) >> > >> > There had been a post for SiS191 driver. Check mailing list >> > archives. Unfortunately I don't have SiS191 controller so I >> > couldn't write a driver and commit the posted driver to tree. >> > Even though the controller is not for high performance servers it >> > would be enough to most desktop users. At least SiS controllers >> > does not seem to require special workarounds for silicon bugs which >> > are commonly found on RealTek/Marvell controllers. >> > >> >> Yes, I've tried to make this driver work for several days, I've found >> OpenSolaris driver and tried to get some stuff missing in the linux >> driver from it, >> but the best I got was to see some packets on the wire, but was never >> able to send anything. > > It's hard to say what was broken here but it seems SiS190 has > severe hardware limitation(no hardware padding, no multi dma segment > support, etc) You may use similar code of if_rl.c:rl_encap() or > if_vr.c:vr_encap(). > Thanks, I'll see if I can make it work. >> Also the SiS191 seems to have problems negotiating gigabit link, there >> are many posts about this >> when using Linux. >> > > This could be related with PHY handling bug of Linux sis190 driver. > Because Linux does not have mii(4) it have to poke PHY registers in > driver layer which =A0in turn would make it hard to support various > PHY hardwares. > I've noticed this. The linux drives seems to write some magic numbers to th= e hardware at several places... very confusing. >> > Alternatively you can use ndis(4) to use your SiS191 controller. I >> > don't know whether ndis(4) works for this controller though. >> > >> >> I've tried, but afair there were some functions in the driver that >> were not yet implemented >> in the ndis layer, so it didn't worked for me. >> > > Make sure you've used NDIS 5.0 compliant driver. ndis(4) does not > support NDIS 6.0 yet. > All of the drivers I've tested (and I could find for this chip) seem to be NDIS 5.1 (at least thats what is written in the .inf file) Many thanks, Niki