Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Thu, November 18, 2010 23:38, Pyun YongHyeon wrote: > On Thu, Nov 18, 2010 at 10:40:10PM -0200, Nenhum_de_Nos wrote: >> >> On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: >> > On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: >> >> >> >> On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: >> >> > On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: >> >> >> >> >> >> On Thu, November 18, 2010 13:10, Derrick Brashear wrote: >> >> >> > The following reply was made to PR usb/140883; it has been noted >> by >> >> >> GNATS. >> >> >> > >> >> >> > From: Derrick Brashear >> >> >> > 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. I downloaded again from above links and are the same as the last: valfenda# md5 if_axe* MD5 (if_axe.c) = 388b7aa84f0d2471f8b144033103618b MD5 (if_axe.c.original) = c528c7cb5eb964a792d4c14dfaed47cf MD5 (if_axe.c.v1) = 388b7aa84f0d2471f8b144033103618b MD5 (if_axereg.h) = 10f85490cab59b8e40de261fd7ad81a5 MD5 (if_axereg.h.original) = 46f37d0f02a3c09463ceec58b743c6ce MD5 (if_axereg.h.v1) = 10f85490cab59b8e40de261fd7ad81a5 .original are files from 8-stable (via csup) .v1 are the files from http://people.freebsd.org/~yongari/axe/ downloaded when the fist test using those files were made. regular .c files were downloaded now when I read this mail. did you uploaded some new version in http://people.freebsd.org/~yongari/axe/ ? or I didn't got it ? :) should this modified version be a good test to fast ethernet axe nics ? my linksys USB200M failed when in bridge after some time of use :(
Re: usb/141212: commit references a PR
The following reply was made to PR usb/141212; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: usb/141212: commit references a PR Date: Fri, 19 Nov 2010 01:43:14 + (UTC) Author: thompsa Date: Fri Nov 19 01:43:08 2010 New Revision: 215494 URL: http://svn.freebsd.org/changeset/base/215494 Log: MFC r212128 Silence debug error by default. PR: usb/141212 Modified: stable/8/sys/dev/usb/input/ukbd.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/xen/xenpci/ (props changed) Modified: stable/8/sys/dev/usb/input/ukbd.c == --- stable/8/sys/dev/usb/input/ukbd.c Fri Nov 19 01:42:13 2010 (r215493) +++ stable/8/sys/dev/usb/input/ukbd.c Fri Nov 19 01:43:08 2010 (r215494) @@ -727,7 +727,7 @@ ukbd_set_leds_callback(struct usb_xfer * break; default:/* Error */ - DPRINTFN(0, "error=%s\n", usbd_errstr(error)); + DPRINTFN(1, "error=%s\n", usbd_errstr(error)); break; } } ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" ___ 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/135575: commit references a PR
The following reply was made to PR usb/135575; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: usb/135575: commit references a PR
Date: Fri, 19 Nov 2010 01:36:06 + (UTC)
Author: thompsa
Date: Fri Nov 19 01:35:57 2010
New Revision: 215488
URL: http://svn.freebsd.org/changeset/base/215488
Log:
MFC r210469
Give a name to the HTC Wizard Smartphone
PR: usb/135575
Modified:
stable/8/sys/dev/usb/serial/uipaq.c
stable/8/sys/dev/usb/usbdevs
Directory Properties:
stable/8/sys/ (props changed)
stable/8/sys/amd64/include/xen/ (props changed)
stable/8/sys/cddl/contrib/opensolaris/ (props changed)
stable/8/sys/contrib/dev/acpica/ (props changed)
stable/8/sys/contrib/pf/ (props changed)
stable/8/sys/dev/xen/xenpci/ (props changed)
Modified: stable/8/sys/dev/usb/serial/uipaq.c
==
--- stable/8/sys/dev/usb/serial/uipaq.cFri Nov 19 01:35:14 2010
(r215487)
+++ stable/8/sys/dev/usb/serial/uipaq.cFri Nov 19 01:35:57 2010
(r215488)
@@ -690,14 +690,14 @@ static const struct usb_device_id uipaq_
{USB_VPI(USB_VENDOR_HTC, 0x0a9e, 0)},
/* SmartPhone USB Sync */
{USB_VPI(USB_VENDOR_HTC, 0x0a9f, 0)},
- /* "High Tech Computer Corp" */
- {USB_VPI(USB_VENDOR_HTC, 0x0bce, 0)},
/**/
{USB_VPI(USB_VENDOR_HTC, USB_PRODUCT_HTC_PPC6700MODEM, 0)},
/**/
{USB_VPI(USB_VENDOR_HTC, USB_PRODUCT_HTC_SMARTPHONE, 0)},
/**/
{USB_VPI(USB_VENDOR_HTC, USB_PRODUCT_HTC_WINMOBILE, 0)},
+ /* High Tech Computer Wizard Smartphone */
+ {USB_VPI(USB_VENDOR_HTC, USB_PRODUCT_HTC_WIZARD, 0)},
/* JVC USB Sync */
{USB_VPI(USB_VENDOR_JVC, 0x3011, 0)},
/* JVC USB Sync */
Modified: stable/8/sys/dev/usb/usbdevs
==
--- stable/8/sys/dev/usb/usbdevs Fri Nov 19 01:35:14 2010
(r215487)
+++ stable/8/sys/dev/usb/usbdevs Fri Nov 19 01:35:57 2010
(r215488)
@@ -1761,6 +1761,7 @@ product HP HS23000x1e1d hs2300 HSDPA
product HTC WINMOBILE 0x00ce HTC USB Sync
product HTC PPC6700MODEM 0x00cf PPC6700 Modem
product HTC SMARTPHONE0x0a51 SmartPhone USB Sync
+product HTC WIZARD0x0bce HTC Wizard USB Sync
/* HUAWEI products */
product HUAWEI MOBILE 0x1001 Huawei Mobile
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Thu, 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. > > >> 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 chan
Re: usb/119981: commit references a PR
The following reply was made to PR usb/119981; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: usb/119981: commit references a PR Date: Fri, 19 Nov 2010 01:24:41 + (UTC) Author: thompsa Date: Fri Nov 19 01:24:36 2010 New Revision: 215479 URL: http://svn.freebsd.org/changeset/base/215479 Log: MFC r212980 Add new device ids. Buffalo (Melco Inc.) LUA3-U2-AGT Logitec LAN-GTJ/U2A(usb/119981) PR: usb/119981 Modified: Directory Properties: stable/8/share/man/man4/ (props changed) stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/xen/xenpci/ (props changed) ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: > On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: >> >> On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: >> > On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: >> >> >> >> On Thu, November 18, 2010 13:10, Derrick Brashear wrote: >> >> > The following reply was made to PR usb/140883; it has been noted by >> >> GNATS. >> >> > >> >> > From: Derrick Brashear >> >> > 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 >> 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 try stable/8 and > use axe(4) I posted. sorry, forgot to add: uname -a FreeBSD valfenda.apartnet 8.1-STABLE FreeBSD 8.1-STABLE #2: Fri Nov 5 01:52:06 BRT 2010 r...@valfenda.apartnet:/usr/obj/usr/src/sys/valfenda i386 and this is using that axe(4) you posted :) just got a litt
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 try stable/8 and use axe(4) I posted. > so I get this: > > ping 192.168.1.2 > PING 192.168.1.2 (192.168.1.2): 56 data bytes > ping: sendto: No route to host > 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.912 ms > 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.842 ms > ping: sendto: No route to host > 64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=1.015 ms > 64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=0.774 ms > 64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=0.789 ms > 64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=0.851 ms > 64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=0.915 ms > ^C > --- 192.168.1.2 ping statistics --- > 11
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: > On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: >> >> On Thu, November 18, 2010 13:10, Derrick Brashear wrote: >> > The following reply was made to PR usb/140883; it has been noted by >> GNATS. >> > >> > From: Derrick Brashear >> > 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 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). so I get this: ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes ping: sendto: No route to host 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.912 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.842 ms ping: sendto: No route to host 64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=1.015 ms 64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=0.774 ms 64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=0.789 ms 64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=0.851 ms 64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=0.915 ms ^C --- 192.168.1.2 ping statistics --- 11 packets transmitted, 7 packets received, 36.4% packet loss round-trip min/avg/max/stddev = 0.774/0.871/1.015/0.077 ms on local network. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/141680: [uath] [usb8] Netgear WG111T not working with uath driver
Synopsis: [uath] [usb8] Netgear WG111T not working with uath driver State-Changed-From-To: open->feedback State-Changed-By: arundel State-Changed-When: Thu Nov 18 22:28:38 UTC 2010 State-Changed-Why: Please note that feedback has been requested. http://www.freebsd.org/cgi/query-pr.cgi?pr=141680 ___ 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/101775: [usb67] [libusbhid] [patch] possible error in report descriptor parsing
Old Synopsis: [usb67] [usb8] [libusbhid] [patch] possible error in report descriptor parsing New Synopsis: [usb67] [libusbhid] [patch] possible error in report descriptor parsing State-Changed-From-To: open->patched State-Changed-By: arundel State-Changed-When: Thu Nov 18 22:20:22 UTC 2010 State-Changed-Why: Fixed in HEAD (101775) and MFC'ed to 8.x (208262). http://www.freebsd.org/cgi/query-pr.cgi?pr=101775 ___ 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/135200: SAMSUNG i740 usb mass: Synchronize cache failed, status == 0x39, scsi status == 0x0
Synopsis: SAMSUNG i740 usb mass: Synchronize cache failed, status == 0x39, scsi status == 0x0 State-Changed-From-To: open->feedback State-Changed-By: arundel State-Changed-When: Thu Nov 18 21:50:32 UTC 2010 State-Changed-Why: Did the quirk merely get rid of the warning, or did you have actual issues with this device? If so please post the actual failures. The point i ask is, because adding a quirk requires an actual problem with the device. If you're merely seeing warnings being issued to the console that is not a sufficient reason to add a quirk (see sys/cam/README.quirks). http://www.freebsd.org/cgi/query-pr.cgi?pr=135200 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Thu, 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: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Thu, November 18, 2010 13:10, Derrick Brashear wrote: > The following reply was made to PR usb/140883; it has been noted by GNATS. > > From: Derrick Brashear > To: bug-follo...@freebsd.org, sub.m...@gmail.com > Cc: > Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after > short > period of traffic > Date: Thu, 18 Nov 2010 09:36:50 -0500 > > Pyun has provided an updated driver which avoids several issues > including using a too-large transmit buffer (the chipset claims only > 8k) but none of the fixes worked until he disabled frame combining for > transmit. With only a single packet being sent per frame (as was the > case in FreeBSD 7, apparently) seems to make the issue go away. None > of the cases I could use to reproduce the issue now happen. > > -- > Derrick is this already in 8-stable ? I have a couple of axe(4) based nic's they're not ok on 8-stable. I've talked to Pyun before, and that time seemed do solve the issue (with gigabit belkin axe based) but now I can't get them to work anymore. even fast ethernet linksys axe are just dying when in a bridge (switched to OpenBSD to have it working). how ca I try this to help ? thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
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 ___ 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/151851: libusb(3) libusb_control_transfer() return value is incorrect
http://svn.freebsd.org/changeset/base/215450 --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"
