usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic

[Pyun YongHyeon]

On Fri, Nov 19, 2010 at 06:23:50PM -0200, Nenhum_de_Nos wrote:

[...]

> > Ok, try again after downloading new if_axe.c and let me know
> > the output "EEPROM data : 0xXX, phymode : 0xXX" shown on your
> > console.
> 
> never got to see that message. I saw the diff to previous version, and did
> boot into verbose mode (dmesg attached). there were just the belkin
> gigabit nic on boot. after, the linksys USB200M:
> 
> axe1: <vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 3> on usbus2
> axe1: PHYADDR 0xe0:0x10
> miibus2: <MII bus> on axe1
> ukphy1: <Generic IEEE 802.3u media interface> PHY 16 on miibus2
> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1
> ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> ue1: <USB Ethernet> on axe1
> ue1: bpf attached
> invalid media SR 0x700
> invalid media SR 0x700
> 

This is normal, the message I said will show up when you use
gigabit controller, AX88178. This controller is fast ethernet
controller, AX88772A.

> 
> and the other gigabit:
> 
> ugen2.4: <vendor 0x050d> at usbus2
> axe2: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 4> on usbus2
> axe2: PHYADDR 0xe0:0x01
> miibus3: <MII bus> on axe2
> truephy1: <ET1011 10/100/1000baseT PHY> PHY 1 on miibus3
> truephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX,
> auto
> ue2: <USB Ethernet> on axe2
> ue2: bpf attached
> ue2: Ethernet address: my mac here
> ue2: link state changed to DOWN
> 
> and never got to see the EEPROM message.
> 

Two odd things here. This controller looks like Belkin F5D5055 and
it is gigabit controller. So it should print the message I
mentioned in previous mail. Are you sure you rebuild/reboot your
kernel?

The second odd thing is now truephy(4) PHY driver is attached to
your controller. Previously it was ukphy(4) generic PHY driver.
This means accessing GMII is not reliable such that reading OUI of
PHY changed its value. Maybe this could the reason why you see lots
of link UP/DOWN messages since mii(4) periodically polls a register
through GMII. If the register value read through GMII constantly
changes it will cause all sorts of problems.
I'm not sure whether this is axe(4) issue or USB stack issue. I
also have Belkin F5D5055 controller and has no such problems so I
guess it could be related with other parts of USB stack.

To easily identify issues for a controller, it would be better to
remove all other axe(4) controllers except one you want to test.