On Fri, November 19, 2010 23:24, Pyun YongHyeon wrote:
> On Fri, Nov 19, 2010 at 11:20:25PM -0200, Nenhum_de_Nos wrote:
>>
>> On Fri, November 19, 2010 22:52, Pyun YongHyeon wrote:
>> > On Fri, Nov 19, 2010 at 08:30:54PM -0200, Nenhum_de_Nos wrote:
>> >>
>> >> On Fri, November 19, 2010 20:07, Nenhum_de_Nos wrote:
>> >> >
>> >> > On Fri, November 19, 2010 20:02, Pyun YongHyeon wrote:
>> >> >> On Fri, Nov 19, 2010 at 07:49:57PM -0200, Nenhum_de_Nos wrote:
>> >> >>>
>> >> >>> 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 ?
>> >> >>>
>> >> >>
>> >> >> Hmm, that depends on your environments. To test USB issues it
>> would
>> >> >> be better to use stable/8.
>> >> >
>> >> > both are 8-stable from the beginning of October. As the faster is
>> >> already
>> >> > compiling things, and it takes 1h max, I'll try this way and can
>> after
>> >> > update to today 8-stable.
>> >> >
>> >> > if anything, just say :)
>> >> >
>> >> > thanks,
>> >> >
>> >> > matheus
>> >> >
>> >> >>> thanks,
>> >> >>>
>> >> >>> matheus
>> >>
>> >> here:
>> >>
>> >> ugen0.2: <vendor 0x0b05> at usbus0
>> >> wlan0: Ethernet address: a mac here
>> >> fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8
>> >> ugen1.3: <vendor 0x050d> at usbus1
>> >> axe0: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on usbus1
>> >> axe0: EEPROM data : 0x0a82, phymode : 02
>> >> axe0: MII without any PHY
>> >> wlan0: link state changed to UP
>> >> wlan0: link state changed to DOWN
>> >> wlan0: link state changed to UP
>> >> ugen1.3: <vendor 0x050d> at usbus1 (disconnected)
>> >> axe0: at uhub1, port 3, addr 3 (disconnected)
>> >> ugen1.3: <vendor 0x050d> at usbus1
>> >> axe0: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on usbus1
>> >> axe0: EEPROM data : 0x0a82, phymode : 02
>> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > Thanks. It's big hint. I uploaded updated if_axe.c
>> > Let me know it makes any difference.
>>
>> need to recompile kernel, or just if_axe ?
>>
>
> If you used if_axe module without "device axe" in kernel
> configuration(i.e. kernel does not include axe(4) driver),
> rebuilding/reloading if_axe should be enough. Otherwise, you have
> to rebuild kernel and reboot.

axe0: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on usbus1
axe0: EEPROM data : 0x0a82, phymode : 02
axe0: attaching PHYs failed
ugen1.3: <vendor 0x050d> at usbus1 (disconnected)
axe0: at uhub1, port 3, addr 3 (disconnected)
ugen1.3: <vendor 0x050d> at usbus1
axe0: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on usbus1
axe0: EEPROM data : 0x0a82, phymode : 02
axe0: attaching PHYs failed
wlan0: link state changed to UP
[math...@darkside /usr/home/matheus]$

tried it twice, tried both adapters. just got this.

thanks,

matheus

>> will do this asap.
>>
>> matheus
>>
>> >> miibus1: <MII bus> on axe0
>> >> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
>> >> ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
>> >> 1000baseT-FDX, auto
>> >> ue0: <USB Ethernet> on axe0
>> >> ue0: Ethernet address: a mac here
>> >> ue0: link state changed to DOWN
>> >>
>> >> both belkin, each one at a time.
>> >>
>> >> will sync world and kernel and make {kernel,world}
>> >>
>> >> thanks,
>


-- 
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
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to