Re: suggestion to change wording in man 4 tpmr
On 23 Aug 23:24, Jason McIntyre wrote: > On Sun, Aug 23, 2020 at 10:16:19PM +, Uwe Werler wrote: > > Hi, > > > > I suggest to change the wording in man 4 tpmr to avoid repetition. > > > > Uwe > > > > Index: tpmr.4 > > === > > RCS file: /cvs/src/share/man/man4/tpmr.4,v > > retrieving revision 1.7 > > diff -u -p -r1.7 tpmr.4 > > --- tpmr.4 5 Aug 2020 14:55:40 - 1.7 > > +++ tpmr.4 23 Aug 2020 22:11:29 - > > @@ -44,7 +44,7 @@ configuration file for > > Other forms of Ethernet bridging are available using the > > .Xr bridge 4 > > driver. > > -Other forms of aggregation of Ethernet interfaces are available > > +Link aggregation of Ethernet interfaces can be achieved > > using the > > .Xr aggr 4 > > and > > > > hi. > > your diff changes the meaning: currently the page suggests tpmr is capable of > (a form of) link aggregation, and aggr and trunk can be used as alternatives. > > with your changes, it suggests tpmr is not capable of (a form of) link > aggregation. > > i don;t know whether that's correct or not. but the diff does not just > "avoid repitition". > > jmc Hi Jason, mmh, now I'm confused because logically that would mean that a bridge is link aggregation. My understanding is that link aggregation is a technology a bridge/switch can be capable of but mainly forwards ethernet frames between interfaces? Uwe
Re: some typos in man 4 tpmr
On 23 Aug 23:21, Stuart Henderson wrote: > On 2020/08/23 21:57, Uwe Werler wrote: > > Hi, > > > > spotted some typos: > > > > Index: tpmr.4 > > === > > RCS file: /cvs/src/share/man/man4/tpmr.4,v > > retrieving revision 1.7 > > diff -u -p -r1.7 tpmr.4 > > --- tpmr.4 5 Aug 2020 14:55:40 - 1.7 > > +++ tpmr.4 23 Aug 2020 21:29:27 - > > @@ -25,13 +25,13 @@ > > .Sh DESCRIPTION > > The > > .Nm > > -driver implements an 802.1Q (originally 802.1aj) Two-Port MAC Relay > > +driver implements a 802.1Q (originally 802.1aj) Two-Port MAC Relay > > 8 is pronounced eight which starts with a vowel sound -> "an" is correct Ok, thanks for the explanation. Because I was unsure I asked a native speaker who said an a would in his opinion correct... > > > (TPMR). > > A TPMR is a simplified Ethernet bridge that provides a subset of > > the functionality as found in > > .Xr bridge 4 . > > -A TPMR has exactly two member ports, and unconditionally relays > > -Ethernet packets between the them. > > +A TPMR has exactly two member ports and unconditionally relays > > +Ethernet packets between them. > > "the them" -> "them" is correct of course, I think it reads better with the > comma though I understand. Comma rules in english are kinda confusing... Uwe
suggestion to change wording in man 4 tpmr
Hi, I suggest to change the wording in man 4 tpmr to avoid repetition. Uwe Index: tpmr.4 === RCS file: /cvs/src/share/man/man4/tpmr.4,v retrieving revision 1.7 diff -u -p -r1.7 tpmr.4 --- tpmr.4 5 Aug 2020 14:55:40 - 1.7 +++ tpmr.4 23 Aug 2020 22:11:29 - @@ -44,7 +44,7 @@ configuration file for Other forms of Ethernet bridging are available using the .Xr bridge 4 driver. -Other forms of aggregation of Ethernet interfaces are available +Link aggregation of Ethernet interfaces can be achieved using the .Xr aggr 4 and
some typos in man 4 tpmr
Hi, spotted some typos: Index: tpmr.4 === RCS file: /cvs/src/share/man/man4/tpmr.4,v retrieving revision 1.7 diff -u -p -r1.7 tpmr.4 --- tpmr.4 5 Aug 2020 14:55:40 - 1.7 +++ tpmr.4 23 Aug 2020 21:29:27 - @@ -25,13 +25,13 @@ .Sh DESCRIPTION The .Nm -driver implements an 802.1Q (originally 802.1aj) Two-Port MAC Relay +driver implements a 802.1Q (originally 802.1aj) Two-Port MAC Relay (TPMR). A TPMR is a simplified Ethernet bridge that provides a subset of the functionality as found in .Xr bridge 4 . -A TPMR has exactly two member ports, and unconditionally relays -Ethernet packets between the them. +A TPMR has exactly two member ports and unconditionally relays +Ethernet packets between them. .Pp .Nm interfaces can be created at runtime using the cvs server: I know nothing about tpmr.4.orig -- With kind regards / Með bestu kveðju / Mit freundlichen Grüßen Uwe Werler
Re: suggestion to change wording in man 4 tpmr
On Sun, Aug 23, 2020 at 11:24:46PM +0100, Jason McIntyre wrote: > On Sun, Aug 23, 2020 at 10:16:19PM +, Uwe Werler wrote: > > Hi, > > > > I suggest to change the wording in man 4 tpmr to avoid repetition. > > > > Uwe > > > > Index: tpmr.4 > > === > > RCS file: /cvs/src/share/man/man4/tpmr.4,v > > retrieving revision 1.7 > > diff -u -p -r1.7 tpmr.4 > > --- tpmr.4 5 Aug 2020 14:55:40 - 1.7 > > +++ tpmr.4 23 Aug 2020 22:11:29 - > > @@ -44,7 +44,7 @@ configuration file for > > Other forms of Ethernet bridging are available using the > > .Xr bridge 4 > > driver. > > -Other forms of aggregation of Ethernet interfaces are available > > +Link aggregation of Ethernet interfaces can be achieved > > using the > > .Xr aggr 4 > > and > > > > hi. > > your diff changes the meaning: currently the page suggests tpmr is capable of > (a form of) link aggregation, and aggr and trunk can be used as alternatives. > > with your changes, it suggests tpmr is not capable of (a form of) link > aggregation. > > i don;t know whether that's correct or not. but the diff does not just > "avoid repitition". That diff reads OK, tpmr(4) is really a bridge like bridge(4) or switch(4), and not an aggregating driver like aggr(4) or trunk(4), hence "Other forms of Ethernat bridging ..." correctly implies that tpmr does indeed ethernet bridging, "Other forms of aggregation ..." implies the same way, but that is misleading.
Re: suggestion to change wording in man 4 tpmr
On Sun, Aug 23, 2020 at 10:16:19PM +, Uwe Werler wrote: > Hi, > > I suggest to change the wording in man 4 tpmr to avoid repetition. > > Uwe > > Index: tpmr.4 > === > RCS file: /cvs/src/share/man/man4/tpmr.4,v > retrieving revision 1.7 > diff -u -p -r1.7 tpmr.4 > --- tpmr.4 5 Aug 2020 14:55:40 - 1.7 > +++ tpmr.4 23 Aug 2020 22:11:29 - > @@ -44,7 +44,7 @@ configuration file for > Other forms of Ethernet bridging are available using the > .Xr bridge 4 > driver. > -Other forms of aggregation of Ethernet interfaces are available > +Link aggregation of Ethernet interfaces can be achieved > using the > .Xr aggr 4 > and > hi. your diff changes the meaning: currently the page suggests tpmr is capable of (a form of) link aggregation, and aggr and trunk can be used as alternatives. with your changes, it suggests tpmr is not capable of (a form of) link aggregation. i don;t know whether that's correct or not. but the diff does not just "avoid repitition". jmc
Re: some typos in man 4 tpmr
On 2020/08/23 21:57, Uwe Werler wrote: > Hi, > > spotted some typos: > > Index: tpmr.4 > === > RCS file: /cvs/src/share/man/man4/tpmr.4,v > retrieving revision 1.7 > diff -u -p -r1.7 tpmr.4 > --- tpmr.4 5 Aug 2020 14:55:40 - 1.7 > +++ tpmr.4 23 Aug 2020 21:29:27 - > @@ -25,13 +25,13 @@ > .Sh DESCRIPTION > The > .Nm > -driver implements an 802.1Q (originally 802.1aj) Two-Port MAC Relay > +driver implements a 802.1Q (originally 802.1aj) Two-Port MAC Relay 8 is pronounced eight which starts with a vowel sound -> "an" is correct > (TPMR). > A TPMR is a simplified Ethernet bridge that provides a subset of > the functionality as found in > .Xr bridge 4 . > -A TPMR has exactly two member ports, and unconditionally relays > -Ethernet packets between the them. > +A TPMR has exactly two member ports and unconditionally relays > +Ethernet packets between them. "the them" -> "them" is correct of course, I think it reads better with the comma though > .Pp > .Nm > interfaces can be created at runtime using the > cvs server: I know nothing about tpmr.4.orig > > -- > > With kind regards / Með bestu kveðju / Mit freundlichen Grüßen > > Uwe Werler >
Re: some typos in man 4 tpmr
On Sun, Aug 23, 2020 at 09:57:09PM +, Uwe Werler wrote: > Hi, > > spotted some typos: > hi. > Index: tpmr.4 > === > RCS file: /cvs/src/share/man/man4/tpmr.4,v > retrieving revision 1.7 > diff -u -p -r1.7 tpmr.4 > --- tpmr.4 5 Aug 2020 14:55:40 - 1.7 > +++ tpmr.4 23 Aug 2020 21:29:27 - > @@ -25,13 +25,13 @@ > .Sh DESCRIPTION > The > .Nm > -driver implements an 802.1Q (originally 802.1aj) Two-Port MAC Relay > +driver implements a 802.1Q (originally 802.1aj) Two-Port MAC Relay "an 8" is correct > (TPMR). > A TPMR is a simplified Ethernet bridge that provides a subset of > the functionality as found in > .Xr bridge 4 . > -A TPMR has exactly two member ports, and unconditionally relays it reads better with the comma, i'd say > -Ethernet packets between the them. but i fixed this one. thanks, jmc > +A TPMR has exactly two member ports and unconditionally relays > +Ethernet packets between them. > .Pp > .Nm > interfaces can be created at runtime using the > cvs server: I know nothing about tpmr.4.orig > > -- > > With kind regards / Me? bestu kve?ju / Mit freundlichen Gr??en > > Uwe Werler >
Re: uaudio device works on usb2 port; fails on usb3 port
On 21/08/20(Fri) 11:46, Marcus Glocker wrote: > On Wed, 19 Aug 2020 20:31:05 +0200 > Marcus Glocker wrote: > > > On Wed, Aug 19, 2020 at 01:21:35PM +0200, Marcus Glocker wrote: > > > > > On Wed, 19 Aug 2020 12:02:23 +0200 > > > Martin Pieuchot wrote: > > > > > > > On 18/08/20(Tue) 18:53, Marcus Glocker wrote: > > > > > On Wed, 12 Aug 2020 21:39:15 +0200 > > > > > Marcus Glocker wrote: > > > > > > > > > > > jmc was so nice to send me his trouble device over to do some > > > > > > further investigations. Just some updates on what I've > > > > > > noticed today: > > > > > > > > > > > > - The issue isn't specific to xhci(4). I also see the same > > > > > > issue on some of my ehci(4) machines when attaching this > > > > > > device. > > > > > > > > > > > > - It seems like the device gets in to an 'corrupted state' > > > > > > after running a couple of control transfer against it. > > > > > > Initially they work fine, with smaller and larger transfer > > > > > > sizes, and at one point the device hangs up and doesn't > > > > > > recover until re-attaching it. While on some ehci(4) machines > > > > > > the uhidev(4) attach works fine, after running lsusb against > > > > > > the device, I see transfer errors coming up again; On > > > > > > xhci(4) namely XHCI_CODE_TXERR. > > > > > > > > > > > > - Attaching an USB 2.0 hub doesn't make any difference, no > > > > > > matter if attached to an xhci(4) or an ehci(4) controller. > > > > > > > > > > > > Not sure what is going wrong with this little beast ... > > > > > > > > > > OK, I give up :-) Following my summary report. > > > > > > > > > > This device seems to have issues with two control request types: > > > > > > > > > > - UR_GET_STATUS, not called for this device from the kernel > > > > > in the default code path. But e.g. 'lsusb -v' will call it. > > > > > > > > > > - UR_SET_IDLE, as called in uhidev_attach(). > > > > > > > > > > UR_GET_STATUS will stall the device for good on *all* controller > > > > > drivers. > > > > > > > > Does this also happen when the device attaches as ugen(4)? If yes > > > > that would rules out concurrency issues that might happen when > > > > using lsusb(1) while other transfers are in fly. To test you > > > > need to disable the current attaching driver in ukc. > > > > > > Yes, it does also happen when attaching the device to ugen(4). > > > But honestly, I was playing around yesterday evening a bit further > > > with this device, and I noticed that the device also stalls with > > > lsusb when I remove the get status and get report request in the > > > lsusb code. > > > > > > Therefore I need to correct my statement, saying instead that *some* > > > request in lsusb makes the device stall as well. What I just found > > > in the lsusb ChangeLog: > > > > > > Added (somewhat dummy) Set_Protocol and Set_Idle requests to > > > stream dumping setup. > > > > > > I'll try to confirm if the stall really happens there. At least > > > that would be in line with our findings in the kernel. > > > > OK, I've tracked the two lsusb requests down finally which also stall > > this device beside our set idle call in the kernel. > > > > UR_GET_DESCRIPTOR, UDESC_DEVICE_QUALIFIER: > > > > ret = usb_control_msg(fd, LIBUSB_ENDPOINT_IN | > > LIBUSB_REQUEST_TYPE_STANDARD | LIBUSB_RECIPIENT_DEVICE, > > LIBUSB_REQUEST_GET_DESCRIPTOR, > > USB_DT_DEBUG << 8, 0, > > buf, sizeof buf, CTRL_TIMEOUT); > > > > UR_GET_DESCRIPTOR, UDESC_DEBUG: > > > > ret = usb_control_msg(fd, LIBUSB_ENDPOINT_IN | > > LIBUSB_REQUEST_TYPE_STANDARD | LIBUSB_RECIPIENT_DEVICE, > > LIBUSB_REQUEST_GET_DESCRIPTOR, > > USB_DT_DEBUG << 8, 0, > > buf, sizeof buf, CTRL_TIMEOUT); > > > > When you comment those two control requests out, lsusb -v runs > > through. > > > > If I wouldn't know better, I would say that this device isn't able to > > handle UR_SET_IDLE, UDESC_DEVICE_QUALIFIER, and UDESC_DEBUG requests. > > But what still puzzles me is why the UR_SET_IDLE request works on > > ehci(4). Would you have any explanation for that? > > > > > > > UR_SET_IDLE works only on ehci(4) - Don't ask me why. > > > > > On all the other controller drivers the following UR_GET_REPORT > > > > > request will fail, stalling the device as well. I tried all > > > > > kind of things to get the UR_SET_IDLE request working on > > > > > xhci(4), but without any luck. > > > > > > > > Does the device respond to GET_IDLE? > > > > > > No, same behaviour as for SET_IDLE, returns with USBD_STALLED. > > > > > > > It it a timing problem? How much time does the device need to be > > > > idle? Does introducing a delay before and/or after usbd_set_idle() > > > > change the behavior? > > > > > > I already tried 100ms delay before and after set idle, no change. > > > > > > > Did you try passing a non-0 duration parameter to the SET_IDLE > > > > command? > > > > > > Yes, I also already tried
