I'm guessing that you mean that on openSUSE you cannot access the device. Have you put a udev rule in place for it? It would be a file in /etc/udev/rules.d/ I have one that looks like this. It is the absolute minimum and is rather permissive: roger@stingray:~> cat /etc/udev/rules.d/95-pico.rules ATTRS{idVendor}=="0ce9", MODE="0666" Just put that one line in a file in /etc/udev/rules.d/ that has the extension .rules. Then type: udevadm control --reload I sometimes add making a symlink in /dev so I know the rule has triggered. Use something like this as the rule instead: SUBSYSTEM=="usb", ACTION=="add", ENV{ID_VENDOR_ID}=="06e9", MODE="0666", SYMLINK+="pico", OWNER="roger", GROUP="users", MODE="0666" If you don't want to set, say, the owner, then remove that directive. Just note that all parts with '==' are a test, and and all with '=' are something that will be set or done. On Wed, Dec 20, 2023 at 5:22 AM David C. Rankin < drankinatty@suddenlinkmail.com> wrote:

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.

-- Roger Oberholtzer

On 2023-12-20 15:21, David C. Rankin wrote:

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

Do you have brltty installed? some braille hardware manufacturers have been exceptionally lazy and have left generic usb serial identifier strings in there devices rather then swapping to identifying as there own manufacturer. As a result the brltty udev rules in the past have been over aggressive and have attempted to configure any device with certain usb->serial chips as a piece of braille hardware. In particular i've been affected by this when using some of the generic ftdi usb to serial chips. I'm also guessing Arch may not install brltty by default where as openSUSE does in some cases for accessibility. So one thing worth trying is uninstalling brltty, personally I have a lock for it.