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

[Nenhum_de_Nos]

On Fri, November 19, 2010 19:23, Pyun YongHyeon wrote:
> 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.

yes, I just tried to show that message with other nic.

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

yes, it's this one.

> it is gigabit controller. So it should print the message I
> mentioned in previous mail. Are you sure you rebuild/reboot your
> kernel?

as usual, just rebuilt the axe module ... so I'm going to rebuild now.
this is a slow box, and might take a couple of hours. Will try to do it
also in a notebook running stable to speedup the process.

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

ok, I was also testing that other issue. Will separate things from now on.
no problem using stable from October 7, right ?

thanks,

matheus

-- 
We will call you cygnus,
The God of balance you shall be

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

http://en.wikipedia.org/wiki/Posting_style