Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, November 19, 2010 15:13, Pyun YongHyeon wrote: On Fri, Nov 19, 2010 at 03:19:26AM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 23:38, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 10:40:10PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 13:10, Derrick Brashear wrote: The following reply was made to PR usb/140883; it has been noted by GNATS. From: Derrick Brashear sha...@gmail.com To: bug-follo...@freebsd.org, sub.m...@gmail.com Cc: Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Date: Thu, 18 Nov 2010 09:36:50 -0500 Pyun has provided an updated driver which avoids several issues including using a too-large transmit buffer (the chipset claims only 8k) but none of the fixes worked until he disabled frame combining for transmit. With only a single packet being sent per frame (as was the case in FreeBSD 7, apparently) seems to make the issue go away. None of the cases I could use to reproduce the issue now happen. -- Derrick is this already in 8-stable ? I have a couple of axe(4) based nic's they're not ok on 8-stable. I've talked to Pyun before, and that time seemed do solve the issue (with gigabit belkin axe based) but now I can't get them to work anymore. even fast ethernet linksys axe are just dying when in a bridge (switched to OpenBSD to have it working). how ca I try this to help ? I uploaded updated if_axe.c/if_axereg.h to the following URL. http://people.freebsd.org/~yongari/axe/if_axe.c http://people.freebsd.org/~yongari/axe/if_axereg.h That files seem to fix axe(4) hang which were seen on AX88772A controller. One of most notable changes are removing combining multiple TX frames in TX path such that this change may result in sub-optimal performance for most axe(4) controllers. However it seems that change makes Derrick's controller work without problems. Generally I prefer driver stability over performance so if this change also fixes other axe(4) stability issues reported so far, I want to check in the change. Thanks. well, things did got better here. but the link state UP and DOWN are still there :( ugen2.3: vendor 0x050d at usbus2 axe1: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3 on usbus2 axe1: PHYADDR 0xe0:0x01 miibus2: MII bus on axe1 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, ^ 1000baseT-FD X, auto It seems you have PHY driver issue. Normally all gigabit PHYs should have their own PHY driver since most PHYs hardwares tend to have a special register that reports link state changes. Show me the output of devinfo -rv | grep phy. there you are: devinfo -rv|grep phy ukphy1 pnpinfo oui=0xec6 model=0x1 rev=0x1 at phyno=16 ukphy2 pnpinfo oui=0xa080 model=0x28 rev=0x2 at phyno=1 ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1 Hmm You have many ukphys there. :-) I think the PHY attached to the USB controller is ukphy2. The OUI indicates its maker is ASIX. Unfortunately there is no dedicated PHY driver for this PHY. I guess it may use a modified CICADA PHY though. Updated driver to force GPIO configuration for this PHY. Would you try again after downloading if_axe.c/if_axereg.h? It may show unknown PHY mode : 0xXX if my guess is wrong. back to this, no problem of unknown PHY: ugen2.2: vendor 0x13b1 at usbus2 axe0: vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 2 on usbus2 axe0: PHYADDR 0xe0:0x10 Root mount waiting for: usbus2 miibus1: MII bus on axe0 ukphy1: Generic IEEE 802.3u media interface PHY 16 on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: my mac here ugen2.3: vendor 0x050d at usbus2 axe1: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3 on usbus2 axe1: PHYADDR 0xe0:0x01 Trying to mount root from ufs:/dev/ad0s3a miibus2: MII bus on axe1 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue1: USB Ethernet on axe1 ue1: Ethernet address: my other mac here the ping still shows problems (on gbit controller at 100BaseTX): 62 packets transmitted, 55 packets received, 11.3% packet loss round-trip min/avg/max/stddev
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, November 19, 2010 17:27, Pyun YongHyeon wrote: On Fri, Nov 19, 2010 at 04:23:20PM -0200, Nenhum_de_Nos wrote: On Fri, November 19, 2010 15:13, Pyun YongHyeon wrote: On Fri, Nov 19, 2010 at 03:19:26AM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 23:38, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 10:40:10PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 13:10, Derrick Brashear wrote: The following reply was made to PR usb/140883; it has been noted by GNATS. From: Derrick Brashear sha...@gmail.com To: bug-follo...@freebsd.org, sub.m...@gmail.com Cc: Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Date: Thu, 18 Nov 2010 09:36:50 -0500 Pyun has provided an updated driver which avoids several issues including using a too-large transmit buffer (the chipset claims only 8k) but none of the fixes worked until he disabled frame combining for transmit. With only a single packet being sent per frame (as was the case in FreeBSD 7, apparently) seems to make the issue go away. None of the cases I could use to reproduce the issue now happen. -- Derrick is this already in 8-stable ? I have a couple of axe(4) based nic's they're not ok on 8-stable. I've talked to Pyun before, and that time seemed do solve the issue (with gigabit belkin axe based) but now I can't get them to work anymore. even fast ethernet linksys axe are just dying when in a bridge (switched to OpenBSD to have it working). how ca I try this to help ? I uploaded updated if_axe.c/if_axereg.h to the following URL. http://people.freebsd.org/~yongari/axe/if_axe.c http://people.freebsd.org/~yongari/axe/if_axereg.h That files seem to fix axe(4) hang which were seen on AX88772A controller. One of most notable changes are removing combining multiple TX frames in TX path such that this change may result in sub-optimal performance for most axe(4) controllers. However it seems that change makes Derrick's controller work without problems. Generally I prefer driver stability over performance so if this change also fixes other axe(4) stability issues reported so far, I want to check in the change. Thanks. well, things did got better here. but the link state UP and DOWN are still there :( ugen2.3: vendor 0x050d at usbus2 axe1: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3 on usbus2 axe1: PHYADDR 0xe0:0x01 miibus2: MII bus on axe1 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, ^ 1000baseT-FD X, auto It seems you have PHY driver issue. Normally all gigabit PHYs should have their own PHY driver since most PHYs hardwares tend to have a special register that reports link state changes. Show me the output of devinfo -rv | grep phy. there you are: devinfo -rv|grep phy ukphy1 pnpinfo oui=0xec6 model=0x1 rev=0x1 at phyno=16 ukphy2 pnpinfo oui=0xa080 model=0x28 rev=0x2 at phyno=1 ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1 Hmm You have many ukphys there. :-) I think the PHY attached to the USB controller is ukphy2. The OUI indicates its maker is ASIX. Unfortunately there is no dedicated PHY driver for this PHY. I guess it may use a modified CICADA PHY though. Updated driver to force GPIO configuration for this PHY. Would you try again after downloading if_axe.c/if_axereg.h? It may show unknown PHY mode : 0xXX if my guess is wrong. back to this, no problem of unknown PHY: ugen2.2: vendor 0x13b1 at usbus2 axe0: vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 2 on usbus2 axe0: PHYADDR 0xe0:0x10 Root mount waiting for: usbus2 miibus1: MII bus on axe0 ukphy1: Generic IEEE 802.3u media interface PHY 16 on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: my mac here ugen2.3: vendor 0x050d at usbus2 axe1: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3 on usbus2 axe1: PHYADDR 0xe0:0x01 Trying to mount root from ufs:/dev/ad0s3a miibus2: MII bus on axe1 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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 ___ 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
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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 -- 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
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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
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,
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
___
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
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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 ?
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,
matheus
--
We will call you cygnus,
The God of balance you shall be
A: Because it messes up
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Thu, November 18, 2010 13:10, Derrick Brashear wrote: The following reply was made to PR usb/140883; it has been noted by GNATS. From: Derrick Brashear sha...@gmail.com To: bug-follo...@freebsd.org, sub.m...@gmail.com Cc: Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Date: Thu, 18 Nov 2010 09:36:50 -0500 Pyun has provided an updated driver which avoids several issues including using a too-large transmit buffer (the chipset claims only 8k) but none of the fixes worked until he disabled frame combining for transmit. With only a single packet being sent per frame (as was the case in FreeBSD 7, apparently) seems to make the issue go away. None of the cases I could use to reproduce the issue now happen. -- Derrick is this already in 8-stable ? I have a couple of axe(4) based nic's they're not ok on 8-stable. I've talked to Pyun before, and that time seemed do solve the issue (with gigabit belkin axe based) but now I can't get them to work anymore. even fast ethernet linksys axe are just dying when in a bridge (switched to OpenBSD to have it working). how ca I try this to help ? 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 ___ 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
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 13:10, Derrick Brashear wrote: The following reply was made to PR usb/140883; it has been noted by GNATS. From: Derrick Brashear sha...@gmail.com To: bug-follo...@freebsd.org, sub.m...@gmail.com Cc: Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Date: Thu, 18 Nov 2010 09:36:50 -0500 Pyun has provided an updated driver which avoids several issues including using a too-large transmit buffer (the chipset claims only 8k) but none of the fixes worked until he disabled frame combining for transmit. With only a single packet being sent per frame (as was the case in FreeBSD 7, apparently) seems to make the issue go away. None of the cases I could use to reproduce the issue now happen. -- Derrick is this already in 8-stable ? I have a couple of axe(4) based nic's they're not ok on 8-stable. I've talked to Pyun before, and that time seemed do solve the issue (with gigabit belkin axe based) but now I can't get them to work anymore. even fast ethernet linksys axe are just dying when in a bridge (switched to OpenBSD to have it working). how ca I try this to help ? I uploaded updated if_axe.c/if_axereg.h to the following URL. http://people.freebsd.org/~yongari/axe/if_axe.c http://people.freebsd.org/~yongari/axe/if_axereg.h That files seem to fix axe(4) hang which were seen on AX88772A controller. One of most notable changes are removing combining multiple TX frames in TX path such that this change may result in sub-optimal performance for most axe(4) controllers. However it seems that change makes Derrick's controller work without problems. Generally I prefer driver stability over performance so if this change also fixes other axe(4) stability issues reported so far, I want to check in the change. Thanks. well, things did got better here. but the link state UP and DOWN are still there :( ugen2.3: vendor 0x050d at usbus2 axe1: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3 on usbus2 axe1: PHYADDR 0xe0:0x01 miibus2: MII bus on axe1 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FD X, auto ue1: USB Ethernet on axe1 ue1: Ethernet address: my mac shown here :) ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ugen1.2: Microsoft at usbus1 (disconnected) ukbd0: at uhub1, port 1, addr 2 (disconnected) ums0: at uhub1, port 1, addr 2 (disconnected) uhid0: at uhub1, port 1, addr 2 (disconnected) ue1: link state changed to DOWN ue1: link state changed to UP the good thing is, it usually never got recognized, and was said not to have a PHY (or something alike). so I get this: ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes ping: sendto: No route to host 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.912 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.842 ms ping: sendto: No route to host 64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=1.015 ms 64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=0.774 ms 64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=0.789 ms 64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=0.851 ms 64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=0.915 ms ^C --- 192.168.1.2 ping statistics --- 11 packets transmitted, 7 packets received, 36.4% packet loss round-trip min/avg/max/stddev = 0.774/0.871/1.015/0.077 ms on local network. 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 ___ 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
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 13:10, Derrick Brashear wrote: The following reply was made to PR usb/140883; it has been noted by GNATS. From: Derrick Brashear sha...@gmail.com To: bug-follo...@freebsd.org, sub.m...@gmail.com Cc: Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Date: Thu, 18 Nov 2010 09:36:50 -0500 Pyun has provided an updated driver which avoids several issues including using a too-large transmit buffer (the chipset claims only 8k) but none of the fixes worked until he disabled frame combining for transmit. With only a single packet being sent per frame (as was the case in FreeBSD 7, apparently) seems to make the issue go away. None of the cases I could use to reproduce the issue now happen. -- Derrick is this already in 8-stable ? I have a couple of axe(4) based nic's they're not ok on 8-stable. I've talked to Pyun before, and that time seemed do solve the issue (with gigabit belkin axe based) but now I can't get them to work anymore. even fast ethernet linksys axe are just dying when in a bridge (switched to OpenBSD to have it working). how ca I try this to help ? I uploaded updated if_axe.c/if_axereg.h to the following URL. http://people.freebsd.org/~yongari/axe/if_axe.c http://people.freebsd.org/~yongari/axe/if_axereg.h That files seem to fix axe(4) hang which were seen on AX88772A controller. One of most notable changes are removing combining multiple TX frames in TX path such that this change may result in sub-optimal performance for most axe(4) controllers. However it seems that change makes Derrick's controller work without problems. Generally I prefer driver stability over performance so if this change also fixes other axe(4) stability issues reported so far, I want to check in the change. Thanks. well, things did got better here. but the link state UP and DOWN are still there :( ugen2.3: vendor 0x050d at usbus2 axe1: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3 on usbus2 axe1: PHYADDR 0xe0:0x01 miibus2: MII bus on axe1 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, ^ 1000baseT-FD X, auto It seems you have PHY driver issue. Normally all gigabit PHYs should have their own PHY driver since most PHYs hardwares tend to have a special register that reports link state changes. Show me the output of devinfo -rv | grep phy. there you are: devinfo -rv|grep phy ukphy1 pnpinfo oui=0xec6 model=0x1 rev=0x1 at phyno=16 ukphy2 pnpinfo oui=0xa080 model=0x28 rev=0x2 at phyno=1 ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1 ue1: USB Ethernet on axe1 ue1: Ethernet address: my mac shown here :) ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN ue1: link state changed to UP ugen1.2: Microsoft at usbus1 (disconnected) ukbd0: at uhub1, port 1, addr 2 (disconnected) ums0: at uhub1, port 1, addr 2 (disconnected) uhid0: at uhub1, port 1, addr 2 (disconnected) ue1: link state changed to DOWN ue1: link state changed to UP the good thing is, it usually never got recognized, and was said not to have a PHY (or something alike). Are you using 8.1-RELEASE? If yes, please give it try stable/8 and use axe(4) I posted. sorry, forgot to add: uname -a FreeBSD valfenda.apartnet 8.1-STABLE FreeBSD 8.1-STABLE #2: Fri Nov 5 01:52:06 BRT 2010 r...@valfenda.apartnet:/usr/obj/usr/src/sys/valfenda i386 and this is using that axe(4) you posted :) just got a little deeper, and put two of them (all I have) connected. when in 1000Base-TX FullDuplex, the throughput is horrible., never get more then 3% of the link (on side this FreeBSD Stable shown above
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Thu, November 18, 2010 23:38, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 10:40:10PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: On Thu, November 18, 2010 13:10, Derrick Brashear wrote: The following reply was made to PR usb/140883; it has been noted by GNATS. From: Derrick Brashear sha...@gmail.com To: bug-follo...@freebsd.org, sub.m...@gmail.com Cc: Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Date: Thu, 18 Nov 2010 09:36:50 -0500 Pyun has provided an updated driver which avoids several issues including using a too-large transmit buffer (the chipset claims only 8k) but none of the fixes worked until he disabled frame combining for transmit. With only a single packet being sent per frame (as was the case in FreeBSD 7, apparently) seems to make the issue go away. None of the cases I could use to reproduce the issue now happen. -- Derrick is this already in 8-stable ? I have a couple of axe(4) based nic's they're not ok on 8-stable. I've talked to Pyun before, and that time seemed do solve the issue (with gigabit belkin axe based) but now I can't get them to work anymore. even fast ethernet linksys axe are just dying when in a bridge (switched to OpenBSD to have it working). how ca I try this to help ? I uploaded updated if_axe.c/if_axereg.h to the following URL. http://people.freebsd.org/~yongari/axe/if_axe.c http://people.freebsd.org/~yongari/axe/if_axereg.h That files seem to fix axe(4) hang which were seen on AX88772A controller. One of most notable changes are removing combining multiple TX frames in TX path such that this change may result in sub-optimal performance for most axe(4) controllers. However it seems that change makes Derrick's controller work without problems. Generally I prefer driver stability over performance so if this change also fixes other axe(4) stability issues reported so far, I want to check in the change. Thanks. well, things did got better here. but the link state UP and DOWN are still there :( ugen2.3: vendor 0x050d at usbus2 axe1: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3 on usbus2 axe1: PHYADDR 0xe0:0x01 miibus2: MII bus on axe1 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, ^ 1000baseT-FD X, auto It seems you have PHY driver issue. Normally all gigabit PHYs should have their own PHY driver since most PHYs hardwares tend to have a special register that reports link state changes. Show me the output of devinfo -rv | grep phy. there you are: devinfo -rv|grep phy ukphy1 pnpinfo oui=0xec6 model=0x1 rev=0x1 at phyno=16 ukphy2 pnpinfo oui=0xa080 model=0x28 rev=0x2 at phyno=1 ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1 Hmm You have many ukphys there. :-) I think the PHY attached to the USB controller is ukphy2. The OUI indicates its maker is ASIX. Unfortunately there is no dedicated PHY driver for this PHY. I guess it may use a modified CICADA PHY though. Updated driver to force GPIO configuration for this PHY. Would you try again after downloading if_axe.c/if_axereg.h? It may show unknown PHY mode : 0xXX if my guess is wrong. I downloaded again from above links and are the same as the last: valfenda# md5 if_axe* MD5 (if_axe.c) = 388b7aa84f0d2471f8b144033103618b MD5 (if_axe.c.original) = c528c7cb5eb964a792d4c14dfaed47cf MD5 (if_axe.c.v1) = 388b7aa84f0d2471f8b144033103618b MD5 (if_axereg.h) = 10f85490cab59b8e40de261fd7ad81a5 MD5 (if_axereg.h.original) = 46f37d0f02a3c09463ceec58b743c6ce MD5 (if_axereg.h.v1) = 10f85490cab59b8e40de261fd7ad81a5 .original are files from 8-stable (via csup) .v1 are the files from http://people.freebsd.org/~yongari/axe/ downloaded when the fist test using those files were made. regular .c files were downloaded now when I read this mail. did you uploaded some new version in http://people.freebsd.org/~yongari/axe/ ? or I didn't got it ? :) should this modified version be a good test to fast ethernet axe nics ? my linksys USB200M failed when in bridge after some time of use :( same hardware I'm testing now. and the nics are ok, tested in OpenBSD with same hardware and same bridge and same pf conf file. thanks, matheus ue1: USB Ethernet on axe1 ue1: Ethernet address: my mac shown here :) ue1: link state changed to DOWN ue1: link state changed to UP ue1: link state changed to DOWN
Re: 10Mbps+ throughput usb based ethernet recommendation
On Sun, April 4, 2010 22:12, Pyun YongHyeon wrote: On Sat, Apr 03, 2010 at 09:46:59PM -0300, Nenhum_de_Nos wrote: On Wed, 31 Mar 2010 12:06:31 -0700 Pyun YongHyeon pyu...@gmail.com wrote: On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: [...] I changed and got this: miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 ^^ This is *NOT* bogus value. It's Agere Systems' ET1011 gigabit PHY. FreeBSD has truephy(4) for Agere Systems' PHY but it does not have support code for the model yet. so I can think that's the issue, right ? Probably. But this does not explain sometimes why you get some bogus value form PHY id registers. ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: xx ue0: link state changed to DOWN so it didn't now. other thing is that not every time it works: Yeah, that is real issue here. I guess there should be some magic to wakeup the PHY from deep sleep state. I'll see what can be done. ok, great it was found :) let me know if I can help in anything :) Would you try attached patch and let me know how it goes? axe0: PHYADDR 0xe0:0x01 miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949 Due to other issues previous patch didn't have chance to make it work. This time, PHY id started to reporting garbage again which means all MII register access may return garbage too. Don't know this could be related with USB subsystem though. ukphy0: 10baseT-FDX ue0: USB Ethernet on axe0 ue0: Ethernet address: 00:11:50:e7:39:e9 ue0: link state changed to DOWN [...] and I can't ping the other host :( ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8LINKSTATE ether 00:11:50:e7:39:e9 inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 media: Ethernet none arroway# ifconfig ue0 ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8LINKSTATE ether 00:11:50:e7:39:e9 inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 media: Ethernet none (none hw-loopback) status: active arroway# ifconfig ue0 ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8LINKSTATE ether 00:11:50:e7:39:e9 inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 media: Ethernet none and it is still crazy media changing. Because your PHY is not recognized it's expected result. :-( waiting for any leads :) I bought a linksys axe based fast ethernet to see what happens. waiting till it arrives. thanks as usual, 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 ___ 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
Re: 10Mbps+ throughput usb based ethernet recommendation
On Wed, 31 Mar 2010 12:06:31 -0700 Pyun YongHyeon pyu...@gmail.com wrote: On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: [...] I changed and got this: miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 ^^ This is *NOT* bogus value. It's Agere Systems' ET1011 gigabit PHY. FreeBSD has truephy(4) for Agere Systems' PHY but it does not have support code for the model yet. so I can think that's the issue, right ? Probably. But this does not explain sometimes why you get some bogus value form PHY id registers. ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: xx ue0: link state changed to DOWN so it didn't now. other thing is that not every time it works: Yeah, that is real issue here. I guess there should be some magic to wakeup the PHY from deep sleep state. I'll see what can be done. ok, great it was found :) let me know if I can help in anything :) Would you try attached patch and let me know how it goes? axe0: PHYADDR 0xe0:0x01 miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949 ukphy0: 10baseT-FDX ue0: USB Ethernet on axe0 ue0: Ethernet address: 00:11:50:e7:39:e9 ue0: link state changed to DOWN ue0: link state changed to DOWN ue0: link state changed to DOWN ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link
Re: 10Mbps+ throughput usb based ethernet recommendation
On Fri, March 26, 2010 16:50, Pyun YongHyeon wrote: On Thu, Mar 25, 2010 at 09:57:22PM -0300, Nenhum_de_Nos wrote: [...] miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949 This value looks garbage. :( ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX, 1000baseT, 1000baseT-FDX, auto And this time, ukphy(4) also thinks your PHY supports 1000baseSX. Of course it's wrong because PHY is copper type. By chance, are you using Belkin F5D5055 USB controller? I remember another user also reported similar issue. yes. I have two of them. Ok, would you try attached patch and check whether the patch prints some error messages on your console? I guess some commands are timed out here. ugen1.3: vendor 0x050d at usbus1 axe0: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3 on usbus1 axe0: PHYADDR 0xe0:0x01 miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: xx.xx.xx.xx.xx.xx ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP vboxnet0: Ethernet address: 0a:00:27:00:00:00 nfe0: promiscuous mode enabled wlan0: link state changed to DOWN wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP nfe0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP nfe0: link state changed to DOWN ue0: link state changed to DOWN nfe0: link state changed to UP ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP nfe0: tx v2 error 0x6100 arp: xx:xx:xx:xx:xx:xx:xx is using my IP address 10.1.1.1 on ue0! wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP so far, just this after plugging the usb nic. tested iperf and the behavior was the same, but nothing in logs. just noticed this: ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 this is not the same as the other mail. I think is the same adapter (as I have two), but this should change with the nic change ? I changed and got this: miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: xx ue0: link state changed to DOWN so it didn't now. other thing is that not every time it works: ugen1.3: vendor 0x050d at usbus1 axe0: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3 on usbus1 axe0: PHYADDR 0xe0:0x01 axe0: MII without any PHY 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: PHYADDR 0xe0:0x01 axe0: MII without any PHY ugen1.3: vendor 0x050d at usbus1 (disconnected) axe0: at uhub1, port 3, addr 3 (disconnected) and in the third time it found the PHY it was looking for above and got what I said above. hope it helps, thanks, matheus thanks, matheus Hans, I guess there is not much thing left to do in PHY driver because accessing these MII registers return garbage. What could be done in USB subsystem to get more information to know why controller returns garbage for accessing MII registers? -- 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
Re: 10Mbps+ throughput usb based ethernet recommendation
On Fri, March 26, 2010 23:19, Pyun YongHyeon wrote: On Fri, Mar 26, 2010 at 11:03:50PM -0300, Nenhum_de_Nos wrote: On Fri, March 26, 2010 16:50, Pyun YongHyeon wrote: On Thu, Mar 25, 2010 at 09:57:22PM -0300, Nenhum_de_Nos wrote: [...] miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949 This value looks garbage. :( ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX, 1000baseT, 1000baseT-FDX, auto And this time, ukphy(4) also thinks your PHY supports 1000baseSX. Of course it's wrong because PHY is copper type. By chance, are you using Belkin F5D5055 USB controller? I remember another user also reported similar issue. yes. I have two of them. Ok, would you try attached patch and check whether the patch prints some error messages on your console? I guess some commands are timed out here. ugen1.3: vendor 0x050d at usbus1 axe0: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3 on usbus1 axe0: PHYADDR 0xe0:0x01 miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: xx.xx.xx.xx.xx.xx ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP vboxnet0: Ethernet address: 0a:00:27:00:00:00 nfe0: promiscuous mode enabled wlan0: link state changed to DOWN wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP nfe0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP nfe0: link state changed to DOWN ue0: link state changed to DOWN nfe0: link state changed to UP ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP nfe0: tx v2 error 0x6100 It seems you have nfe(4) Tx issues here. You may want to check negotiated speed/duplex is correct against switch. If you have manual media configuration instead of auto, nuke that configuration. nfe(4) has a long standing issue when manual media configuration is used. I'm linking my nfe0 from notebook, bridged in a vbox freebsd machine, and the usb nic. the media is auto (not manually changed since boot) on both ue0 (native freebsd), nfe0 native and em0 (guest freebsd). arp: xx:xx:xx:xx:xx:xx:xx is using my IP address 10.1.1.1 on ue0! wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP so far, just this after plugging the usb nic. tested iperf and the behavior was the same, but nothing in logs. just noticed this: ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 this is not the same as the other mail. I think is the same adapter (as I have two), but this should change with the nic change ? I changed and got this: miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 ^^ This is *NOT* bogus value. It's Agere Systems' ET1011 gigabit PHY. FreeBSD has truephy(4) for Agere Systems' PHY but it does not have support code for the model yet. so I can think that's the issue, right ? ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: xx ue0: link state changed to DOWN so it didn't now. other thing is that not every time it works: Yeah, that is real issue here. I guess there should be some magic to wakeup the PHY from deep sleep state. I'll see what can be done. ok, great it was found :) let me know if I can help in anything :) 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 ___ freebsd-usb@freebsd.org mailing
Re: 10Mbps+ throughput usb based ethernet recommendation
On Thu, March 25, 2010 14:35, Pyun YongHyeon wrote: On Thu, Mar 25, 2010 at 02:22:32PM -0300, Nenhum_de_Nos wrote: On Wed, March 24, 2010 20:18, Pyun YongHyeon wrote: On Wed, Mar 24, 2010 at 02:58:27PM -0700, Pyun YongHyeon wrote: On Wed, Mar 24, 2010 at 02:42:30PM -0700, Pyun YongHyeon wrote: On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote: On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote: [...] Just adding info, I keep getting these outputs from ifconfig: ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT full-duplex) status: active and: ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX full-duplex,hw-loopback) status: active and this keeps repeating over and over. iperf and on the other end an Maybe this is real problem. It seems PHY have trouble to establish link. This is FreeBSD stable/8 right? yes. on 7.2 is even worse :( Would you show me the output of devinfo -rv| grep phy? /usr/home/matheus]$ devinfo -rv| grep phy ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at phyno=1 axe(4) requires correct resolved speed/link status reported from PHY driver. Otherwise it will incorrectly reprogram some registers and this can result in unexpected result. The OUI 0x1e from the above looks odd and I'm not aware of any PHY vendors that reports such OUI. Because FreeBSD does not strictly follows OUI decoding defined by IEEE it's also possible that FreeBSD incorrectly showed wrong OUI. What is your USB ethernet controller model? Please try this patch and let me know the output on your console. It will show you XXX ID1 = 0x, ID2 = 0x. Use this patch instead of previous one. I applied the patch, and recompiled just the module. no good, then mii module also recompiled. this time I can ping from inside the freebsd-current vm (vbox) using bridged networking (notebook ethernet nfe adapter) connected to this axe device (this on 8-stable native). ping runs, but yet looses packets: The patch just prints some register information which could be used to track down PHY issues. So it's expected one as the patch has no functional changes. 64 bytes from 192.168.1.1: icmp_seq=125 ttl=64 time=0.507 ms load: 0.54 cmd: ping 15245 [select] 125.96r 0.01u 0.00s 0% 1372k 95/126 packets received (75.4%) 0.450 min / 1.359 avg / 51.108 max 64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=0.499 ms but I see no messages on console/dmesg/messages file: Mar 25 14:04:40 darkside kernel: ue0: link state changed to DOWN Mar 25 14:04:40 darkside kernel: ue0: link state changed to UP Mar 25 14:06:17 darkside kernel: ue0: promiscuous mode enabled Mar 25 14:06:35 darkside kernel: ue0: promiscuous mode disabled Mar 25 14:15:59 darkside kernel: ugen1.4: vendor 0x050d at usbus1 (disconnected) Mar 25 14:15:59 darkside kernel: axe0: at uhub1, port 3, addr 4 (disconnected) Mar 25 14:15:59 darkside kernel: ukphy0: detached Mar 25 14:15:59 darkside kernel: miibus1: detached Mar 25 14:16:00 darkside kernel: nfe0: link state changed to DOWN Mar 25 14:16:19 darkside kernel: ugen1.4: vendor 0x050d at usbus1 Mar 25 14:16:19 darkside kernel: axe0: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 4 on usbus1 Mar 25 14:16:19 darkside kernel: axe0: PHYADDR 0xe0:0x01 Mar 25 14:16:20 darkside kernel: miibus1: MII bus on axe0 Mar 25 14:16:20 darkside kernel: ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 Mar 25 14:16:20 darkside kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Mar 25 14:16:20 darkside kernel: ue0: USB Ethernet on axe0 Mar 25 14:16:20 darkside kernel: ue0: Ethernet address: 00:11:50:e7:39:e9 Mar 25 14:16:21 darkside kernel: ue0: link state changed to DOWN Mar 25 14:16:23 darkside kernel: nfe0: link state changed to UP Mar 25 14:17:06 darkside kernel: ue0: link state changed to UP do I need to recompile kernel ? (I will as soon as I get home anyway) Yes, mii(4) should be recompiled to get the register information. Let me know ukphy(4) output after rebuilding kernel. there you are: miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX, 1000baseT, 1000baseT-FDX, auto ue0: USB Ethernet on axe0 ue0: Ethernet address: xx:xx:xx:xx:xx:xx let me know if you need anything
Re: 10Mbps+ throughput usb based ethernet recommendation
On Thu, March 25, 2010 21:31, Pyun YongHyeon wrote: On Thu, Mar 25, 2010 at 04:42:19PM -0300, Nenhum_de_Nos wrote: On Thu, March 25, 2010 14:35, Pyun YongHyeon wrote: On Thu, Mar 25, 2010 at 02:22:32PM -0300, Nenhum_de_Nos wrote: On Wed, March 24, 2010 20:18, Pyun YongHyeon wrote: On Wed, Mar 24, 2010 at 02:58:27PM -0700, Pyun YongHyeon wrote: On Wed, Mar 24, 2010 at 02:42:30PM -0700, Pyun YongHyeon wrote: On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote: On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote: [...] Just adding info, I keep getting these outputs from ifconfig: ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT full-duplex) status: active and: ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX full-duplex,hw-loopback) status: active and this keeps repeating over and over. iperf and on the other end an Maybe this is real problem. It seems PHY have trouble to establish link. This is FreeBSD stable/8 right? yes. on 7.2 is even worse :( Would you show me the output of devinfo -rv| grep phy? /usr/home/matheus]$ devinfo -rv| grep phy ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at phyno=1 axe(4) requires correct resolved speed/link status reported from PHY driver. Otherwise it will incorrectly reprogram some registers and this can result in unexpected result. The OUI 0x1e from the above looks odd and I'm not aware of any PHY vendors that reports such OUI. Because FreeBSD does not strictly follows OUI decoding defined by IEEE it's also possible that FreeBSD incorrectly showed wrong OUI. What is your USB ethernet controller model? Please try this patch and let me know the output on your console. It will show you XXX ID1 = 0x, ID2 = 0x. Use this patch instead of previous one. I applied the patch, and recompiled just the module. no good, then mii module also recompiled. this time I can ping from inside the freebsd-current vm (vbox) using bridged networking (notebook ethernet nfe adapter) connected to this axe device (this on 8-stable native). ping runs, but yet looses packets: The patch just prints some register information which could be used to track down PHY issues. So it's expected one as the patch has no functional changes. 64 bytes from 192.168.1.1: icmp_seq=125 ttl=64 time=0.507 ms load: 0.54 cmd: ping 15245 [select] 125.96r 0.01u 0.00s 0% 1372k 95/126 packets received (75.4%) 0.450 min / 1.359 avg / 51.108 max 64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=0.499 ms but I see no messages on console/dmesg/messages file: Mar 25 14:04:40 darkside kernel: ue0: link state changed to DOWN Mar 25 14:04:40 darkside kernel: ue0: link state changed to UP Mar 25 14:06:17 darkside kernel: ue0: promiscuous mode enabled Mar 25 14:06:35 darkside kernel: ue0: promiscuous mode disabled Mar 25 14:15:59 darkside kernel: ugen1.4: vendor 0x050d at usbus1 (disconnected) Mar 25 14:15:59 darkside kernel: axe0: at uhub1, port 3, addr 4 (disconnected) Mar 25 14:15:59 darkside kernel: ukphy0: detached Mar 25 14:15:59 darkside kernel: miibus1: detached Mar 25 14:16:00 darkside kernel: nfe0: link state changed to DOWN Mar 25 14:16:19 darkside kernel: ugen1.4: vendor 0x050d at usbus1 Mar 25 14:16:19 darkside kernel: axe0: vendor 0x050d product 0x5055, rev 2.00/0.01, addr 4 on usbus1 Mar 25 14:16:19 darkside kernel: axe0: PHYADDR 0xe0:0x01 Mar 25 14:16:20 darkside kernel: miibus1: MII bus on axe0 Mar 25 14:16:20 darkside kernel: ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 Mar 25 14:16:20 darkside kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Mar 25 14:16:20 darkside kernel: ue0: USB Ethernet on axe0 Mar 25 14:16:20 darkside kernel: ue0: Ethernet address: 00:11:50:e7:39:e9 Mar 25 14:16:21 darkside kernel: ue0: link state changed to DOWN Mar 25 14:16:23 darkside kernel: nfe0: link state changed to UP Mar 25 14:17:06 darkside kernel: ue0: link state changed to UP do I need to recompile kernel ? (I will as soon as I get home anyway) Yes, mii(4) should be recompiled to get the register information. Let me know ukphy(4) output after rebuilding kernel. there you are: miibus1: MII bus on axe0 ukphy0
Re: 10Mbps+ throughput usb based ethernet recommendation
On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote: On Tue, Mar 23, 2010 at 12:13:26AM -0300, Nenhum_de_Nos wrote: On Mon, March 22, 2010 23:29, Nenhum_de_Nos wrote: On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: hail, I need an usb nic that is able to push more then 10Mbps on wire. if is altq capable better. AFAIK all USB ethernet drivers support altq(4). I use pfsense as router, but my next upgrade will use 10Mbps link and my aue and rue nic's can't pass the 5Mbps barrier. I need to use three to make 11Mbps on it, and its not a good thing for me in production. I've seen some axe based on its manual page, but I'm afraid to buy and it won't solve my problem. if anyone has any leads/experience on this please broadcast :) Last time I tried AX88178 based axe(4) controller, I can push more than 200Mbps. Related change already MFCed to stable/8. well, I did that but using that chip on windows :( I got two nics based on these chips but they are unstable as hell in FreeBSD. on pfSense (FreeBSD 7.1 and 7.2 versions) I never got the axe0 media to be active. on 8-stable (this box), one got issues with media link and the other can set link state ok, but looses 10% of ping packets. iperf gets cut every now and then and this makes the throughput suffer :( I plan to use pfSense 1.2.3 (7.2 based) and when available pfSense 2.0 (8.0 based). are there any patches to try ? it is really unstable here ... some logs: Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 42556 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-32.7 sec 69.5 MBytes 17.8 Mbits/sec [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 45725 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-30.6 sec128 MBytes 35.1 Mbits/sec [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 38546 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-31.0 sec129 MBytes 35.0 Mbits/sec this is: FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Mar 21 03:45:47 BRT 2010 r...@xxx:/usr/obj/usr/src/sys/xxx amd64 and on both ends there is a nic using this chip, here is this freebsd and the other on windows xp. as said above, when run iperf on this nic on windows and my nfe gigabit I got those 228Mbps said above. 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 -- 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 Just adding info, I keep getting these outputs from ifconfig: ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT full-duplex) status: active and: ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX full-duplex,hw-loopback) status: active and this keeps repeating over and over. iperf and on the other end an Maybe this is real problem. It seems PHY have trouble to establish link. This is FreeBSD stable/8 right? yes. on 7.2 is even worse :( Would you show me the output of devinfo -rv| grep phy? /usr/home/matheus]$ devinfo -rv| grep phy ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at phyno=1 I'm trying to test it on current, but I think it will be the same (I saw cvs commits till releng 8 creating and all
Re: 10Mbps+ throughput usb based ethernet recommendation
On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: hail, I need an usb nic that is able to push more then 10Mbps on wire. if is altq capable better. AFAIK all USB ethernet drivers support altq(4). I use pfsense as router, but my next upgrade will use 10Mbps link and my aue and rue nic's can't pass the 5Mbps barrier. I need to use three to make 11Mbps on it, and its not a good thing for me in production. I've seen some axe based on its manual page, but I'm afraid to buy and it won't solve my problem. if anyone has any leads/experience on this please broadcast :) Last time I tried AX88178 based axe(4) controller, I can push more than 200Mbps. Related change already MFCed to stable/8. well, I did that but using that chip on windows :( I got two nics based on these chips but they are unstable as hell in FreeBSD. on pfSense (FreeBSD 7.1 and 7.2 versions) I never got the axe0 media to be active. on 8-stable (this box), one got issues with media link and the other can set link state ok, but looses 10% of ping packets. iperf gets cut every now and then and this makes the throughput suffer :( I plan to use pfSense 1.2.3 (7.2 based) and when available pfSense 2.0 (8.0 based). are there any patches to try ? it is really unstable here ... some logs: Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 42556 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-32.7 sec 69.5 MBytes 17.8 Mbits/sec [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 45725 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-30.6 sec128 MBytes 35.1 Mbits/sec [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 38546 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-31.0 sec129 MBytes 35.0 Mbits/sec this is: FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Mar 21 03:45:47 BRT 2010 r...@xxx:/usr/obj/usr/src/sys/xxx amd64 and on both ends there is a nic using this chip, here is this freebsd and the other on windows xp. as said above, when run iperf on this nic on windows and my nfe gigabit I got those 228Mbps said above. 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 -- 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
Re: 10Mbps+ throughput usb based ethernet recommendation
On Mon, March 22, 2010 23:29, Nenhum_de_Nos wrote: On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: hail, I need an usb nic that is able to push more then 10Mbps on wire. if is altq capable better. AFAIK all USB ethernet drivers support altq(4). I use pfsense as router, but my next upgrade will use 10Mbps link and my aue and rue nic's can't pass the 5Mbps barrier. I need to use three to make 11Mbps on it, and its not a good thing for me in production. I've seen some axe based on its manual page, but I'm afraid to buy and it won't solve my problem. if anyone has any leads/experience on this please broadcast :) Last time I tried AX88178 based axe(4) controller, I can push more than 200Mbps. Related change already MFCed to stable/8. well, I did that but using that chip on windows :( I got two nics based on these chips but they are unstable as hell in FreeBSD. on pfSense (FreeBSD 7.1 and 7.2 versions) I never got the axe0 media to be active. on 8-stable (this box), one got issues with media link and the other can set link state ok, but looses 10% of ping packets. iperf gets cut every now and then and this makes the throughput suffer :( I plan to use pfSense 1.2.3 (7.2 based) and when available pfSense 2.0 (8.0 based). are there any patches to try ? it is really unstable here ... some logs: Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 42556 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-32.7 sec 69.5 MBytes 17.8 Mbits/sec [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 45725 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-30.6 sec128 MBytes 35.1 Mbits/sec [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 38546 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-31.0 sec129 MBytes 35.0 Mbits/sec this is: FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Mar 21 03:45:47 BRT 2010 r...@xxx:/usr/obj/usr/src/sys/xxx amd64 and on both ends there is a nic using this chip, here is this freebsd and the other on windows xp. as said above, when run iperf on this nic on windows and my nfe gigabit I got those 228Mbps said above. 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 -- 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 Just adding info, I keep getting these outputs from ifconfig: ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT full-duplex) status: active and: ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX full-duplex,hw-loopback) status: active and this keeps repeating over and over. iperf and on the other end an intel gigabit pcie nic: [r...@xxx ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 52180 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-50.9 sec392 MBytes 64.6 Mbits/sec [r...@xxx ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 62772
10Mbps+ throughput usb based ethernet recommendation
hail, I need an usb nic that is able to push more then 10Mbps on wire. if is altq capable better. I use pfsense as router, but my next upgrade will use 10Mbps link and my aue and rue nic's can't pass the 5Mbps barrier. I need to use three to make 11Mbps on it, and its not a good thing for me in production. I've seen some axe based on its manual page, but I'm afraid to buy and it won't solve my problem. if anyone has any leads/experience on this please broadcast :) 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 ___ 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
Re: 10Mbps+ throughput usb based ethernet recommendation
On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: hail, I need an usb nic that is able to push more then 10Mbps on wire. if is altq capable better. AFAIK all USB ethernet drivers support altq(4). first of all, thanks for the reply. but unfortunatelly I think I found one that is not, rue. at least ont the version pfsense 1.2.3 is based ... I use pfsense as router, but my next upgrade will use 10Mbps link and my aue and rue nic's can't pass the 5Mbps barrier. I need to use three to make 11Mbps on it, and its not a good thing for me in production. I've seen some axe based on its manual page, but I'm afraid to buy and it won't solve my problem. if anyone has any leads/experience on this please broadcast :) Last time I tried AX88178 based axe(4) controller, I can push more than 200Mbps. Related change already MFCed to stable/8. that's kind of a problem for me, as pfsense uses 7 yet (is about to change) I'm not sure which FreeBSD version pfsense is based on though. 7.2+ (7.2, or a bit more new from stable). but thanks for the info ! aiming at this controller :) 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 ___ 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
Re: 10Mbps+ throughput usb based ethernet recommendation
On Mon, March 1, 2010 16:33, Pyun YongHyeon wrote: On Mon, Mar 01, 2010 at 04:22:47PM -0300, Nenhum_de_Nos wrote: On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: hail, I need an usb nic that is able to push more then 10Mbps on wire. if is altq capable better. AFAIK all USB ethernet drivers support altq(4). first of all, thanks for the reply. but unfortunatelly I think I found one that is not, rue. at least ont the version pfsense 1.2.3 is based ... Hmm, you're right. I've checked stable/7 and rue(4) lacks altq(4) support code. If you switch to stable/8 you can get altq(4) capability as well as better performance. the change in 8 is really great. as my aue won't work at all (attachs, but can't send bytes). I would like to hear from people that used Linksys USB200M, as 100Mbps is enough for me and the hardware is way cheaper. it is based on the (I think older) AX88172 ... if anyone could share :) 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 ___ 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
Re: bug fix for aue driver
On Thu, July 30, 2009 01:11, john hood wrote: I have a D-Link DSB-650 USB ethernet adapter, which uses an ADMtek AN986 USB MAC, a Broadcom BCM5201 PHY device, and the aue driver. Recent versions of FreeBSD (7.1, 7.2, 8 beta 2) all get stuck on aue0: MII read timed out errors after you try and bring the interface up. (The system continues to run, but you get long waits performing ioctls on the device, and no actual packets.) I think I've found the problem; the device is getting mis-initialized, and has been ever since the early days of the driver. The old code mis-sets a power-down configuration line on the PHY just as it's resetting it. I think I have a fix; it 1) does the right thing for ADMtek's reference design, 2) matches (better) what the Linux driver does (successfully, for me), 3) matches the actual circuit of the DSB-650, 4) makes sense when you read it. I suspect it will improve the situation for most users of Pegasus-based Ethernet adapters, and probably resolve most of the weird media- and PHY-related issues the driver's had for its entire life. Would people try the attached patch? (If anyone cares much about an obsolete Ethernet adapter-- I used this mostly as an excuse to wade into the USB stack and understand it a little better...) If you get debugging spew, please forward it to me. If it just works (or not), tell me that too. The patch is against 8.0-beta2. It won't apply to the old, pre-USB2 driver in sys/dev/usb/if_aue.c, but the significant change is the reset code in the last hunk of the patch; trying that on whatever version of FreeBSD you're using is worthwhile. Thanks, --jh I had problems using some aue in anything prior to 8-current. when I used usb from hps, all worked fine. I filed a PR for 7-stable in that time. my aue on 7.x didn't work at all. 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 ___ 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
Re: u3g panic
On Wed, April 1, 2009 06:50, Nick Hibma wrote: Mike, and others, We are working on this panic at the moment and there will be a driver out for inclusion in 7.2 (hopefully). It seems to (almost) make ZTE MF626 work as well (mode switch does not work reliably yet). According to Mike Tancsa this driver also makes his Novatel device work without having to manually switch the device. I'd appreciate it if poeple could gives this driver a try to see whether it works for them too. http://people.freebsd.org/~n_hibma/u3g.html I am using it as we speak to submit this message and upload the driver sources, change the HTML text on that page. Cheers, Nick nick, I had problems with u3g and umass. In old ubsa days, I could load it and then umass and use pendrive Ok. Now on current, if I do this I get a frozen box. I talked to HPS and he asked for some debugs but I didn't provided nothing to him (my fault, I know), but as this box has no witness anymore (and other debug stuff), all I have os the vmcore. is this expected ? vmcore would help ? this is the box from work, so I can't play with it too much. thanks, (both nick and hps for support when I asked) matheus -- We will call you cygnus, The God of balance you shall be ___ 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
ADMtek USB To LAN Converter
hail, I have two of these and cant make them ping. module loads ok, ifconfig sees ok, but cant send any data. tcpdump can get info though. aue0: ADMtek USB To LAN Converter, class 255/0, rev 1.10/2.01, addr 2 on uhub1 miibus3: MII bus on aue0 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus3 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto aue0: Ethernet address: 00:60:6e:00:05:d2 aue0: link state changed to DOWN aue0: link state changed to UP aue0: usb error on rx: IOERROR FreeBSD xxx 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #2: Tue Dec 30 00:41:39 BRT 2008 r...@xxx:/usr/obj/usr/src/sys/xxx i386 if anyone has any clues, thanks, matheus -- We will call you cygnus, The God of balance you shall be -- We will call you cygnus, The God of balance you shall be ___ 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
RE: ADMtek USB To LAN Converter
hail, first of all I apologize for two messages, but I'm not receiving usb@ msgs. but to the point, this adapter: aue0: ADMtek USB To LAN Converter, class 255/0, rev 1.10/2.01, addr 2 on uhub1 miibus3: MII bus on aue0 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus3 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto aue0: Ethernet address: 00:60:6e:00:05:d2 aue0: link state changed to DOWN aue0: link state changed to UP aue0: usb error on rx: IOERROR in current using usb1 never got to send a byte on the wire. So I tested USB2: ugen0.2: ADMtek at usbus0 aue0: ADMtek USB To LAN Converter, rev 1.10/2.01, addr 2 on usbus0 miibus1: MII bus on aue0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: USB Ethernet on aue0 ue0: Ethernet address: 00:60:6e:00:05:d2 ue0: link state changed to DOWN and after a ifconfig ue0 $ip, it did work :) as I have no clue why this, I'm here asking. I'd like to have this nic in a router and planned to run STABLE or any RELEASE, nor CURRENT. so is this possible ? and at last but not least, thanks for usb2 code :) matheus -- We will call you cygnus, The God of balance you shall be ___ 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
Re: ADMtek USB To LAN Converter
On Tue, February 10, 2009 13:01, Hans Petter Selasky wrote: On Tuesday 10 February 2009, Nenhum_de_Nos wrote: first of all I apologize for two messages, but I'm not receiving usb@ msgs. but to the point, this adapter: Hi, aue0: usb error on rx: IOERROR Probably the old USB aue0 driver does not handle the clear-stall correctly. this error appeared just once, but I tried for quite long time (some hours yesterday), and using 7.1R/STABLE/CURRENT So is this possible ? It will require some work. What is the target version of FreeBSD where you want to backport the aue0 driver? well, STABLE would be much of enough :) as it'll be in future releases :) and at last but not least, thanks for usb2 code :) Great to hear it's working! yep, and is ok. just noticed u3g stopped working :) I was about to send nick a message about this, or is all about you ? ;) thanks again, matheus --HPS -- We will call you cygnus, The God of balance you shall be ___ 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
Re: ADMtek USB To LAN Converter
On Tue, February 10, 2009 17:08, Hans Petter Selasky wrote: On Tuesday 10 February 2009, Nenhum_de_Nos wrote: On Tue, February 10, 2009 13:01, Hans Petter Selasky wrote: On Tuesday 10 February 2009, Nenhum_de_Nos wrote: first of all I apologize for two messages, but I'm not receiving usb@ msgs. but to the point, this adapter: Hi, aue0: usb error on rx: IOERROR Probably the old USB aue0 driver does not handle the clear-stall correctly. this error appeared just once, but I tried for quite long time (some hours yesterday), and using 7.1R/STABLE/CURRENT So is this possible ? It will require some work. What is the target version of FreeBSD where you want to backport the aue0 driver? well, STABLE would be much of enough :) as it'll be in future releases :) and at last but not least, thanks for usb2 code :) Great to hear it's working! yep, and is ok. just noticed u3g stopped working :) I was about to send nick a message about this, or is all about you ? ;) Hi, If you have some debug prints you can send them to me or Andrew Thompson. There has been some changes to u3g recently. Maybe something is broken? kldload usb2_serial_3g And dmesg output. --HPS well, sorry for my mistake. I did kldluad u3g and it loaded, but my Huawei E226 got ugen for it. I'll try this though. thanks, matheus -- We will call you cygnus, The God of balance you shall be ___ 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
ADMtek USB To LAN Converter
hail, I have two of these and cant make them ping. module loads ok, ifconfig sees ok, but cant send any data. tcpdump can get info though. aue0: ADMtek USB To LAN Converter, class 255/0, rev 1.10/2.01, addr 2 on uhub1 miibus3: MII bus on aue0 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus3 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto aue0: Ethernet address: 00:60:6e:00:05:d2 aue0: link state changed to DOWN aue0: link state changed to UP aue0: usb error on rx: IOERROR FreeBSD xxx 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #2: Tue Dec 30 00:41:39 BRT 2008 r...@xxx:/usr/obj/usr/src/sys/xxx i386 if anyone has any clues, thanks, matheus -- We will call you cygnus, The God of balance you shall be ___ 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
