[Bug 237666] repeated messages of "uhub_reattach_port: giving up port reset - device vanished"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 --- Comment #114 from Ihor Antonov --- Yes, I can reproduce the bug by unplugging my external monitor. Monitor is connected via USB-C cable. As soon as I unplug it I see this message in dmesg appearing roughly every second. uhub_reattach_port: giving up port reset - device vanished If I plug the monitor back - the message stops. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
[Bug 237666] repeated messages of "uhub_reattach_port: giving up port reset - device vanished"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 Ihor Antonov changed: What|Removed |Added CC||ihor@antonovs.family --- Comment #113 from Ihor Antonov --- The bug is alive. Just had it today on FreeBSD 13.0-CURRENT r362882 ThinkPad T470 The exact circumstances under which it happened are not clear. I noticed it when I detached external USB-C monitor and USB2 keyboard and took my laptop to another room. I will try to figure out the exact sequence to reproduce the bug. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Thank you guys for trust and hints, I will be able to get into this around August, sorry, I am a bit overworked at the moment, I have some backlog waiting for FreeBSD already :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Fri, 3 Jul 2020 11:15:01 +0200 Hans Petter Selasky wrote: > Hi, > > On 2020-07-03 11:06, Tomasz CEDRO wrote: > > +1 for user enabled actions like usb reset and kernel driver detach:-) > > maybe based on a sysctl like usermount, i.e. usb_allow_user_device_reset > > and usb_allow_user_kernel_driver_detach..? > > > > One would allow user to reset a usb device. This is sometimes required to > > restore device or change its configration. > > > > Second would allow user for example to unload ucom driver that is attached > > to a device which does not seem possible right now and causes problem with > > i.e. pyOCD / some debug probes. > > Currently we use PRIV_DRIVER in the USB stack. Not sure how a user gets > PRIV_DRIVER rights. > With a few exceptions it looks like root permissions are required per default. The code is in /usr/src/sys/kern/kern_priv.c. > Tomasz: Feel free to suggest a patch for this after testing. > -- Gary Jennejohn ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
pt., 3 lip 2020, 11:15 użytkownik Hans Petter Selasky napisał: > > Second would allow user for example to unload ucom driver that is > attached > > to a device which does not seem possible right now and causes problem > with > > i.e. pyOCD / some debug probes. > > Currently we use PRIV_DRIVER in the USB stack. Not sure how a user gets > PRIV_DRIVER rights. > > Tomasz: Feel free to suggest a patch for this after testing. > Thank You HPS :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Hi, On 2020-07-03 11:06, Tomasz CEDRO wrote: +1 for user enabled actions like usb reset and kernel driver detach:-) maybe based on a sysctl like usermount, i.e. usb_allow_user_device_reset and usb_allow_user_kernel_driver_detach..? One would allow user to reset a usb device. This is sometimes required to restore device or change its configration. Second would allow user for example to unload ucom driver that is attached to a device which does not seem possible right now and causes problem with i.e. pyOCD / some debug probes. Currently we use PRIV_DRIVER in the USB stack. Not sure how a user gets PRIV_DRIVER rights. Tomasz: Feel free to suggest a patch for this after testing. --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
pt., 3 lip 2020, 10:10 użytkownik Hans Petter Selasky napisał: > > I see three possible approaches currently: > > > > 1. Allowing a USB reset if the user has access to /dev/ugenX.Y (might > > allow users to mess with kernel's operation on a device, unless the > > problem exists anyway, see my questions above). > > > > 2. Allowing a USB reset if the user has access to /dev/ugenX.Y and > > there are other prerequirements fulfilled (e.g. a sysctl setting to > > enable it globally, which might not be fine-graded enough, or the > > requirement that there is currently no kernel driver attached, or a > > combination thereof). > > > > 3. Providing a way to grant "reset permissions" on a per-device basis > > (might be overkill, and not really needed). > > > > Maybe you're right we should allow this for non-root aswell. I need to > think about it! > +1 for user enabled actions like usb reset and kernel driver detach :-) maybe based on a sysctl like usermount, i.e. usb_allow_user_device_reset and usb_allow_user_kernel_driver_detach..? One would allow user to reset a usb device. This is sometimes required to restore device or change its configration. Second would allow user for example to unload ucom driver that is attached to a device which does not seem possible right now and causes problem with i.e. pyOCD / some debug probes. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Hi Jan, On 2020-07-03 09:51, Jan Behrens wrote: Yes, and we have one or two firmware loading utilities in base still using them. Except that /dev/usb/X.Y.0 (which is linked by /dev/ugenX.Y) controls access rights to the device through libusb, right? Yes, that is correct. Yes, but opening /dev/ugenX.Y doesn't mean that kernel device drivers are detached from this device. Can/does a kernel device driver restrict what a user can do with the device when the kernel driver is active? Or does access to the device always enable a user to mess up things badly? The kernel device driver can not restrict what the user-space driver can do. Yes, user-space can mess up the device totally. User-space drivers are requested to create a uniq PID file, to avoid clashes with multiple drivers on the same interface and may use libusb_claim_interface() to tell the kernel to detach any drivers on that specific interface. If the kernel refuses to give up control, is the user-space program denied access? If yes, I can generally understand why you don't want a USB reset to be initiated by a user-space program (at least as long there are kernel drivers attached). The FreeBSD USB stack has no concept of exclusive access to USB endpoints. Simply if both kernel and user-space attach to the same device, user-space will receive half of the USB packets and the kernel the other half. If you for example load the LimeSDR two times for the same ugenX.Y device, then the interface communication might stop working, even though no error is reported. Thus the lock of user-space drivers is only advisory and not enforced? Right, it is not enforced. How about if a kernel driver uses the device? Can/does the kernel block out a user-space driver that would mess with the kernel's operation on the device? No, it is all transparent. Kernel drivers cannot block user-space, but user-space can detach kernel-space. That's all. I see three possible approaches currently: 1. Allowing a USB reset if the user has access to /dev/ugenX.Y (might allow users to mess with kernel's operation on a device, unless the problem exists anyway, see my questions above). 2. Allowing a USB reset if the user has access to /dev/ugenX.Y and there are other prerequirements fulfilled (e.g. a sysctl setting to enable it globally, which might not be fine-graded enough, or the requirement that there is currently no kernel driver attached, or a combination thereof). 3. Providing a way to grant "reset permissions" on a per-device basis (might be overkill, and not really needed). Maybe you're right we should allow this for non-root aswell. I need to think about it! --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Hello Hans, Thanks for your responses so far, all your work on FreeBSD's USB support, and helping me to understand the nature of the problem. Also thanks to Tomek, of course. Your responses helped me a lot to track down the problem. I have a couple more questions, see below. On Thu, 2 Jul 2020 13:05:51 +0200 Hans Petter Selasky wrote: > On 2020-07-02 12:37, Jan Behrens wrote: > > On Thu, 2 Jul 2020 12:18:02 +0200 > > Hans Petter Selasky wrote: > > > > Hi Jan, > > >>> I experienced that /dev/usb/2.2.0 and /dev/usb/2.2.1, 2.2.2, 2.2.3, > >>> etc. get treated differently when I reset the LimeSDR Mini with > >>> "usbconfig -u 2 -a 2 reset". The devices 2.2.1 and up are supposingly > >>> re-created (and have their access rights reset), while the device 2.2.0 > >>> maintains any manually changed access rights. > >>> > >> > >> Let me explain, now you are getting me into dirty details :-) > >> > >> This device is used for all of LibUSB interfaces and gives access to all > >> endpoints: > >> > >> /dev/usb/X.Y.0 > >> > >> These devices are legacy devices, which allow direct access to the > >> endpoint via the shell. They are there to support the old user-space > >> model FreeBSD had. And they are re-created when you reset/reconfigure a > >> USB device. Actually you can "echo > /dev/usb/X.Y.N" to write directly > >> to an endpoint from user-space. But don't do that unless it is a modem > >> endpoint which support AT commands for example. > >> > >> /dev/usb/X.Y.[1..15] > > > > Are these devices there only for legacy reasons? > > Yes, and we have one or two firmware loading utilities in base still > using them. Except that /dev/usb/X.Y.0 (which is linked by /dev/ugenX.Y) controls access rights to the device through libusb, right? > > > Or also for granting > > access to devices via chown/chmod (or devfs.rules)? I see > > that /dev/ugenX.Y are symlinks to /dev/usb/X.Y.0 > > For LibUSB you only need to chown/chmod /dev/ugenX.Y or /dev/usb/X.Y.0 > > The other utilities are usually run as root via devd scripts in base > (See /etc/devd) . > > > > > I used chown user /dev/usb/2.2.* to get access through libusb (before I > > set up devfs.rules). > > Technically that is fine too, but you actually only need .0 for LibUSB. > > > > >> > >>> Is it correct that 2.2.0 identifies the device as a whole? > >> > >> Yes, this is correct. > > > > Then I suppose if you have access to /dev/ugenX.Y (i.e. /dev/usb/X.Y. > > 0), you should be allowed to reset a device. > > Yes, but opening /dev/ugenX.Y doesn't mean that kernel device drivers > are detached from this device. Can/does a kernel device driver restrict what a user can do with the device when the kernel driver is active? Or does access to the device always enable a user to mess up things badly? > > > What do you think? > >>> > >>> I'm not sure if this is (from a semantic point of view) the best thing > >>> to do. I would say you should only be able to reset a device if you > >>> have been granted access to the device as a whole (including all > >>> interfaces/subdevices/whatever), as the reset seems to affect all of > >>> those. > >>> > >> > >> In FreeBSD and LibUSB there is no such concept. Everything is oriented > >> around interfaces. There is a function to claim an interface, but not > >> the device itself. (man libusb_claim_interface) > > > > That means in order to reset the device itself, I need to claim an > > interface, e.g. interface 0? But above you said, 2.2.0 identifies the > > device as a whole (and I noted it is symlinked by /dev/ugen2.2). So I'm > > a bit confused now. Is /dev/usb/2.2.0 the whole device? Or the > > interface 0 of the device? Or both... haha > > I think the following will clear your confusion: > > FreeBSD allows multiple drivers and user-space (LibUSB) to access the > same device and USB interface, using same endpoints, at the same time! > > User-space drivers are requested to create a uniq PID file, to avoid > clashes with multiple drivers on the same interface and may use > libusb_claim_interface() to tell the kernel to detach any drivers on > that specific interface. If the kernel refuses to give up control, is the user-space program denied access? If yes, I can generally understand why you don't want a USB reset to be initiated by a user-space program (at least as long there are kernel drivers attached). > > If you for example load the LimeSDR two times for the same ugenX.Y > device, then the interface communication might stop working, even though > no error is reported. Thus the lock of user-space drivers is only advisory and not enforced? How about if a kernel driver uses the device? Can/does the kernel block out a user-space driver that would mess with the kernel's operation on the device? > > Was that clear? It cleared a lot of questions for me, but some details I still don't fully overlook, see my questions above. > > --HPS > I see three possible approaches currently: 1. Allowing a
