Date: Mon, 1 Jun 2020 19:42:31 -0600 From: Gary Aitken <freebsd@dreamchaser.org> To: Tomasz CEDRO <tomek@cedro.info>, Ian Lepore <ian@freebsd.org> Cc: "freebsd-usb@FreeBSD.org" <freebsd-usb@freebsd.org> Subject: Re: arduino usb/com port issue Message-ID: <142b8877-4c21-439e-366d-e1ebcd0132fb@dreamchaser.org> In-Reply-To: <CAM8r67As2s4Xtczhw-q1_%2B7PYgJszBNhkZQ2trTu2gqvQwWtdQ@mail.gmail.com> References: <59da59d9-f0f0-0b30-f112-1c0af5f5399f@dreamchaser.org> <e17b8319-69c1-de73-678e-b7c9572da927@selasky.org> <CAM8r67Cx9DJ8EHGYmWiZVG_UOBdeyzJWdNKfxz-z_2pzbaAbmA@mail.gmail.com> <351ed893885670e21e2cf66c2afc8b637f1c517a.camel@freebsd.org> <CAM8r67As2s4Xtczhw-q1_%2B7PYgJszBNhkZQ2trTu2gqvQwWtdQ@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
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: <Arduino www.arduino.cc product 0x0043> at usbus6 Jun 1 17:32:30 breakaway kernel: umodem0 on uhub3 Jun 1 17:32:30 breakaway kernel: umodem0: <Arduino www.arduino.cc product 0x0043, class 2/0, rev 1.10/0.01, addr 2> 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 :-). Garyhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?142b8877-4c21-439e-366d-e1ebcd0132fb>