From owner-freebsd-usb@freebsd.org Tue Jun 2 01:45:02 2020 Return-Path: Delivered-To: freebsd-usb@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5E0CE2FB6D5 for ; Tue, 2 Jun 2020 01:45:02 +0000 (UTC) (envelope-from freebsd@dreamchaser.org) Received: from nightmare.dreamchaser.org (ns.dreamchaser.org [66.109.141.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dreamchaser.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49bZbw6jw8z4PNm; Tue, 2 Jun 2020 01:45:00 +0000 (UTC) (envelope-from freebsd@dreamchaser.org) Received: from breakaway.dreamchaser.org (breakaway [192.168.151.122]) by nightmare.dreamchaser.org (8.15.2/8.15.2) with ESMTP id 0521ipa1013778; Mon, 1 Jun 2020 19:44:51 -0600 (MDT) (envelope-from freebsd@dreamchaser.org) Subject: Re: arduino usb/com port issue To: Tomasz CEDRO , Ian Lepore Cc: "freebsd-usb@FreeBSD.org" References: <59da59d9-f0f0-0b30-f112-1c0af5f5399f@dreamchaser.org> <351ed893885670e21e2cf66c2afc8b637f1c517a.camel@freebsd.org> Reply-To: freebsd@dreamchaser.org From: Gary Aitken Message-ID: <142b8877-4c21-439e-366d-e1ebcd0132fb@dreamchaser.org> Date: Mon, 1 Jun 2020 19:42:31 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (nightmare.dreamchaser.org [192.168.151.101]); Mon, 01 Jun 2020 19:44:51 -0600 (MDT) X-Rspamd-Queue-Id: 49bZbw6jw8z4PNm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@dreamchaser.org designates 66.109.141.57 as permitted sender) smtp.mailfrom=freebsd@dreamchaser.org X-Spamd-Result: default: False [-2.57 / 15.00]; HAS_REPLYTO(0.00)[freebsd@dreamchaser.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DMARC_NA(0.00)[dreamchaser.org]; NEURAL_HAM_LONG(-1.00)[-1.002]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.34)[-0.336]; NEURAL_HAM_MEDIUM(-0.93)[-0.934]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:21947, ipnet:66.109.128.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 01:45:02 -0000 Ok, I've rebooted even though I didn't need to ;-) If I start an X session as root, when I start arduino the Serial Port menu item is live; I have the needed access and see 4 devices: /dev/ttyu0 /dev/cuau0 /dev/ttyU0 /dev/cuaU0 In my case, /dev/cuaU0 is what responds when I have the arduino plugged in. The other three devices are "permanently" present; cuaU0 only appears when the arduino is plugged in. If I assign cuaU0 as the arduino serial device, arduino uploads to it fine. So all is cool if you're the supreme being. Switching back to a normal user, the entire serial port menu item is still greyed out, so you see no choices even though the other three devices are still present. As a normal user: $ grep skinnyguy /etc/group operator:*:5:root,skinnyguy video:*:44:skinnyguy dialer:*:68:skinnyguy $ grep devfs /etc/rc.conf # allow local rules as specified in /etc/devfs.rules (5) devfs_system_ruleset="localrules" $ cat /etc/devfs.rules # Allow operator group to mount USB devices [localrules=5] add path 'da*' mode 0660 group operator # for arduino hotplug USB add path 'ugen*' mode 0660 group operator add path 'usb/*' mode 0660 group operator add path 'usb' mode 0770 group operator add path 'cuaU*' mode 0770 group operator $ ls -l /dev/cuaU0 crwxrwx--- 1 uucp operator 0xac Jun 1 17:32 /dev/cuaU0 Giving +rw access to everyone for cua* makes no difference Did I miss something along the way, or is there yet something else that root has that I'm missing? On 6/1/20 9:36 AM, Tomasz CEDRO wrote: > On Mon, Jun 1, 2020 at 5:28 PM Ian Lepore wrote: >> There should be no need to unload ucom to access the low-level usb >> device via libusb. I typically have anywhere from 5-8 usb-serial >> adapters connected at once, it would be crazy to unload ucom and lose >> access to all of them just to use one of them with libusb. >> >> It is important, however, to avoid accessing /dev/cuaU# or /dev/ttyU# >> at the same time that some application is using libusb (or libftdi) to >> access that same device. That would cause ucom and the work being done >> via libusb to conflict with each other. > > Exactly the problem here. Either application tries to unload kernel > driver just to make sure terminal can connect to a dongle (linux > quickfix), or the modem port is already opened with u3g module (more > probable scenario). Anyway CMSIS-DAP has its own endpoint that is > separate from VCP so it should work without unloading the module. > > Will verify and send patches to the upstream no worries, thanks for > the hints, but that could be another source of problem described by > Gary that I found in a similar application :-) I'm running xfce via "/usr/local/bin/startxfce4 --with-ck-launch" Other than a bunch of xterms, a clock, and thunderbird, nothing special. However, I see that dbus- has four instances, and at-spi-bus-launcher has one: $ ps ax | grep bus 604 - Is 0:00.03 /usr/local/bin/dbus-daemon --system 6260 - Is 0:00.03 /usr/local/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session 6262 - I 0:00.01 /usr/local/libexec/at-spi-bus-launcher 6263 - S 0:00.09 /usr/local/bin/dbus-daemon --config-file=/usr/local/share/defaults/at-spi2/accessibility.conf --nofork --p 6259 v0 I 0:00.00 /usr/local/bin/dbus-launch --sh-syntax --exit-with-session xfce4-session Could these be interfering with user access as you hypothesize? I don't *know* of any other apps accessing any usb port other than the mouse. Jun 1 17:32:30 breakaway kernel: ugen6.2: at usbus6 Jun 1 17:32:30 breakaway kernel: umodem0 on uhub3 Jun 1 17:32:30 breakaway kernel: umodem0: on usbus6 Jun 1 17:32:30 breakaway kernel: umodem0: data interface 1, has CM over data, has break Is there a document describing the relationship between usb0 and ugen6.2, umodem0, usbus6, and uhub3? I'm guessing something like usbusn is a physical port on uhubm which is a physical multiplexor, and ugena.b, umodemx and usbusy are somehow mapped to usbusn, but that's a wild guess and probably not useful (to *me*) in making progress here. But inquiring minds always want to know, if for no other reason than to fight dementia :-). Gary