arduino usb/com port issue

[Warner Losh]

On Mon, Jun 1, 2020 at 7:45 PM Gary Aitken <freebsd at dreamchaser.org> wrote:

> 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?


Not really no. :( uhub is the 'bus' of USB, but beyond that it gets murky.


> 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 :-).
>

You might find that devinfo -v gives you enough information to hold
dementia at bay for another day or three... Or not if I've lost it

Warner