Re: axe(4) (Belkin F5D5055) problems

On Thu, Apr 9, 2009 at 4:09 AM, Pyun YongHyeon <pyunyh_at_gmail.com> wrote:
> 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.
>

There are two switch statements in axe_miibus_statchg,
and I've put printfs in each case in both of them, and the results is
and in each call it matches once the two cases for 1000T and then,
100T and it repeats. I guess this means it cycles between 1000baseT-FXD and
100baseTX-FDX?

As for the cables, I've also suspected this, and tried several Cat 5e cables,
and right now I'm testing with Cat 6 cable which works with other gige hardware
without problems. Also I've tried different switch ports on the ProCurve 1800-8G


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

Thanks, I'll see if I can make it work.

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

I've noticed this. The linux drives seems to write some magic numbers to the
hardware at several places... very confusing.

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

All of the drivers I've tested (and I could find for this chip) seem
to be NDIS 5.1 (at least
thats what is written in the .inf file)


Many thanks,
Niki