On Thu, November 18, 2010 23:38, Pyun YongHyeon wrote: > On Thu, Nov 18, 2010 at 10:40:10PM -0200, Nenhum_de_Nos wrote: >> >> On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: >> > On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: >> >> >> >> On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: >> >> > On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: >> >> >> >> >> >> On Thu, November 18, 2010 13:10, Derrick Brashear wrote: >> >> >> > The following reply was made to PR usb/140883; it has been noted >> by >> >> >> GNATS. >> >> >> > >> >> >> > From: Derrick Brashear <sha...@gmail.com> >> >> >> > To: bug-follo...@freebsd.org, sub.m...@gmail.com >> >> >> > Cc: >> >> >> > Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs >> >> after >> >> >> > short >> >> >> > period of traffic >> >> >> > Date: Thu, 18 Nov 2010 09:36:50 -0500 >> >> >> > >> >> >> > Pyun has provided an updated driver which avoids several issues >> >> >> > including using a too-large transmit buffer (the chipset claims >> >> only >> >> >> > 8k) but none of the fixes worked until he disabled frame >> combining >> >> >> for >> >> >> > transmit. With only a single packet being sent per frame (as >> was >> >> the >> >> >> > case in FreeBSD 7, apparently) seems to make the issue go away. >> >> None >> >> >> > of the cases I could use to reproduce the issue now happen. >> >> >> > >> >> >> > -- >> >> >> > Derrick >> >> >> >> >> >> is this already in 8-stable ? I have a couple of axe(4) based >> nic's >> >> >> they're not ok on 8-stable. I've talked to Pyun before, and that >> time >> >> >> seemed do solve the issue (with gigabit belkin axe based) but now >> I >> >> >> can't >> >> >> get them to work anymore. even fast ethernet linksys axe are just >> >> dying >> >> >> when in a bridge (switched to OpenBSD to have it working). >> >> >> >> >> >> how ca I try this to help ? >> >> >> >> >> > >> >> > I uploaded updated if_axe.c/if_axereg.h to the following URL. >> >> > http://people.freebsd.org/~yongari/axe/if_axe.c >> >> > http://people.freebsd.org/~yongari/axe/if_axereg.h >> >> > >> >> > That files seem to fix axe(4) hang which were seen on AX88772A >> >> > controller. One of most notable changes are removing combining >> >> > multiple TX frames in TX path such that this change may result in >> >> > sub-optimal performance for most axe(4) controllers. However it >> >> > seems that change makes Derrick's controller work without problems. >> >> > Generally I prefer driver stability over performance so if this >> >> > change also fixes other axe(4) stability issues reported so far, I >> >> > want to check in the change. >> >> > >> >> > Thanks. >> >> >> >> well, >> >> >> >> things did got better here. but the link state UP and DOWN are still >> >> there :( >> >> >> >> ugen2.3: <vendor 0x050d> at usbus2 >> >> axe1: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on usbus2 >> >> axe1: PHYADDR 0xe0:0x01 >> >> miibus2: <MII bus> on axe1 >> >> ukphy2: <Generic IEEE 802.3u media interface> PHY 1 on miibus2 >> >> ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> 1000baseT-FD >> >> X, auto >> > >> > It seems you have PHY driver issue. Normally all gigabit PHYs >> > should have their own PHY driver since most PHYs hardwares tend to >> > have a special register that reports link state changes. >> > Show me the output of "devinfo -rv | grep phy". >> >> there you are: >> >> devinfo -rv|grep phy >> ukphy1 pnpinfo oui=0xec6 model=0x1 rev=0x1 at phyno=16 >> ukphy2 pnpinfo oui=0xa080 model=0x28 rev=0x2 at >> phyno=1 >> ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1 >> > > Hmm.... You have many ukphys there. :-) I think the PHY attached to > the USB controller is ukphy2. The OUI indicates its maker is ASIX. > Unfortunately there is no dedicated PHY driver for this PHY. I > guess it may use a modified CICADA PHY though. Updated driver to > force GPIO configuration for this PHY. Would you try again after > downloading if_axe.c/if_axereg.h? It may show > "unknown PHY mode : 0xXX" if my guess is wrong.
I downloaded again from above links and are the same as the last: valfenda# md5 if_axe* MD5 (if_axe.c) = 388b7aa84f0d2471f8b144033103618b MD5 (if_axe.c.original) = c528c7cb5eb964a792d4c14dfaed47cf MD5 (if_axe.c.v1) = 388b7aa84f0d2471f8b144033103618b MD5 (if_axereg.h) = 10f85490cab59b8e40de261fd7ad81a5 MD5 (if_axereg.h.original) = 46f37d0f02a3c09463ceec58b743c6ce MD5 (if_axereg.h.v1) = 10f85490cab59b8e40de261fd7ad81a5 .original are files from 8-stable (via csup) .v1 are the files from http://people.freebsd.org/~yongari/axe/ downloaded when the fist test using those files were made. regular .c files were downloaded now when I read this mail. did you uploaded some new version in http://people.freebsd.org/~yongari/axe/ ? or I didn't got it ? :) should this modified version be a good test to fast ethernet axe nics ? my linksys USB200M failed when in bridge after some time of use :( same hardware I'm testing now. and the nics are ok, tested in OpenBSD with same hardware and same bridge and same pf conf file. thanks, matheus >> >> >> ue1: <USB Ethernet> on axe1 >> >> ue1: Ethernet address: "my mac shown here :)" >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> ugen1.2: <Microsoft> at usbus1 (disconnected) >> >> ukbd0: at uhub1, port 1, addr 2 (disconnected) >> >> ums0: at uhub1, port 1, addr 2 (disconnected) >> >> uhid0: at uhub1, port 1, addr 2 (disconnected) >> >> ue1: link state changed to DOWN >> >> ue1: link state changed to UP >> >> >> >> the good thing is, it usually never got recognized, and was said not >> to >> >> have a PHY (or something alike). >> >> >> > >> > Are you using 8.1-RELEASE? If yes, please give it try stable/8 and >> > use axe(4) I posted. >> >> sorry, forgot to add: >> >> uname -a >> FreeBSD valfenda.apartnet 8.1-STABLE FreeBSD 8.1-STABLE #2: Fri Nov 5 >> 01:52:06 BRT 2010 >> r...@valfenda.apartnet:/usr/obj/usr/src/sys/valfenda >> i386 >> >> and this is using that axe(4) you posted :) >> >> just got a little deeper, and put two of them (all I have) connected. >> when >> in 1000Base-TX FullDuplex, the throughput is horrible., never get more >> then 3% of the link (on side this FreeBSD Stable shown above, the other > > I'm not surprised with the poor performance since you have link > flapping issues. :-( > >> Win7 and belkin drivers for it). when I force for 100BaseTX FullDuplex >> on >> Windows, and this way I get 68Mbps out of it (need to say the windows >> task >> manager keeps showing 90% link utilization quite all time, some falls >> from >> time to time though). >> >> thanks as usual, >> > -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style _______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"