Re: axe(4) (Belkin F5D5055) problems

On Wed, Apr 08, 2009 at 09:45:26AM +0300, Niki Denev wrote:
> Hi Pyun,
> 
> On Wed, Apr 8, 2009 at 5:49 AM, Pyun YongHyeon <pyunyh_at_gmail.com> wrote:
> > On Tue, Apr 07, 2009 at 11:15:47PM +0300, Niki Denev wrote:
> >
> > [...]
> >
> > I've read the datasheet but I still don't understand why dsp
> > programming in truephy_reset is required. Anyway would you try
> > attached patch? And show me dmesg output generated by truephy(4).
> 
> Here is the dmesg output with the latest patch.
> 
> truephy0: <ET1011C 10/100/1000baseT PHY> PHY 1 on miibus0
> truephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> 
> 
> >
> >> 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.
> >>
> >
> > This sounds like different issue to me. Let's focus on the
> > truephy(4) until axe(4) get a valid link report.
> >
> 
> Ok.
> With this patch the old problems still persist.
> 

Can you add a couple of printf()s in if_axe.c:axe_miibus_statchg
and see how link state/speed reports are generated? Does it
cycle between 1000baseT-FDX and 100baseTX-HDX?
And the UTP cable you used was proven to work without problems with
gigabit link? It seems ET1011C performs automatic-downshifting so
I'd like to rule out it.

> >> 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)
> >
> > There had been a post for SiS191 driver. Check mailing list
> > archives. Unfortunately I don't have SiS191 controller so I
> > couldn't write a driver and commit the posted driver to tree.
> > Even though the controller is not for high performance servers it
> > would be enough to most desktop users. At least SiS controllers
> > does not seem to require special workarounds for silicon bugs which
> > are commonly found on RealTek/Marvell controllers.
> >
> 
> Yes, I've tried to make this driver work for several days, I've found
> OpenSolaris driver and tried to get some stuff missing in the linux
> driver from it,
> but the best I got was to see some packets on the wire, but was never
> able to send anything.

It's hard to say what was broken here but it seems SiS190 has
severe hardware limitation(no hardware padding, no multi dma segment
support, etc) You may use similar code of if_rl.c:rl_encap() or
if_vr.c:vr_encap().

> Also the SiS191 seems to have problems negotiating gigabit link, there
> are many posts about this
> when using Linux.
> 

This could be related with PHY handling bug of Linux sis190 driver.
Because Linux does not have mii(4) it have to poke PHY registers in
driver layer which  in turn would make it hard to support various
PHY hardwares.

> > Alternatively you can use ndis(4) to use your SiS191 controller. I
> > don't know whether ndis(4) works for this controller though.
> >
> 
> I've tried, but afair there were some functions in the driver that
> were not yet implemented
> in the ndis layer, so it didn't worked for me.
> 

Make sure you've used NDIS 5.0 compliant driver. ndis(4) does not
support NDIS 6.0 yet.