Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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: on > >> >>> usbus2 > >> >>> >> axe1: PHYADDR 0xe0:0x10 > >> >>> >> miibus2: on axe1 > >> >>> >> ukphy1: PHY 16 on miibus2 > >> >>> >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 > >> >>> >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >> >>> >> ue1: 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: at usbus2 > >> >>> >> axe2: on > >> >>> usbus2 > >> >>> >> axe2: PHYADDR 0xe0:0x01 > >> >>> >> miibus3: on axe2 > >> >>> >> truephy1: PHY 1 on miibus3 > >> >>> >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > >> >>> >> 1000baseT-FDX, > >> >>> >> auto > >> >>> >> ue2: 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 p
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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: on > >>> usbus2 > >>> >> axe1: PHYADDR 0xe0:0x10 > >>> >> miibus2: on axe1 > >>> >> ukphy1: PHY 16 on miibus2 > >>> >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 > >>> >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >>> >> ue1: 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: at usbus2 > >>> >> axe2: on > >>> usbus2 > >>> >> axe2: PHYADDR 0xe0:0x01 > >>> >> miibus3: on axe2 > >>> >> truephy1: PHY 1 on miibus3 > >>> >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > >>> >> 1000baseT-FDX, > >>> >> auto > >>> >> ue2: 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 > &g
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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: on usbus2 > >> axe1: PHYADDR 0xe0:0x10 > >> miibus2: on axe1 > >> ukphy1: PHY 16 on miibus2 > >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 > >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >> ue1: 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: at usbus2 > >> axe2: on usbus2 > >> axe2: PHYADDR 0xe0:0x01 > >> miibus3: on axe2 > >> truephy1: PHY 1 on miibus3 > >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > >> 1000baseT-FDX, > >> auto > >> ue2: 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. > thanks, > > matheus ___ 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, 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: on usbus2 > axe1: PHYADDR 0xe0:0x10 > miibus2: on axe1 > ukphy1: PHY 16 on miibus2 > ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 > ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue1: on axe1 > ue1: bpf attached > invalid media SR 0x700 > invalid media SR 0x700 > This is normal, the message I said will show up when you use gigabit controller, AX88178. This controller is fast ethernet controller, AX88772A. > > and the other gigabit: > > ugen2.4: at usbus2 > axe2: on usbus2 > axe2: PHYADDR 0xe0:0x01 > miibus3: on axe2 > truephy1: PHY 1 on miibus3 > truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, > auto > ue2: on axe2 > ue2: bpf attached > ue2: Ethernet address: my mac here > ue2: link state changed to DOWN > > and never got to see the EEPROM message. > Two odd things here. This controller looks like Belkin F5D5055 and it is gigabit controller. So it should print the message I mentioned in previous mail. Are you sure you rebuild/reboot your kernel? The second odd thing is now truephy(4) PHY driver is attached to your controller. Previously it was ukphy(4) generic PHY driver. This means accessing GMII is not reliable such that reading OUI of PHY changed its value. Maybe this could the reason why you see lots of link UP/DOWN messages since mii(4) periodically polls a register through GMII. If the register value read through GMII constantly changes it will cause all sorts of problems. I'm not sure whether this is axe(4) issue or USB stack issue. I also have Belkin F5D5055 controller and has no such problems so I guess it could be related with other parts of USB stack. To easily identify issues for a controller, it would be better to remove all other axe(4) controllers except one you want to test. ___ 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, 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 > >> >> >> >> > 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. > >> >> >> &g
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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 > >> >> >> > 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: at usbus2 > >> >> axe1: on usbus2 > >> >> axe1: PHYADDR 0xe0:0x01 > >> >> miibus2: on axe1 > >> >> ukphy2: 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
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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 > >> >> > 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: at usbus2 > >> axe1: on usbus2 > >> axe1: PHYADDR 0xe0:0x01 > >> miibus2: on axe1 > >> ukphy2: 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. > > >&
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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 > >> > 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: at usbus2 > axe1: on usbus2 > axe1: PHYADDR 0xe0:0x01 > miibus2: on axe1 > ukphy2: 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". > ue1: 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: 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
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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 > > 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. ___ 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: Network TX/RX fairness is not honored by USB stack
On Sun, Oct 03, 2010 at 04:54:23PM -0700, Pyun YongHyeon wrote: > On Sat, Oct 02, 2010 at 08:41:57AM +0200, Hans Petter Selasky wrote: [...] > > > USB EHCI uses round robin, so this is either USB device problem or a test- > > program software failure. > > > > I'm pretty sure the benchmark program is not broken, so either > axe(4) or USB stack could be wrong here. I see three issues from > the UDP torture test. > - Either TX or RX could be starved to death. If you start TX test >first, RX would be stuck. If you start RX test first, TX would >be stuck. I had some progress for narrowing down the issue. It seems the issue happens on some revision of axe(4) controller so I guess the issue is in axe(4), not USB stack. I spent a lot of time to reproduce it on several axe(4) variants and only one axe(4) showed TX stuck condition under certain conditions. I don't believe the controller is in broken state as there were a couple axe(4) instability issues reported in ML. I vaguely thought the issue could be related with USB stack at that time but my testing indicates it might be caused by axe(4). Unfortunately all USB ethernet controllers did not implement a watchdog timeout handler in new USB stack so it was not easy to detect TX stuck condition(USB stack does not detect this condition). I guess if axe(4) had watchdog timeout code some users would have already reported the issue. Is there any reason not to have watchdog timeout handler in driver? If it is not, why USB ethernet drivers in new USB stack removed watchdog handler? I'm not sure resetting controller in ue_tick_task is allowed or not but trying to recover from TX stuck condition by stopping and reinitializing controller didn't work in axe(4). I still have to find a root cause why TX stuck happens on certain axe(4) controller but I have no clue yet. ___ 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: FYI: USB 3.0 support and the XHCI driver is now fully committed to FreeBSD-current
On Tue, Oct 05, 2010 at 11:39:33AM -0700, Mark Atkinson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > On 10/05/2010 10:09, Mark Atkinson wrote: > > Root mount waiting for: usbus3 usbus0 > > [hang, waits forever...] > > Well reverting to r213377 exhibits similar behavior, so I guess this is > not suspect. I'll keep reverting until I find the breakage. It seems I also see the similar behavior. Booting to single user and going back to single user does not work. But USB keyboard still seems to work. ___ 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: Network TX/RX fairness is not honored by USB stack
On Mon, Oct 04, 2010 at 09:54:18PM +0200, Hans Petter Selasky wrote: > > > Personally I'd like to nuke the use of interrupt endpoint here but > > want to hear Han's opinion before doing that. > > If no data is ever transmitted except zero length packets, you can just nuke > it. > Controller always transfers meaningful 8 bytes data(about 1000times/sec) but interrupt callback didn't read it. Even if we can read that data, there is no use for that as link state changes are already handled by mii callback. It seems Linux wants to use that to show link UP/DOWN message though. > Rest of patch looks Ok. > Ok, thanks. > --HPS ___ 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: Network TX/RX fairness is not honored by USB stack
On Sun, Oct 03, 2010 at 08:33:39PM -0700, Julian Elischer wrote: > On 10/3/10 4:54 PM, Pyun YongHyeon wrote: > >On Sat, Oct 02, 2010 at 08:41:57AM +0200, Hans Petter Selasky wrote: > >>On Saturday 02 October 2010 02:11:00 Pyun YongHyeon wrote: > >>>Hi, > >>> > >>>I don't know how long it had been there but it seems current USB > >>>stack does not honor fairness of TX/RX on USB ethernet controller. > >>>Unidirectional performance test(UDP) or most-unidirectional > >>>performance(TCP) test works well without problems. However if heavy > >>>TX/RX traffic hits controller at the same time either TX or RX is > >>>not served at all. I'm under the impression that whenever TX work > >>>is done it seems USB reschedules next pending TX again instead of > >>>processing RX such that RX is starved to death. This can be easily > >>>reproduced on two hosts with the netperf performance test. > >>>Whenever both hosts send tiny UDP datagrams to the other host > >>>either TX or RX packet counters are not increasing until the end > >>>of the UDP torture test. The number of EHCI interrupt is about 8K/s > >>>while test is in progress so I think it reached its maximum > >>>processing limit. After netperf testing, it can still process TX/RX > >>>packets even though it dropped too many RX packets. But these > >>>dropped packets are not counted so netstat(1) shows 0 dropped > >>>frames even though it lost millions of packets. > >>> > >>>Hans, do you have any idea what's going on here? > >>>You can use the following netperf command on both hosts after > >>>running netserver. > >>>%netperf -c -H ip_addr_of_other_host -tUDP_STREAM -l 300 -- -m 1 > >>> > >>>Another odd thing I noticed is number of interrupts does not go > >>>down to 0 after the testing. It constantly generates 1k/s > >>>interrupts after that. > >>Maybe we are triggering a bug. Can you enable USB debugging to figure out > >>what > >>data lengths are transmitted or received. > >> > >In the middle of testing? If yes, that would be meaningless as it > >would generate bunch of messages. The test case generates payload > >size 1 UDP datagrams with full speed so enabling debug messages > >will change timing. Note, I'm exercising number of packets per > >second, not number of bytes per second. > > > >>USB EHCI uses round robin, so this is either USB device problem or a test- > >>program software failure. > >> > >I'm pretty sure the benchmark program is not broken, so either > >axe(4) or USB stack could be wrong here. I see three issues from > >the UDP torture test. > > - Either TX or RX could be starved to death. If you start TX test > >first, RX would be stuck. If you start RX test first, TX would > >be stuck. > > - The number of packets sent or received are much lower than > >expected. > >For TX case, the number of packets sent per second is exactly 8k > >which is much less than that of non-USB controllers. For gigabit > > that is a big clue. > the USB hardware uses an 8 thousand time per second clock for it's > internal polling. > > >controllers number of TX packets could be several hundred > >thousands per second. For RX packets it shows 14K/s packets with > >8K/s interrupts. I thought USB ethernet controllers can send > >more than 8k packets per second. Because the number of > >interrupts per second and 8k packets per second is the same, > >this also make me wonder there could be some relations there. > > - Number of interrupts does not go back to 0 after the testing. > > > >I'll let you know if I find some clue but it may take long time as > >I'm not familiar with USB stack. :-( > > Attached patch address two issues for me. Because axe(4) combines multiple TX into single one, relying on TX completion callback to update TX packet counter was wrong. I moved that counting into TX loop which addressed the issue. Now TX counter shows 221Kpps which looks good to me. I don't think it's correct way to count TX packets as the counter was updated before TX but it seems there is no way to know how many packets are sent at the write callback. The 3rd issue seems to come from setting up interrupt endpoint. It seems controller constantly generates interrupt even if no traffic is there. I was able to decrease number of interrupts generated by setting interval to 1sec which effectively limits number of
Re: Network TX/RX fairness is not honored by USB stack
On Sat, Oct 02, 2010 at 08:41:57AM +0200, Hans Petter Selasky wrote: > On Saturday 02 October 2010 02:11:00 Pyun YongHyeon wrote: > > Hi, > > > > I don't know how long it had been there but it seems current USB > > stack does not honor fairness of TX/RX on USB ethernet controller. > > Unidirectional performance test(UDP) or most-unidirectional > > performance(TCP) test works well without problems. However if heavy > > TX/RX traffic hits controller at the same time either TX or RX is > > not served at all. I'm under the impression that whenever TX work > > is done it seems USB reschedules next pending TX again instead of > > processing RX such that RX is starved to death. This can be easily > > reproduced on two hosts with the netperf performance test. > > Whenever both hosts send tiny UDP datagrams to the other host > > either TX or RX packet counters are not increasing until the end > > of the UDP torture test. The number of EHCI interrupt is about 8K/s > > while test is in progress so I think it reached its maximum > > processing limit. After netperf testing, it can still process TX/RX > > packets even though it dropped too many RX packets. But these > > dropped packets are not counted so netstat(1) shows 0 dropped > > frames even though it lost millions of packets. > > > > Hans, do you have any idea what's going on here? > > You can use the following netperf command on both hosts after > > running netserver. > > %netperf -c -H ip_addr_of_other_host -tUDP_STREAM -l 300 -- -m 1 > > > > Another odd thing I noticed is number of interrupts does not go > > down to 0 after the testing. It constantly generates 1k/s > > interrupts after that. > > Maybe we are triggering a bug. Can you enable USB debugging to figure out > what > data lengths are transmitted or received. > In the middle of testing? If yes, that would be meaningless as it would generate bunch of messages. The test case generates payload size 1 UDP datagrams with full speed so enabling debug messages will change timing. Note, I'm exercising number of packets per second, not number of bytes per second. > USB EHCI uses round robin, so this is either USB device problem or a test- > program software failure. > I'm pretty sure the benchmark program is not broken, so either axe(4) or USB stack could be wrong here. I see three issues from the UDP torture test. - Either TX or RX could be starved to death. If you start TX test first, RX would be stuck. If you start RX test first, TX would be stuck. - The number of packets sent or received are much lower than expected. For TX case, the number of packets sent per second is exactly 8k which is much less than that of non-USB controllers. For gigabit controllers number of TX packets could be several hundred thousands per second. For RX packets it shows 14K/s packets with 8K/s interrupts. I thought USB ethernet controllers can send more than 8k packets per second. Because the number of interrupts per second and 8k packets per second is the same, this also make me wonder there could be some relations there. - Number of interrupts does not go back to 0 after the testing. I'll let you know if I find some clue but it may take long time as I'm not familiar with USB stack. :-( > Check the CPU usage of the host computer during the test. Do you see anything? > I didn't notice odd thing except 8k/s interrupts. > > The only way I stop that interrupts was to > > down the ue0 interface with "ifconfig ue0 down" command. > > --HPS ___ 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"
Network TX/RX fairness is not honored by USB stack
Hi, I don't know how long it had been there but it seems current USB stack does not honor fairness of TX/RX on USB ethernet controller. Unidirectional performance test(UDP) or most-unidirectional performance(TCP) test works well without problems. However if heavy TX/RX traffic hits controller at the same time either TX or RX is not served at all. I'm under the impression that whenever TX work is done it seems USB reschedules next pending TX again instead of processing RX such that RX is starved to death. This can be easily reproduced on two hosts with the netperf performance test. Whenever both hosts send tiny UDP datagrams to the other host either TX or RX packet counters are not increasing until the end of the UDP torture test. The number of EHCI interrupt is about 8K/s while test is in progress so I think it reached its maximum processing limit. After netperf testing, it can still process TX/RX packets even though it dropped too many RX packets. But these dropped packets are not counted so netstat(1) shows 0 dropped frames even though it lost millions of packets. Hans, do you have any idea what's going on here? You can use the following netperf command on both hosts after running netserver. %netperf -c -H ip_addr_of_other_host -tUDP_STREAM -l 300 -- -m 1 Another odd thing I noticed is number of interrupts does not go down to 0 after the testing. It constantly generates 1k/s interrupts after that. The only way I stop that interrupts was to down the ue0 interface with "ifconfig ue0 down" command. ___ 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 Tue, Jul 20, 2010 at 04:10:03PM +, Derrick Brashear wrote: > The following reply was made to PR usb/140883; it has been noted by GNATS. > > From: Derrick Brashear > To: bug-follo...@freebsd.org > Cc: > Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short > period of traffic > Date: Tue, 20 Jul 2010 11:39:28 -0400 > > Happens with non-gig adapters also: > axe0: on usbus2 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > axe1: on usbus2 > ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > USB200M v2. > > USB_ERR_TIMEOUT until a reset is forced after a large amount of data > passes, e.g. > Jul 20 01:50:38 rtr kernel: axe_bulk_write_callback: transfer error, > USB_ERR_TIMEOUT > Jul 20 01:50:48 rtr kernel: axe_bulk_write_callback: transfer error, > USB_ERR_TIMEOUT > Jul 20 01:50:57 rtr kernel: axe_bulk_write_callback: transfer error, > USB_ERR_TIMEOUT > Jul 20 01:51:01 rtr kernel: axe_bulk_read_callback: bulk read error, > USB_ERR_CANCELLED > Jul 20 01:51:01 rtr kernel: axe_bulk_write_callback: transfer error, > USB_ERR_CANCELLED > Jul 20 01:51:13 rtr kernel: axe_bulk_read_callback: bulk read error, > USB_ERR_CANCELLED > > and data continues to be able to be read after writing it fails, as > described in the original PR. > I think your issue is different from the PR. There are several AX88178 variants that use different PHY and each controller/PHY combination require different GPIO programming and PHY specific initialization. Hans committed that part to P4 but it's not in CURRENT yet. Your controller looks like AX88772A, a second generation of AX88172. It's known that there is AX88772B, another variant of AX88772A, which can offload TX/RX checksum computation from CPU. These controllers seem to require controller specific magic to power up PHY as well as new GPIO configuration. Unfortunately it looks hard to write patches without real hardware access and ASIX no more provide data sheet for these newer controllers. > sysctl -a|grep date > kern.osreldate: 801000 > ___ 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, Apr 12, 2010 at 05:52:55PM -0700, Pyun YongHyeon wrote: > On Sun, Apr 04, 2010 at 06:12:56PM -0700, 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 wrote: > > > > > > > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: > > > > > > > > [...] > > > > > > > > > >> I changed and got this: > > > > > >> > > > > > >> miibus1: on axe0 > > > > > >> ukphy0: 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: 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: on axe0 > > > ukphy0: 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: 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=8843 metric 0 mtu 1500 > > > options=8 > > > 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=8843 metric 0 mtu 1500 > > > options=8 > > > ether 00:11:50:e7:39:e9 > > > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > > > media: Ethernet none (none ) > > > status: active > > > arroway# ifconfig ue0 > > > ue0: flags=8843 metric 0 mtu 1500 > > > options=8 > > > 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. :-( > > Today I got ordered Belkin F5D5055 USB controller. And I believe > this controller is the same one as you have. With the previous patch > it worked as expected on my box. > > axe0: on > usbus7 > axe0: PHYADDR 0xe0:0x01 > miibus0: on axe0 > truephy0: PHY 1 on miibus0 > truephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto > ue0: on axe0 > ue0: Ethernet address: 00:22:75:d6:ab:88 > ue0: link state changed to DOWN > ue0: link state changed to UP > > And the performance number for the controller is also similar to > other AX88178 gigabit controllers. So I guess axe(4) has no issue > in handling Belkin F5D5055 USB controller but underlying ehci(4) > could be behaving incorrectly. I believe this part could be > explained/debugged by Hans. > Mine is the following. > >ehci1 pnpinfo vendor=0x8086 device=0x3a6a subvendor=0x1028 > subdevice=0x027f class=0x0c0320 at slot=29 function=7 > Interrupt request lines: > 23 > I/O memory addresses: > 0xff98-0xff9803ff > usbus7 > uhub7 > axe0 pnpinfo vendor=0x050d product=0x5055 devclass=0xff > devsubclass=0xff sernum="" release=0x0001 intclass=0xff intsubclass=0xff at > port=5 interface=0 > miibus0 > truephy0 pnpinfo oui=0xa0bc model=0x1 rev=0x4 at phyno=1 > > Hope this helps. FYI: Patch committed to HEAD(r206563). ___ 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 Sun, Apr 04, 2010 at 06:12:56PM -0700, 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 wrote: > > > > > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: > > > > > > [...] > > > > > > > >> I changed and got this: > > > > >> > > > > >> miibus1: on axe0 > > > > >> ukphy0: 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: 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: on axe0 > > ukphy0: 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: 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=8843 metric 0 mtu 1500 > > options=8 > > 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=8843 metric 0 mtu 1500 > > options=8 > > ether 00:11:50:e7:39:e9 > > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > > media: Ethernet none (none ) > > status: active > > arroway# ifconfig ue0 > > ue0: flags=8843 metric 0 mtu 1500 > > options=8 > > 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. :-( Today I got ordered Belkin F5D5055 USB controller. And I believe this controller is the same one as you have. With the previous patch it worked as expected on my box. axe0: on usbus7 axe0: PHYADDR 0xe0:0x01 miibus0: on axe0 truephy0: PHY 1 on miibus0 truephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto ue0: on axe0 ue0: Ethernet address: 00:22:75:d6:ab:88 ue0: link state changed to DOWN ue0: link state changed to UP And the performance number for the controller is also similar to other AX88178 gigabit controllers. So I guess axe(4) has no issue in handling Belkin F5D5055 USB controller but underlying ehci(4) could be behaving incorrectly. I believe this part could be explained/debugged by Hans. Mine is the following. ehci1 pnpinfo vendor=0x8086 device=0x3a6a subvendor=0x1028 subdevice=0x027f class=0x0c0320 at slot=29 function=7 Interrupt request lines: 23 I/O memory addresses: 0xff98-0xff9803ff usbus7 uhub7 axe0 pnpinfo vendor=0x050d product=0x5055 devclass=0xff devsubclass=0xff sernum="" release=0x0001 intclass=0xff intsubclass=0xff at port=5 interface=0 miibus0 truephy0 pnpinfo oui=0xa0bc model=0x1 rev=0x4 at phyno=1 Hope this helps. ___ 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 Sat, Apr 03, 2010 at 09:46:59PM -0300, Nenhum_de_Nos wrote: > On Wed, 31 Mar 2010 12:06:31 -0700 > Pyun YongHyeon wrote: > > > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: > > > > [...] > > > > > >> I changed and got this: > > > >> > > > >> miibus1: on axe0 > > > >> ukphy0: 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: 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: on axe0 > ukphy0: 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: 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=8843 metric 0 mtu 1500 > options=8 > 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=8843 metric 0 mtu 1500 > options=8 > ether 00:11:50:e7:39:e9 > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > media: Ethernet none (none ) > status: active > arroway# ifconfig ue0 > ue0: flags=8843 metric 0 mtu 1500 > options=8 > 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. :-( ___ 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, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: [...] > >> I changed and got this: > >> > >> miibus1: on axe0 > >> ukphy0: 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: 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? ___ 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, 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: on axe0 > >> >> ukphy0: 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: at usbus1 > axe0: on usbus1 > axe0: PHYADDR 0xe0:0x01 > miibus1: on axe0 > ukphy0: PHY 1 on miibus1 > ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > ue0: 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. > 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: on axe0 > ukphy0: 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. > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > ue0: 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. ___ 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 Thu, Mar 25, 2010 at 09:57:22PM -0300, Nenhum_de_Nos wrote:
[...]
> >> miibus1: on axe0
> >> ukphy0: 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.
> 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?
> >
Index: sys/dev/usb/net/if_axe.c
===
--- sys/dev/usb/net/if_axe.c(revision 205700)
+++ sys/dev/usb/net/if_axe.c(working copy)
@@ -295,7 +295,7 @@
{
struct axe_softc *sc = device_get_softc(dev);
uint16_t val;
- int locked;
+ int error, locked;
if (sc->sc_phyno != phy)
return (0);
@@ -304,9 +304,15 @@
if (!locked)
AXE_LOCK(sc);
- axe_cmd(sc, AXE_CMD_MII_OPMODE_SW, 0, 0, NULL);
- axe_cmd(sc, AXE_CMD_MII_READ_REG, reg, phy, &val);
- axe_cmd(sc, AXE_CMD_MII_OPMODE_HW, 0, 0, NULL);
+ error = axe_cmd(sc, AXE_CMD_MII_OPMODE_SW, 0, 0, NULL);
+ if (error != 0)
+ printf("AXE_CMD_MII_OPMODE_SW failed : %d:%d\n", reg, error);
+ error = axe_cmd(sc, AXE_CMD_MII_READ_REG, reg, phy, &val);
+ if (error != 0)
+ printf("AXE_CMD_MII_READ_REG failed : %d:%d\n", reg, error);
+ error = axe_cmd(sc, AXE_CMD_MII_OPMODE_HW, 0, 0, NULL);
+ if (error != 0)
+ printf("AXE_CMD_MII_OPMODE_HW failed : %d:%d\n", reg, error);
val = le16toh(val);
if ((sc->sc_flags & AXE_FLAG_772) != 0 && reg == MII_BMSR) {
___
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 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=8843 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 ) > >> >> > > >> status: active > >> >> > > >> and: > >> >> > > >> ue0: flags=8843 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 > >> ) > >> >> > > > > >> >> > > > > >> >> > > >> 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: > >&
Re: 10Mbps+ throughput usb based ethernet recommendation
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=8843 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 ) > >> > > >> status: active > >> > > >> and: > >> > > >> ue0: flags=8843 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 ) > >> > > > > >> > > > > >> > > >> 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: 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: at usbus1 > Mar 25 14:16:19 darkside kernel: axe0: 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: on axe0 > Mar 25 14:16:20 darkside kernel: ukphy0: 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: 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. ___ 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, 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=8843 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 ) > > > >>status: active > > > >> and: > > > >> ue0: flags=8843 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 ) > > > > > > > >>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. Index: sys/dev/mii/ukphy.c === --- sys/dev/mii/ukphy.c (revision 205608) +++ sys/dev/mii/ukphy.c (working copy) @@ -141,6 +141,8 @@ device_printf(dev, "OUI 0x%06x, model 0x%04x, rev. %d\n", MII_OUI(ma->mii_id1, ma->mii_id2), MII_MODEL(ma->mii_id2), MII_REV(ma->mii_id2)); + device_printf(dev, "XXX ID1 = 0x%04x, ID2 = 0x%04x\n", + ma->mii_id1, ma->mii_id2); sc->mii_inst = mii->mii_instance; sc->mii_phy = ma->mii_phyno; ___ 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, 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=8843 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 ) > > >> status: active > > >> and: > > >> ue0: flags=8843 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 ) > > > > > >> 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". > > > > 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 commits are the same ). > > > > Unless we fix the PHY issue you would get the same result on > stable/8. > > > still looking for better performance usb nic :) you think the slower > > linksys usb200m (axe based also) will have better luck in this link > > negotiation issue ? (I don't need gigabit, just to break the 10Mbps at > > I have no experience with usb200m so I don't know. > > > start - though breaking the 50Mpbs would be perfert). > > > > thanks, ___ 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, 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=8843 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 ) > >>status: active > >> and: > >> ue0: flags=8843 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 ) > > > >>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? > > 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 commits are the same ). > Unless we fix the PHY issue you would get the same result on stable/8. > still looking for better performance usb nic :) you think the slower > linksys usb200m (axe based also) will have better luck in this link > negotiation issue ? (I don't need gigabit, just to break the 10Mbps at I have no experience with usb200m so I don't know. > start - though breaking the 50Mpbs would be perfert). > > thanks, ___ 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 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=8843 metric 0 mtu 1500 > ether 00:11:50:e7:39:e9 > inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
Re: 10Mbps+ throughput usb based ethernet recommendation
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. ___ 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, 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. I'm not sure which FreeBSD version pfsense is based on though. ___ 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(4) USB gigabit ethernet hangs after short period of traffic
On Mon, Nov 30, 2009 at 04:42:28AM +0100, Jason Edwards wrote:
> [r...@mesa /]# devinfo -rv | grep phy
> (..)
> ukphy1 pnpinfo oui=0x606e model=0xc rev=0x0 at phyno=0
> (..)
>
> I understand my device may have the same name, but different PHY thus
> is actually a different product.
>
This looks strange. According to the output above, the OUI
indicates the PHY vendor is Davicom and its model number is 0x0c.
However, the vendor's site has no mention of gigabit PHY and also
their current product line does not seem to have model C of PHY.
Are you sure your axe(4) controller has gigabit PHY?
Or by chance did you capture the output of udav(4)?
> In order to debug this problem i need physical access to change the
> ethernet cables (and replug the device once its stuck). Probably might
> get the chance tomorrow.
>
> Aside from enabling debug and trying to get it to the point it fails,
> what else could i try to identify the problem or is there any other
> information you require to diagnose this issue?
>
> Thanks for looking into it!
> Kind regards,
> sub
>
> On 11/29/09, Pyun YongHyeon wrote:
> > On Thu, Nov 26, 2009 at 08:40:04AM +, Hans Petter Selasky wrote:
> >> The following reply was made to PR usb/140883; it has been noted by GNATS.
> >>
> >> From: Hans Petter Selasky
> >> To: freebsd-usb@freebsd.org
> >> Cc: sub mesa ,
> >> freebsd-gnats-sub...@freebsd.org
> >> Subject: Re: usb/140883: axe(4) USB gigabit ethernet hangs after short
> >> period of traffic
> >> Date: Thu, 26 Nov 2009 09:32:43 +0100
> >>
> >> On Thursday 26 November 2009 03:59:55 sub mesa wrote:
> >> > >Number: 140883
> >> > >Category: usb
> >> > >Synopsis: axe(4) USB gigabit ethernet hangs after short period
> >> of
> >> > > traffic Confidential: no
> >> > >Severity: serious
> >> > >Priority: medium
> >> > >Responsible:freebsd-usb
> >> > >State: open
> >> > >Quarter:
> >> > >Keywords:
> >> > >Date-Required:
> >> > >Class: sw-bug
> >> > >Submitter-Id: current-users
> >> > >Arrival-Date: Thu Nov 26 03:00:11 UTC 2009
> >> > >Closed-Date:
> >> > >Last-Modified:
> >> > >Originator: sub mesa
> >> > >Release:FreeBSD 8.0-RELEASE i386
> >> > >Organization:
> >> > >Environment:
> >> >
> >> > FreeBSD gut 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Wed Nov 25 14:30:17 CET
> >> > 2009 x...@xor:/usr/obj/usr/src/sys/XOR i386
> >> >
> >> > >Description:
> >> >
> >> > I own a USB gigabit ethernet adapter with ASIX Electronics AX88178 chip
> >> > supported by the axe(4) driver in FreeBSD 8.0. It works, but it
> >> 'freezes'
> >> > or 'hangs' after some traffic, like downloading at ~50Mbps for 5-10
> >> minutes
> >> > will cause the device to freeze. This has been happening since a long
> >> time
> >> > on 8.0, ever since i bought the device and was running one of the early
> >> > beta's. Upgrading to the final release of 8.0 did not resolve the
> >> issue.
> >> >
> >> > Googling on the problem i found this mailinglist thread:
> >> >
> >> http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005738.html
> >> >
> >> > However, there doesn't seem to be a single conclusion. Even though my
> >> > product ("Belkin F5D5055") seems to be supported according to the
> >> axe(4)
> >> > manpage, it doesn't get detected as such, rather with a vendor id.
> >> Quoting
> >> > dmesg output:
> >> >
> >> > axe0: on usbus4
> >> > axe0: PHYADDR 0xe0:0x01
> >> > miibus1: on axe0
> >> > ue0: on axe0
> >> >
> >> > May i suggest removing the Belkin F5D5055 from the supported devices
> >> list
> >> > in the axe(4) manpage, until a fix has been committed? I specifically
> >> > bought the device believing it would work since it was explicitly
> >> listed in
> >> > the manpage. As of 8.0, it doesn't even get detected by name. It is of
> >> > course possible my device is of a different revision.
> >
> > I frequently see some vendors do not chan
Re: ASIX USB-to-Ethernet drivers
On Sun, Nov 29, 2009 at 05:03:44PM -0700, Brett Glass wrote: > At 02:23 PM 11/29/2009, Pyun YongHyeon wrote: > > >I think the large number of interrupts has nothing to do with > >axe(4). Almost all USB ethernet controllers are poorly designed > >to save cost so you can't expect reasonable performance from it and > >you should have fast CPU to copy received frames in a buffer. > >It's worse than rl(4) controllers. > > Are there any that are better? I have several machines here that I will > be using as embedded systems. They have one Ethernet interface each, > and I need some of them to have two. The only other non-USB ports > on these machines are video and CompactFlash. > If you had redundant mini PCI/PCIe slot I would have recommended to avoid USB based ethernet controllers. > I've thought about using VLAN tagging and VLAN switch to double up > the Ethernet port, but this is quite expensive. So, I need the best USB > Ethernet I can get. > > I chose the AX88772A because it seems to be a better solution than the > Davicom DM9601 (which is USB 1.0 only). The AX88178 has more buffer > space, but I am having trouble finding reasonably priced adapters that > use it. > > --Brett Glass > ___ 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] USB gigabit ethernet hangs after short period of traffic
On Sun, Nov 29, 2009 at 04:51:09PM -0700, Brett Glass wrote: > At 02:38 PM 11/29/2009, Pyun YongHyeon wrote: > > >I'm not sure buffer size allowed in driver is 4K. Long time ago I > >increased Rx buffer size to 16KB from 2KB for 88178/88772. That > >change was essential to get 220Mbps for 88178/88772 on Rx. The > >patch was not made into 8.0-RELEASE though. > > If not, it certainly ought to get into 8.1-RELEASE and 7.3-RELEASE... > so long as it doesn't cause the USB stack to freeze up. 16 KB is a > much more reasonable buffer size. > Actually 16KB was controller default buffer size of AX88178. axe(4) just used to set 2KB for Rx buffer which could be safely set for all ASIX controllers. > By the way, I've done some stress testing with the patch I posted, and > it seems very solid. It appears that the AX88772A chip can safely be > treated like an AX88772. > That's great! > --Brett Glass > > ___ 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: ASIX USB-to-Ethernet drivers
On Sat, Nov 28, 2009 at 01:40:18PM -0700, Brett Glass wrote: > Everyone: > > Just tried to plug an ASIX-based USB-to-Ethernet interface into a > system running FreeBSD 8.0-RELEASE, and discovered that it wasn't > recognized. It turns out that ASIX has come out with a new version > of one of its chips: the AX88772A. It has a smaller package with > fewer pins, slightly less buffer memory, and a serial interface so > that it can also support power line networking (see > http://www.asix.com.tw/products.php?op=ProductList&PLine=71&PSeries=100). > The AX88772 is being phased out by most interface manufacturers > because the "A" chip is smaller and cheaper and takes up less board > space. I am sure that I will not be the only person who is > frustrated when plugging in an interface that looks the same as the > older ones and finding that it doesn't work! > > I've discovered that the existing axe(4) driver for FreeBSD seems > to work on the AX88772A without any changes if it is told to treat > the chip like an AX88772. (It may not be optimal, because the ASIX > Linux driver code does differentiate between the two. And the AFAIK Linux does not differentiate 88772A from 88772. Since ASIX seems to require account to download datasheet I couldn't check the datasheet but I guess 88772A has the same interface for driver's view. > command "systat -vmstat 1" does show a lot of IRQs -- about one per > millisecond. Also, the link light on the interface does not work, I think the large number of interrupts has nothing to do with axe(4). Almost all USB ethernet controllers are poorly designed to save cost so you can't expect reasonable performance from it and you should have fast CPU to copy received frames in a buffer. It's worse than rl(4) controllers. Datasheet may have an entry to control LEDs. Linux may also have the same problem as they don't try to program LEDs unless the PHY is Marvell gigabit PHY. > though this is a minor nit that I can live with. But the interface > does at least run.) > > For the moment, I've patched /sys/dev/usb/usbdevs and > /sys/dev/usb/net/axe to treat the AX88772A as if it were an AX88772 > (patch submitted as PR 140923) so that I can get my systems Maybe Hans can handle this. > working. But it would probably be a good idea to do more thorough > testing > > --Brett Glass ___ 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] USB gigabit ethernet hangs after short period of traffic
On Sun, Nov 29, 2009 at 02:50:03AM +, Brett Glass wrote: > The following reply was made to PR usb/140883; it has been noted by GNATS. > > From: Brett Glass > To: bug-follo...@freebsd.org > Cc: sub.m...@gmail.com > Subject: Re: usb/140883: [axe] USB gigabit ethernet hangs after short > period of traffic > Date: Sat, 28 Nov 2009 19:04:49 -0700 > > The reason why the vendor name and device name is not appearing is > that the USB_VERBOSE option was not included in the configuration > of the 8.0-RELEASE GENERIC kernel. > > The USB_VERBOSE option should be included in GENERIC. Otherwise, > any USB device whose driver follows the proper coding convention -- > that is, placing vendor and product information in /sys/usb/usbdevs > rather than in the driver itself -- will not print the name of the > vendor or device. > > The failure to print the name has nothing to do with the > malfunction in the device, which may be due to overruns. (The > buffer size currently allowed in the driver -- only 4K -- is extremely > small.) > I'm not sure buffer size allowed in driver is 4K. Long time ago I increased Rx buffer size to 16KB from 2KB for 88178/88772. That change was essential to get 220Mbps for 88178/88772 on Rx. The patch was not made into 8.0-RELEASE though. You can try the patch from the following URL. http://svn.freebsd.org/viewvc/base/head/sys/dev/usb/net/if_axe.c?r1=197565&r2=197566&view=patch ___ 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(4) USB gigabit ethernet hangs after short period of traffic
On Thu, Nov 26, 2009 at 08:40:04AM +, Hans Petter Selasky wrote:
> The following reply was made to PR usb/140883; it has been noted by GNATS.
>
> From: Hans Petter Selasky
> To: freebsd-usb@freebsd.org
> Cc: sub mesa ,
> freebsd-gnats-sub...@freebsd.org
> Subject: Re: usb/140883: axe(4) USB gigabit ethernet hangs after short period
> of traffic
> Date: Thu, 26 Nov 2009 09:32:43 +0100
>
> On Thursday 26 November 2009 03:59:55 sub mesa wrote:
> > >Number: 140883
> > >Category: usb
> > >Synopsis: axe(4) USB gigabit ethernet hangs after short period of
> > > traffic Confidential: no
> > >Severity: serious
> > >Priority: medium
> > >Responsible:freebsd-usb
> > >State: open
> > >Quarter:
> > >Keywords:
> > >Date-Required:
> > >Class: sw-bug
> > >Submitter-Id: current-users
> > >Arrival-Date: Thu Nov 26 03:00:11 UTC 2009
> > >Closed-Date:
> > >Last-Modified:
> > >Originator: sub mesa
> > >Release:FreeBSD 8.0-RELEASE i386
> > >Organization:
> > >Environment:
> >
> > FreeBSD gut 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Wed Nov 25 14:30:17 CET
> > 2009 x...@xor:/usr/obj/usr/src/sys/XOR i386
> >
> > >Description:
> >
> > I own a USB gigabit ethernet adapter with ASIX Electronics AX88178 chip
> > supported by the axe(4) driver in FreeBSD 8.0. It works, but it 'freezes'
> > or 'hangs' after some traffic, like downloading at ~50Mbps for 5-10 minutes
> > will cause the device to freeze. This has been happening since a long time
> > on 8.0, ever since i bought the device and was running one of the early
> > beta's. Upgrading to the final release of 8.0 did not resolve the issue.
> >
> > Googling on the problem i found this mailinglist thread:
> > http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005738.html
> >
> > However, there doesn't seem to be a single conclusion. Even though my
> > product ("Belkin F5D5055") seems to be supported according to the axe(4)
> > manpage, it doesn't get detected as such, rather with a vendor id. Quoting
> > dmesg output:
> >
> > axe0: on usbus4
> > axe0: PHYADDR 0xe0:0x01
> > miibus1: on axe0
> > ue0: on axe0
> >
> > May i suggest removing the Belkin F5D5055 from the supported devices list
> > in the axe(4) manpage, until a fix has been committed? I specifically
> > bought the device believing it would work since it was explicitly listed in
> > the manpage. As of 8.0, it doesn't even get detected by name. It is of
> > course possible my device is of a different revision.
I frequently see some vendors do not change their model name even
though the controller's internal chipset/PHY was changed. I guess
the original FD5055 have used different PHY so it might have worked
at that time.
> >
> > I would be happy to try any patches.
> >
> > Also see:
> > http://forums.freebsd.org/showthread.php?t=8661
> >
> > >How-To-Repeat:
> >
> > Connect axe(4) gigabit ethernet device
> > Send/receive packets using the ueX ethernet device
> > Device will stop receiving/transmitting packets after a short while
> >
I remember some user also reported instability of axe(4) on Belkin
F5D5055. I'm not sure what PHY driver was attached to your
controller but it could also be a variant of LSI TruePHY.
Would you show me the output of "devinfo -rv | grep phy"?
___
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: aue0 detected as ue0 on 8.0-RC2
On Tue, Nov 03, 2009 at 10:10:47AM +, Gavin Atkinson wrote: > [freebsd-current cc'd, as that was where the thread started, but this > probably belongs on -usb, replies should go there] > > On Sat, 2009-10-31 at 21:59 +0100, Rick van der Zwet wrote: > > The first net interface of a aue(4) define used to be called aue0 > > afaik. But is now called ue0 (declared in usb/net/usb_ethernet.c). (no > > sign of ue(4) btw). > > > > I was looking in the UPDATING, man, mailinglists freebsd-usb@ and > > freebsd-curr...@. But I could not find the reason why the naming > > convention on this aue differs from the regular stuff, anybody? > > > > /Rick > > > > quick# dmesg | tail -8 > > ugen1.3: at usbus1 > > aue0: on usbus1 > > miibus1: on aue0 > > ukphy0: PHY 1 on miibus1 > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > ue0: on aue0 > > ue0: Ethernet address: 00:00:e8:00:11:36 > > ue0: link state changed to DOWN > > > > quick# ifconfig -l > > bfe0 lo0 ue0 > > Hmm, this looks like a serious bug, possibly in the new USB subsystem > (HPS CC'd). > > I've got an axe(4) device, which also does the same: > > ugen7.3: at usbus7 > axe0: on usbus7 > axe0: PHYADDR 0xe0:0x10 > miibus1: on axe0 > ukphy0: PHY 16 on miibus1 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on axe0 > ue0: Ethernet address: 00:50:b6:05:57:a7 > ue0: link state changed to DOWN > I'm not sure this is feature of new USB or bug. I don't have strong objections on current behavior but looks like I'm seeing Linux behavior. Traditionally all network interfaces used their own driver name. I think this change should be documented in UPDATING. > Gavin ___ 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: CFT: axe(4) performance patch
On Fri, Sep 18, 2009 at 12:06:57AM +0900, Norikatsu Shigemura wrote: > Hi pyun! > > On Mon, 14 Sep 2009 12:37:22 -0700 > Pyun YongHyeon wrote: > > I submitted axe(4) performance patch to Hans and he committed the > > patch to P4. > > http://perforce.freebsd.org/chv.cgi?CH=168457 > > I tested following environments: > Thanks a lot nork@ ! > AX88178(GbE), AX88172(100), AX88772(100), bge(GbE), re(GbE), rl(100) > > patched:AX88178, AX88172, AX88772 <-> bge > old:AX88178, AX88172, AX88772 <-> bge > patched:AX88178, AX88172, AX88772 <-> rl > old:AX88178, AX88172, AX88772 <-> re > > My environment, there are 3 machines: > +--++-++ (All port GbE L2SW) > || | >bge re rl >(patched) (old) > >bge: FreeBSD 7.2-stable > re: FreeBSD 9-current > rl: FreeBSD 8.0-beta4 > > > For test environments: > +--++---+---+---+ +--+-+--+--+---+ > || ||| | >bge re rl-axebge re-axerl > (old)(patched) > > > According to netperf, > > patched:AX88178, AX88172, AX88772 <-> bge >60Mbps, 60Mbps, 25Mbps > patched:AX88178, AX88172, AX88772 <-> rl >90Mbps, 60Mbps, 40Mbps > > old:AX88178, AX88172, AX88772 <-> bge > 180Mbps, 90Mbps, 95Mbps > old:AX88178, AX88172, AX88772 <-> re > 180Mbps, 90Mbps, 95Mbps > I'm not sure I understood the test environment. But it looks un-patched axe(4) performs better, right? One odd thing is performance differences for AX88172. My patch does not touch AX88172 controller but your benchmark shows big differences for AX88172. Are you sure you didn't apply other patches for axe(4)/USB stack? Ehh, I was wrong, there was a change for AX88172. The bufsize was changed to 16KB from 2KB for AX88172, that was not my intention. It seems new USB stack has no easy way to configure this parameter in attach phase so I used 16KB. Would you try changing the value to MCLBYTES(aorund line number 208 in patched if_axe.c) and test it on AX88172? Also please let me know what netperf parameters were used in the test. > U, I'll try to update old(rl) machine to pached, and re-test. > > Thank you. It seems you have all three variants that axe(4) supports, so would you test "http://p4db.freebsd.org/chv.cgi?CH=168602";? ___ 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: CFT: axe(4) station address patch
On Wed, Sep 16, 2009 at 11:55:04PM +0200, Hans Petter Selasky wrote: > Hi, > > Can you send me the patch. > Sure. > Seems like the list software stripped it off. > > --HPS > > On Wednesday 16 September 2009 20:52:56 Pyun YongHyeon wrote: > > Hi, > > > > Traditionally axe(4) didn't support reprogramming station address > > (node id) as datasheet does not mention the required command. > > However AX88178 datasheet has the command and it seems the command > > works as expected. I've attached patch which will enable changing > > ethernet address of the controller for AX88178/AX88772/AX88172. > > I couldn't test it on AX88772 and AX88172 controller. So if you > > have these controllers would you give it try let me know how it > > goes on your controller? > > > > > > Check the ethernet address and change it to other address with > > ifconfig(8). The following command will change the ethernet address > > to aa:bb:cc:dd:ee:ff. > > #ifconfig ue0 down > > #ifconfig ue0 ether aa:bb:cc:dd:ee:ff > > #ifconfig ue0 up > > After that check whether you can still use network. > > > > Hans, would you review the patch? > ___ 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"
CFT: axe(4) station address patch
Hi, Traditionally axe(4) didn't support reprogramming station address (node id) as datasheet does not mention the required command. However AX88178 datasheet has the command and it seems the command works as expected. I've attached patch which will enable changing ethernet address of the controller for AX88178/AX88772/AX88172. I couldn't test it on AX88772 and AX88172 controller. So if you have these controllers would you give it try let me know how it goes on your controller? Check the ethernet address and change it to other address with ifconfig(8). The following command will change the ethernet address to aa:bb:cc:dd:ee:ff. #ifconfig ue0 down #ifconfig ue0 ether aa:bb:cc:dd:ee:ff #ifconfig ue0 up After that check whether you can still use network. Hans, would you review the patch? ___ 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"
CFT: axe(4) performance patch
Hi, I submitted axe(4) performance patch to Hans and he committed the patch to P4. http://perforce.freebsd.org/chv.cgi?CH=168457 The patch fixes two issues, lots of Rx errors seen under high network load and poor Rx performance. The Rx error was introduced in new USB stack conversion and it was not spotted until this time. For better Rx performance, the patch increases Rx maximum burst size to 16384 from 2048 for AX88178 and AX88772. Now I can see dramatic Rx performance boost from 50Mbps to 220Mbps on AX88178. AX88178 data sheet clearly indicates the default burst size is 16384 for maximum performance. But I don't know whether it breaks AX88772 fast ethernet controller. Now vendor's site requires valid account to download AX88772 data sheet so I can't verify that. If you have AX88772 or AX88178 please give it try and let us know how it goes. Since all USB ethernet controllers are poorly designed to save money and ASIX USB ether controller requires copy operation for every received frames(actually it's much much worse than rl(4) hardwares), you should have fast system to achieve maximum speed. I see constant Rx 220Mbps for various packet sizes(from 64 bytes to MTU sized bytes) on my 2.8GHz C2D. I don't know 220Mbps is the maximum speed the controller can achieve but I never seen these numbers on any USB ethernet drivers on FreeBSD. ___ 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: USB2: [was: umass not detected correctly, axe not transmitting] AXE problems
On Fri, Feb 13, 2009 at 10:58:12AM +0900, Pyun YongHyeon wrote: > On Fri, Feb 13, 2009 at 02:17:16AM +0900, Hiroharu Tamaru wrote: [...] > > This symptom was solved after I have brought my userland in > > sync with the kernel. > > > > So here I am, with all my USB2 problems solved! > > Thank you all for this quick assistance! > > > > And finally, I'd appreciate if you could send me or the list > > the 'commit done' message on this ethernet patch and the > > mountroot delay patch, so that I can mark to forget about > > patching the kernel as I cvsup it. Thanks. > > > > Will do. > FYI: Andrew committed the fix, r188553. ___ 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: USB2: [was: umass not detected correctly, axe not transmitting] AXE problems
On Fri, Feb 13, 2009 at 02:17:16AM +0900, Hiroharu Tamaru wrote: > Hi, I'm back with the results. > And to make it short, everything works now. > Thank you, Hans and Pyun, and all others who looked into this for me. > Great! Andrew, would you commit the patch? > Some notes inline: > [...] > OK, the patch usb2_ethernet.patch2 in > <20090212043033.gc6...@michelle.cdnetworks.co.kr> worked, and now the > ue0/AXE interface is working fine. > > Though I have only tested in 100BaseTX/full-duplex mode, > ping -f over a 100Mbps switch run without any packet loss > (sysctl net.inet.icmp.icmplim=0, of course), and the interface > statics shows no errors too: > > NameMtu Network Address Ipkts IerrsOpkts Oerrs > Coll > ue01500 00:90:cc:xx:xx:xx32634 0321920 0 > ue01500 192.168.1.0 192.168.1.3 32553 -32190- - > > > Also, > At Thu, 12 Feb 2009 12:51:00 +0900, Hiroharu Tamaru wrote: > > I also have em0/em1 interfaces, and I am switching with ue0 > > when I test AXE. > > > > It turned out that although I 'ifconfig em0 inet delete > > down' those unused interfaces, the arp table entries remain. > > 'arp -nda' shows 'delete: cannot locate 192.168.1.1' and the > > like for every entry in the table, and they are infact not > > deleted. Deletion fails both when em0 is up and down. > > This symptom was solved after I have brought my userland in > sync with the kernel. > > So here I am, with all my USB2 problems solved! > Thank you all for this quick assistance! > > And finally, I'd appreciate if you could send me or the list > the 'commit done' message on this ethernet patch and the > mountroot delay patch, so that I can mark to forget about > patching the kernel as I cvsup it. Thanks. > Will do. Thanks for testing! ___ 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: USB2: [was: umass not detected correctly, axe not transmitting] AXE problems
On Wed, Feb 11, 2009 at 07:57:52PM -0800, Andrew Thompson wrote: > On Thu, Feb 12, 2009 at 12:42:51PM +0900, Pyun YongHyeon wrote: > > > > > > I have the same USB controller and latest CURRENT works. > > > > > > axe0: on usbus1 > > > axe0: PHYADDR 0xe0:0x18 > > > miibus2: on axe0 > > > ciphy0: PHY 24 on miibus2 > > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > 1000baseT-FDX, auto > > > ue0: on axe0 > > > ue0: Ethernet address: 00:90:cc:ef:b9:f6 > > > ue0: link state changed to DOWN > > > > > > I manually loaded necessary kernel modules as my kernel does not > > > have any USB device entries. The only regression since I tried USB2 > > > axe(4) was failure of symbol resolving of link_elf in > > > usb2_ethernet.ko module. Attached simple patch seems to fix that. > > > > > > To Hans, > > > I think MODULE_DEPEND should come first before any reference to > > > the module in usb2_ethernet.c. Since mii_phy_probe live in > > > miibus(4) I added it too. > > > > > > > Hans, I managed to track down Hiroharu's issue in axe(4). It seems > > Andrew removed link handling code that ensures correct state of > > established link in r188412. > > I believe we have to revert changes made in axe_cfg_mii_statchg() > > and axe_tick(). I have no idea what was happend in P4, you > > checked in the link handling code I submitted. > > Thanks for finding this Pyun, an unintentional breakage due to the code > reshuffle. Have you committed the fix, I dont see it? > Not yet. I've posted possible fix for axe(4) so let's see how it goes first. ___ 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: USB2: [was: umass not detected correctly, axe not transmitting] AXE problems
On Thu, Feb 12, 2009 at 12:59:13PM +0900, Hiroharu Tamaru wrote: > I've just sent another message before reading this. > > At Thu, 12 Feb 2009 12:42:51 +0900, Pyun YongHyeon wrote: > > On Thu, Feb 12, 2009 at 11:37:23AM +0900, Pyun YongHyeon wrote: > > > On Thu, Feb 12, 2009 at 01:51:47AM +0900, Hiroharu Tamaru wrote: > > > > > > > > At Wed, 11 Feb 2009 16:57:36 +0100, Hans Petter Selasky wrote: > > > > > > > > ugen3.3: at usbus3 > > > > > > > > axe0: on > > > > > > > > usbus3 > > > > > > > > axe0: PHYADDR 0xe0:0x18 > > > > > > > > miibus0: on axe0 > > > > > > > > ciphy0: PHY 24 on miibus0 > > > > > > > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > > > > > > > 1000baseT, > > > > > > > > 1000baseT-FDX, auto ue0: on axe0 > > > > > > > > ue0: Ethernet address: 00:90:cc:xx:xx:xx > > > > > > > > ue0: link state changed to DOWN > > > > > > > > ue0: link state changed to UP > > > > > > > > > > > > > > > > > > > > > > > > > > > Turn on debugging: > > > > > > > > > > > > > > sysctl hw.usb2.axe.debug=15 > > > > > > > > > > > > > > And repeat test. > > > > > > > > > > > > with hw.usb2.axe.debug=15, I have: > > > > > > > > > > > > ugen3.3: at usbus3 (disconnected) > > > > > > pid 3244 (dhclient), uid 65: exited on signal 11 > > > > > > ugen3.3: at usbus3 > > > > > > axe0: on usbus3 > > > > > > axe0: PHYADDR 0xe0:0x18 > > > > > > miibus0: on axe0 > > > > > > ciphy0: PHY 24 on miibus0 > > > > > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > > > > 1000baseT-FDX, auto ue0: on axe0 > > > > > > ue0: Ethernet address: 00:90:cc:f7:bc:2e > > > > > > ue0: link state changed to DOWN > > > > > > ue0: link state changed to UP > > > > > > > > > > > > > > > > > The hardware is a PLANEX GU-1000T ethernet adapter. > > > > > > > > > > > > > > > I have the same USB controller and latest CURRENT works. > > > > > > axe0: on usbus1 > > > axe0: PHYADDR 0xe0:0x18 > > > miibus2: on axe0 > > > ciphy0: PHY 24 on miibus2 > > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > 1000baseT-FDX, auto > > > ue0: on axe0 > > > ue0: Ethernet address: 00:90:cc:ef:b9:f6 > > > ue0: link state changed to DOWN > > > > > > I manually loaded necessary kernel modules as my kernel does not > > > have any USB device entries. The only regression since I tried USB2 > > > axe(4) was failure of symbol resolving of link_elf in > > > usb2_ethernet.ko module. Attached simple patch seems to fix that. > > > > > > To Hans, > > > I think MODULE_DEPEND should come first before any reference to > > > the module in usb2_ethernet.c. Since mii_phy_probe live in > > > miibus(4) I added it too. > > > > > > > Hans, I managed to track down Hiroharu's issue in axe(4). It seems > > Andrew removed link handling code that ensures correct state of > > established link in r188412. > > I believe we have to revert changes made in axe_cfg_mii_statchg() > > and axe_tick(). I have no idea what was happend in P4, you > > checked in the link handling code I submitted. > > Thanks for looking into this. > > So, can I just be waiting for a patch to test, or a CVS > revision of files to revert to? > > Meanwhile, I'll bring the userland to the latest current, as > I mentioned on the other mail. > Ok, try this one after installword. Attached one restores previous link handle code. Note, it was just compile tested. > Hiroharu Index: sys/dev/usb2/ethernet/usb2_ethernet.c === --- sys/dev/usb2/ethernet/usb2_ethernet.c (revision 188507) +++ sys/dev/usb2/ethernet/usb2_ethernet.c (working copy) @@ -43,6 +43,9 @@ #defineUE_UNLOCK(_ue) mtx_unlock((_ue)->ue_mtx) #defineUE_LOCK_ASSERT(_ue, t) mtx_assert((_ue)->ue_mtx, t) +MODULE_DEPEND(usb2_ethernet, usb2_core, 1,
Re: USB2: [was: umass not detected correctly, axe not transmitting] AXE problems
On Thu, Feb 12, 2009 at 11:37:23AM +0900, Pyun YongHyeon wrote: > On Thu, Feb 12, 2009 at 01:51:47AM +0900, Hiroharu Tamaru wrote: > > > > At Wed, 11 Feb 2009 16:57:36 +0100, Hans Petter Selasky wrote: > > > > > > ugen3.3: at usbus3 > > > > > > axe0: on usbus3 > > > > > > axe0: PHYADDR 0xe0:0x18 > > > > > > miibus0: on axe0 > > > > > > ciphy0: PHY 24 on miibus0 > > > > > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > > > > 1000baseT-FDX, auto ue0: on axe0 > > > > > > ue0: Ethernet address: 00:90:cc:xx:xx:xx > > > > > > ue0: link state changed to DOWN > > > > > > ue0: link state changed to UP > > > > > > > > > > > > > > > > > > > Turn on debugging: > > > > > > > > > > sysctl hw.usb2.axe.debug=15 > > > > > > > > > > And repeat test. > > > > > > > > with hw.usb2.axe.debug=15, I have: > > > > > > > > ugen3.3: at usbus3 (disconnected) > > > > pid 3244 (dhclient), uid 65: exited on signal 11 > > > > ugen3.3: at usbus3 > > > > axe0: on usbus3 > > > > axe0: PHYADDR 0xe0:0x18 > > > > miibus0: on axe0 > > > > ciphy0: PHY 24 on miibus0 > > > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > > 1000baseT-FDX, auto ue0: on axe0 > > > > ue0: Ethernet address: 00:90:cc:f7:bc:2e > > > > ue0: link state changed to DOWN > > > > ue0: link state changed to UP > > > > > > > > > > > The hardware is a PLANEX GU-1000T ethernet adapter. > > > > > > > I have the same USB controller and latest CURRENT works. > > axe0: on usbus1 > axe0: PHYADDR 0xe0:0x18 > miibus2: on axe0 > ciphy0: PHY 24 on miibus2 > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > ue0: on axe0 > ue0: Ethernet address: 00:90:cc:ef:b9:f6 > ue0: link state changed to DOWN > > I manually loaded necessary kernel modules as my kernel does not > have any USB device entries. The only regression since I tried USB2 > axe(4) was failure of symbol resolving of link_elf in > usb2_ethernet.ko module. Attached simple patch seems to fix that. > > To Hans, > I think MODULE_DEPEND should come first before any reference to > the module in usb2_ethernet.c. Since mii_phy_probe live in > miibus(4) I added it too. > Hans, I managed to track down Hiroharu's issue in axe(4). It seems Andrew removed link handling code that ensures correct state of established link in r188412. I believe we have to revert changes made in axe_cfg_mii_statchg() and axe_tick(). I have no idea what was happend in P4, you checked in the link handling code I submitted. ___ 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: USB2: [was: umass not detected correctly, axe not transmitting] AXE problems
On Thu, Feb 12, 2009 at 01:51:47AM +0900, Hiroharu Tamaru wrote: > > At Wed, 11 Feb 2009 16:57:36 +0100, Hans Petter Selasky wrote: > > > > > ugen3.3: at usbus3 > > > > > axe0: on usbus3 > > > > > axe0: PHYADDR 0xe0:0x18 > > > > > miibus0: on axe0 > > > > > ciphy0: PHY 24 on miibus0 > > > > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > > > 1000baseT-FDX, auto ue0: on axe0 > > > > > ue0: Ethernet address: 00:90:cc:xx:xx:xx > > > > > ue0: link state changed to DOWN > > > > > ue0: link state changed to UP > > > > > > > > > > > > > > > Turn on debugging: > > > > > > > > sysctl hw.usb2.axe.debug=15 > > > > > > > > And repeat test. > > > > > > with hw.usb2.axe.debug=15, I have: > > > > > > ugen3.3: at usbus3 (disconnected) > > > pid 3244 (dhclient), uid 65: exited on signal 11 > > > ugen3.3: at usbus3 > > > axe0: on usbus3 > > > axe0: PHYADDR 0xe0:0x18 > > > miibus0: on axe0 > > > ciphy0: PHY 24 on miibus0 > > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > 1000baseT-FDX, auto ue0: on axe0 > > > ue0: Ethernet address: 00:90:cc:f7:bc:2e > > > ue0: link state changed to DOWN > > > ue0: link state changed to UP > > > > > > > > The hardware is a PLANEX GU-1000T ethernet adapter. > > > I have the same USB controller and latest CURRENT works. axe0: on usbus1 axe0: PHYADDR 0xe0:0x18 miibus2: on axe0 ciphy0: PHY 24 on miibus2 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: on axe0 ue0: Ethernet address: 00:90:cc:ef:b9:f6 ue0: link state changed to DOWN I manually loaded necessary kernel modules as my kernel does not have any USB device entries. The only regression since I tried USB2 axe(4) was failure of symbol resolving of link_elf in usb2_ethernet.ko module. Attached simple patch seems to fix that. To Hans, I think MODULE_DEPEND should come first before any reference to the module in usb2_ethernet.c. Since mii_phy_probe live in miibus(4) I added it too. > > > What can I do now? > > Hiroharu, if you unplug/replug UTP cable, does it make any difference? > > Does netstat indicate any receive errors on the AXE interface? > > > > netstat -i > > Nope. > > NameMtu Network Address Ipkts IerrsOpkts Oerrs > Coll > ... > ue01500 00:90:cc:f7:bc:2e 52 0 12 0 > 0 > ue01500 192.168.1.0 192.168.1.3 0 -4 - > - > > The latter line is the result of statically asigning an address, > and then 'ping -n 192.168.1.1'ing for four seconds. > > > Maybe "Pyun YongHyeon" should have a look at this. > > > > And you are running the latest current? > > I updated to -current as of about an hour or two ago. > PS. Please CC to me I'm not subscribed to the list. ___ 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"
