Date: Fri, 19 Nov 2010 16:23:20 -0200 From: "Nenhum_de_Nos" <matheus@eternamente.info> To: pyunyh@gmail.com Cc: freebsd-usb@freebsd.org Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Message-ID: <603efbe44ab6deefcd86905280566f32.squirrel@eternamente.info> In-Reply-To: <20101119171324.GA13317@michelle.cdnetworks.com> References: <201011181510.oAIFA7SZ034209@freefall.freebsd.org> <833a33ce5369c53c6db220b79e379092.squirrel@eternamente.info> <20101118202426.GB8512@michelle.cdnetworks.com> <bab43754fb4c3361ef0d990af3c3bd07.squirrel@eternamente.info> <20101119000618.GC8512@michelle.cdnetworks.com> <32aed4c0a483f26c662dd513ea718a78.squirrel@eternamente.info> <20101119013857.GE8512@michelle.cdnetworks.com> <8ca59ffdfef13423f8a34d81cfdefc49.squirrel@eternamente.info> <20101119171324.GA13317@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, November 19, 2010 15:13, Pyun YongHyeon wrote: > On Fri, Nov 19, 2010 at 03:19:26AM -0200, Nenhum_de_Nos wrote: >> >> 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 <shadow@gmail.com> >> >> >> >> > To: bug-followup@FreeBSD.org, sub.mesa@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. back to this, no problem of unknown PHY: ugen2.2: <vendor 0x13b1> at usbus2 axe0: <vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 2> on usbus2 axe0: PHYADDR 0xe0:0x10 Root mount waiting for: usbus2 miibus1: <MII bus> on axe0 ukphy1: <Generic IEEE 802.3u media interface> PHY 16 on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: <USB Ethernet> on axe0 ue0: Ethernet address: my mac here ugen2.3: <vendor 0x050d> at usbus2 axe1: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on usbus2 axe1: PHYADDR 0xe0:0x01 Trying to mount root from ufs:/dev/ad0s3a 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-FDX, auto ue1: <USB Ethernet> on axe1 ue1: Ethernet address: my other mac here the ping still shows problems (on gbit controller at 100BaseTX): 62 packets transmitted, 55 packets received, 11.3% packet loss round-trip min/avg/max/stddev = 0.873/1.957/51.408/6.730 ms when in gigabit, no good: ping 192.168.1.3 PING 192.168.1.3 (192.168.1.3): 56 data bytes 64 bytes from 192.168.1.3: icmp_seq=2 ttl=128 time=1.533 ms 64 bytes from 192.168.1.3: icmp_seq=3 ttl=128 time=1001.806 ms 64 bytes from 192.168.1.3: icmp_seq=4 ttl=128 time=1.151 ms 64 bytes from 192.168.1.3: icmp_seq=5 ttl=128 time=1001.860 ms 64 bytes from 192.168.1.3: icmp_seq=6 ttl=128 time=1.317 ms 64 bytes from 192.168.1.3: icmp_seq=7 ttl=128 time=1.036 ms 64 bytes from 192.168.1.3: icmp_seq=8 ttl=128 time=1001.899 ms 64 bytes from 192.168.1.3: icmp_seq=9 ttl=128 time=1.273 ms ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host 64 bytes from 192.168.1.3: icmp_seq=16 ttl=128 time=0.992 ms 64 bytes from 192.168.1.3: icmp_seq=18 ttl=128 time=0.860 ms ping: sendto: No route to host 64 bytes from 192.168.1.3: icmp_seq=25 ttl=128 time=1.132 ms ping: sendto: No route to host 64 bytes from 192.168.1.3: icmp_seq=34 ttl=128 time=3003.569 ms 64 bytes from 192.168.1.3: icmp_seq=35 ttl=128 time=2002.963 ms 64 bytes from 192.168.1.3: icmp_seq=36 ttl=128 time=1002.208 ms 64 bytes from 192.168.1.3: icmp_seq=37 ttl=128 time=1.454 ms ^C --- 192.168.1.3 ping statistics --- 38 packets transmitted, 15 packets received, 60.5% packet loss round-trip min/avg/max/stddev = 0.860/601.670/3003.569/880.104 ms and: 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 >> 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 ? :) >> > > Oops, it seems I forgot to upload it after modifying it. > Please download again. MD5 should be > 507a672946e7c0394e83c79d1a12c9b5 (if_axe.c) and > 10f85490cab59b8e40de261fd7ad81a5 (if_axereg.h) > >> 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 > > Yes, the change made in if_axe.c is for AX88178, AX88772 and > AX8872A. The change has no effect for AX88172. Your controller would > be either AX88772 or AX88772A so chances are good to see different > behavior than ever before. I have no idea on how to see this ... is there anyway ? >> 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 by the way, you would not know if an interrupt storm on the irq of the fast ethernet axe would have anything to do with its driver, right ? it just happens when in bridge mode (I figured out why the bridge was stopping working - the other nic keeps working fine). thanks as usual, matheus -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?603efbe44ab6deefcd86905280566f32.squirrel>