usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic

Nenhum_de_Nos matheus at eternamente.info
Fri Nov 19 05:19:31 UTC 2010


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 at gmail.com>
>> >> >> > To: bug-followup at FreeBSD.org, sub.mesa at 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
>> root at 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


More information about the freebsd-usb mailing list