sis(4) flow control

[Yonghyeon PYUN]

On Sat, Jul 13, 2013 at 10:30:40PM +0200, Andreas Longwitz wrote:
> Yonghyeon PYUN wrote:
> 
> >>> Try attached patch and let me know how it works.
> >> Thanks for your patch. I will test it on next update of my soekris boxes
> >> with sis interfaces. Because they are all remote far away this will need
> >> some time.
> > 
> > Ok. Make sure to check established link before testing
> > flow-control. 'ifconfig sis0' will show current media and you
> > should have something like the following.
> >   ...
> >   media: Ethernet autoselect <flowcontrol> (100baseTX <full-duplex,flowcontrol,rxpause,txpause>)
> > 
> > If you don't see 'rxpause', re-negotiate flow-control with
> > 'ifconfig sis0 mediaopt flow'.
> 
> Because sis(4) (soekris 4801) is not available for me at the moment, I
> tried with vr(4) (soekris 5501). In production I run both types of boxes
> with FreeBSD 6 and a simple SETBIT patch to honor RX pause frames.
> Now I want to go with FreeBSD 8 Stable and eliminate my patch.
> 
> "ifconfig vr0" gives
>    media: Ethernet autoselect (100baseTX <full-duplex>),
> therefore I tried (using serial console) "ifconfig vr0 flow"
> and now "ifconfig vr0" as expected gives
>    media: Ethernet autoselect <flowcontrol> (100baseTX
>      <full-duplex,flowcontrol,rxpause,txpause>),
> but the interface vr0 hangs. Outgoing packets are ok, but all incoming
> packets are blocked. In this situation I can give "ifconfig vr0
> -mediaopt flowcontrol" and see after "ifconfig vr0"
>    media: Ethernet autoselect (none)
>    status: no carrier
> and one second later
>    media: Ethernet autoselect (100baseTX <full-duplex>)
>    status: active
> and interface works correct again.
> 

Hmm, I recall flow control worked on VT6105 when I initially added
the feature but it seems there is an issue on that. vr(4) needs
driver assistance to generate TX pause frames so I guess vr(4) may
not be good link partner to verify flow-control. vr(4) controllers
also does not have hardware MAC counters so it would be hard to
know how many pause frames were processed in the controller.

> >From console:
> vr0: <VIA VT6105M Rhine III 10/100BaseTX> port 0xe100-0xe1ff mem
>    0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0
> vr0: Quirks: 0x2
> vr0: Revision: 0x96
> miibus0: <MII bus> on vr0
> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
> ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto,
>          auto-flow
> vr0: Ethernet address: 00:00:24:cb:1e:34
> vr0: [ITHREAD]
> 
> My switch is D-Link DGS-1008D green Ethernet (has support for IEEE
> 802.3x Flow-Control). On the same switch I have connected two other
> machines using msk driver (88E8050 and 88E8055) and "ifconfig msk0"
> gives always
>   media: Ethernet autoselect (1000baseT
>         <full-duplex,flowcontrol,rxpause,txpause>)
> 
> Maybe there is a bug in vr(4) that generates the hang, but why is

Probably yes and I shall have to narrow down the issue.

> negotiation of flowcontrol on vr(4) not done at boot time as shown for
> msk(4) ?
> 

msk(4) supported flow-control from day 1 with a hack and it was
re-implemented later with proper way such that it always announces
flow-control. However for other drivers(i.e vr(4)) that didn't
support the feature in the beginning, you have to explicitly enable
the feature. The decision was made to provide compatibility and to
not introduce POLA.

> If you need more information about the hang let me know.

I guess it would be good idea to use a link partner that shows
hardware MAC statistics. If your switch provides such information
that's fine. If you use direct connection between two hosts without
switch, use other network drivers(most gigabit controllers support
hardware MAC counters).