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 <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.

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
_______________________________________________
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"

Reply via email to