Re: axe(4) (Belkin F5D5055) problems

On Mon, Mar 30, 2009 at 12:34 PM, Sepherosa Ziehau <sepherosa_at_gmail.com> wrote:
> On Mon, Mar 30, 2009 at 10:47 AM, Pyun YongHyeon <pyunyh_at_gmail.com> wrote:
>> On Mon, Mar 30, 2009 at 11:16:48AM +0900, Pyun YongHyeon wrote:
>>> On Sun, Mar 29, 2009 at 12:39:22AM +0200, Niki Denev wrote:
>>> > On Sat, Mar 28, 2009 at 6:42 PM, Niki Denev <ndenev_at_gmail.com> wrote:
>>> > > On Sat, Mar 28, 2009 at 12:27 PM, Pyun YongHyeon <pyunyh_at_gmail.com> wrote:
>>> > >> On Sat, Mar 28, 2009 at 11:59:13AM +0200, Niki Denev wrote:
>>> > >>> 2009/3/28 Pyun YongHyeon <pyunyh_at_gmail.com>:
>>> > >>> > On Fri, Mar 27, 2009 at 09:14:06PM +0200, Nikolay Denev wrote:
>>> > >>> >> -----BEGIN PGP SIGNED MESSAGE-----
>>> > >>> >> Hash: SHA1
>>> > >>> >>
>>> > >>> >> Hello,
>>> > >>> >>
>>> > >>> >> I'm running -current from 23.03.09 and I'm experiencing some axe(4)
>>> > >>> >> problems.
>>> > >>> >> Basically the network connection works but when some more serious
>>> > >>> >> traffic hits the
>>> > >>> >> interface (i.e. torrent download) it then dies, ifconfig down/up
>>> > >>> >> does not help, only replugging of the adapter.
>>> > >>> >>
>>> > >>> >> I've tried running with hw.usb2.axe.debug=15 and the output was many
>>> > >>> >> lines of:
>>> > >>> >>
>>> > >>> >> ? ?axe_bulk_write_callback:853: transfer complete
>>> > >>> >>
>>> > >>> >> then a pause of several seconds and the kernel begins to print :
>>> > >>> >>
>>> > >>> >> ? ?axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT
>>> > >>> >>
>>> > >>> >> Another strange thing that I noticed is that, while the interface
>>> > >>> >> seems to be
>>> > >>> >> connected and working, if I type many times ifconfig ue0 consecutively
>>> > >>> >> most of the time it would show different settings for the auto
>>> > >>> >> negotiated link.
>>> > >>> >> I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier,
>>> > >>> >> 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback.
>>> > >>> >>
>>> > >>> >> The switch does not seem to register link flaps.
>>> > >>> >>
>>> > >>> >
>>> > >>> > axe(4) requires exact link state/speed information from mii(4) to
>>> > >>> > reprogram controller to resolved speed/duplex. In this case
>>> > >>> > ukphy(4) seems to report fake link state/speed to axe(4).
>>> > >>> >
>>> > >>> >> The kernel messages for the interface are :
>>> > >>> >>
>>> > >>> >> ? ?ugen2.5: <Belkin Components> at usbus2
>>> > >>> >> ? ?axe0: <Belkin Components F5D5055, rev 2.00/0.01, addr 5> on usbus2
>>> > >>> >> ? ?axe0: PHYADDR 0xe0:0x01
>>> > >>> >> ? ?miibus0: <MII bus> on axe0
>>> > >>> >> ? ?ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
>>> > >>> >> ? ?ukphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
>>> > >>> >> 1000baseT, 1000baseT-FDX, auto
>>> > >>> >> ? ?ue0: <USB Ethernet> on axe0
>>> > >>> >> ? ?ue0: Ethernet address: 00:11:50:xx:xx:xx
>>> > >>> >>
>>> > >>> >> devinfo -vr | grep phy
>>> > >>> >> ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1
>>> > >>> >>
>>> > >>> >
>>> > >>> > This looks like Agere systems ET110C TruePHY. Would you try
>>> > >>> > attached patch? Because truephy(4) pokes some undocumented PHY
>>> > >>> > registers on PHY reset I'm not sure this model also requires that
>>> > >>> > magic to make it work though.
>>> > >>> >
>>> > >>>
>>> > >>> Hi Pyun,
>>> > >>>
>>> > >>> Thanks for the patch.
>>> > >>>
>>> > >>> With it the PHY is now detected as truephy.
>>> > >>> The only thing that i notice is that if the media status changes displayed with
>>> > >>> ifconfig are less frequent, and I mostly see 1000baseT-FDX and 100baseT-HDX
>>> > >>> The packet loss is still there, and the interface again stops to work
>>> > >>> after some time.
>>> > >>>
>>> > >>
>>> > >> Ok, revert previous patch and try attached one. This one does not
>>> > >> try to load ET1011C dsp codes. If this does not work next thing
>>> > >> would be try to load dsp code for ET1011C revision 1 model.
>>> > >> Not sure where I can find required dsp code.
>>> > >>
>>> > >
>>> > > There don't seem to be any improvement with the new patch.
>>> > > The packetloss and media status changes are still here.
>>> > > Maybe check Linux/Solaris/OtherBSD driver?
>>> > >
>>> > > --
>>> > > Niki
>>> > >
>>> >
>>> > LSI seem to have several documents about this phy chip, including
>>> > datasheet (which you probably have) and errata :
>>> > http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/DS06-161GPHY_ET1011C_09-28-2007.pdf
>>> > http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/ET1011C_Errata_08June2007.pdf
>>> >
>>>
>>> Yes, but unfortunately it is for model 3 or model 4. Yours is model
>>> 1. In fact I have no idea whether model 1 is ET1011C. It seems that
>>
>> I was wrong. The datasheet is for model 1, but revision number is
>> 4.
>>
>>> there are ET1011A or ET1011B PHYs.
>>>
>>> Sepherosa, do you have more information on ET1011A/ET1011B PHY?
>
> Nope, LSI site only has et1011c data sheet.  However, the model in the
> data sheet mismatches the PHY model on my available hardware.
>
>> It looks odd to me, by chance is model 4 typo? Does et(4) really
>
> Nah, its not typo, at least the hardwares I have (one OEM and one EVB)
> uses model 4.
>
>> recognize the PHY as truephy(4)? Also CCed to Xin Li who ported the
>> et(4) to FreeBSD.
>
>
>
> --
> Live Free or Die
>

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.

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 machine
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 sis191
gigabit adapter)