All,

   This is way in the weeds of a udev question -- something I know little
about, but I've pulled my hair out trying to find out why when connected to
openSUSE the device simply doesn't provide I/O responses from the Pico after
high-activity on the Pico?

   Simply rebooting into windows, same Pico, same USB same everything -- all
works. Unplug the Pico, carry 8-foot to Arch box, plug-in, everything works,
reboot openSUSE, carry Pico back from Arch box, plug into same USB as before
and no output after high-activity on the Pico on openSUSE. The card isn't
locked, simply pressing Enter restores shell prompt, so it is just something
happening on the USB port that is preventing *some* I/O from coming through.

   minicom, picocom, tip, doesn't matter. 9600 baud or 115200 baud, doesn't
matter, there is just something about how /dev/ttyACM0 is configured or
accessed on openSUSE that is causing the issue.

   stty settings are exactly the same between Arch and openSUSE. When hooked
to the Arch box, access is from openSUSE via ssh using the same terminal.
Peering through udevadm info output there are subtle difference in how the
udev rule sets up the device which has me wondering if those small differences
in setup is what is responsible for the behavior I see. I don't know enough
about it to know so I need help.

   The Archlinux udevadmin info output for /dev/ttyACM0 is at:

https://paste.opensuse.org/bb73cdfe5dd7

   The openSUSE udevadmin info output for /dev/ttyACM0 is at:

https://paste.opensuse.org/2c4d323524ee

   The only things that stand out are the openSUSE configures "kids" info for
the device while Arch has no "kids" and there are difference in some settings,
these being some that were noted, e.g.

   Arch:

     ATTRS{manufacturer}=="Raspberry Pi"
     ...
     (power/async not set)
     ATTRS{power/control}=="on"
     ATTRS{power/level}=="on"
     ...
     ATTRS{power/runtime_status}=="active"
     ATTRS{power/runtime_suspended_time}=="0"
     ...
     ATTRS{quirks}=="0x0"
     ATTRS{removable}=="unknown"
     ATTRS{remove}=="(not readable)"
     ATTRS{rx_lanes}=="1"
     ATTRS{serial}=="E6612483CB6D7F25"
     ATTRS{speed}=="12"
     ATTRS{tx_lanes}=="1"
     ATTRS{urbnum}=="250"
     ATTRS{version}==" 1.10"

   looking at parent device '/devices/pci0000:00/0000:00:1d.3':
     ...
     ATTRS{consistent_dma_mask_bits}=="32"
     ATTRS{d3cold_allowed}=="0"
     ATTRS{device}=="0x27cb"
     ATTRS{dma_mask_bits}=="32"


   openSUSE:

     ATTRS{manufacturer}=="Raspberry Pi"
     ...
     ATTRS{power/async}=="enabled"
     ATTRS{power/control}=="auto"
     ATTRS{power/level}=="auto"
     ...
     ATTRS{power/runtime_status}=="suspended"
     ATTRS{power/runtime_suspended_time}=="75332"
     ...
     ATTRS{product}=="Picoprobe"
     ATTRS{quirks}=="0x0"
     ATTRS{removable}=="unknown"
     ATTRS{rx_lanes}=="1"
     ATTRS{serial}=="E6612483CB6D7F25"
     ATTRS{speed}=="12"
     ATTRS{tx_lanes}=="1"
     ATTRS{urbnum}=="273"
     ATTRS{version}==" 1.10"

   looking at parent device '/devices/pci0000:00/0000:00:1c.7/0000:26:00.0':
     ...
     ATTRS{consistent_dma_mask_bits}=="64"
     ATTRS{current_link_speed}=="5.0 GT/s PCIe"
     ATTRS{current_link_width}=="1"
     ATTRS{d3cold_allowed}=="1"
     ATTRS{device}=="0x0194"
     ATTRS{dma_mask_bits}=="64"


   But admittedly, those settings do not mean much to me. Can anyone think of
any difference in udev that may explain the I/O with the pico not all being
there on openSUSE, but being 100% fine when rebooting to windows, or when
plugging the connection into any other box I have?

   Having eliminated everything else I can think of and having tested the same
Pico on the same USB port on my laptop and then having tested plugged into any
other box, there is something different about the /dev/ttyACM0 device when it
is connected to openSUSE - but I can't quite figure out what.

   All help, ideas, welcomed.

   This was uncovered as part of an issue being worked on github, though not
100% related to the port, it contains all the elimination of other
possibilities of what it could be (for any interested reader):

https://github.com/carlk3/no-OS-FatFS-SD-SPI-RPi-Pico/issues/91


--
David C. Rankin, J.D.,P.E.