How can openSUSE udev rule for /dev/ttyACM0 impact communication with the device?
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.
On Wed, Dec 20, 2023 at 7:22 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
But admittedly, those settings do not mean much to me.
They are not settings, they are attributes exported and managed by the driver. The difference is likely due to different kernel versions or kernel configurations. Try the current kernel from https://build.opensuse.org/project/show/Kernel:stable:Backport, assuming you are using Leap (you never told us).
On 12/20/23 00:59, Andrei Borzenkov wrote:
They are not settings, they are attributes exported and managed by the driver. The difference is likely due to different kernel versions or kernel configurations.
Try the current kernel from https://build.opensuse.org/project/show/Kernel:stable:Backport, assuming you are using Leap (you never told us).
Thank you Andrei, Yes, still Leap 15.4, we will give it a try and report back. -- David C. Rankin, J.D.,P.E.
On 12/20/23 00:59, Andrei Borzenkov wrote:
On Wed, Dec 20, 2023 at 7:22 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
But admittedly, those settings do not mean much to me.
They are not settings, they are attributes exported and managed by the driver. The difference is likely due to different kernel versions or kernel configurations.
Try the current kernel from https://build.opensuse.org/project/show/Kernel:stable:Backport, assuming you are using Leap (you never told us).
Andrei, Got it booted, but not much I can do stuck in 640x480 res. This laptop has a damn Nvidia card in it. Is there a way to bootstrap the G04 drivers to work with the 6.6.7 kernel, or do I need to do the normal build from the .bin package? If I do need to build from the .bin, is there a TW package or patch that would work? -- David C. Rankin, J.D.,P.E.
On 12/20/23 13:14, David C. Rankin wrote:
On 12/20/23 00:59, Andrei Borzenkov wrote:
Andrei,
Got it booted, but not much I can do stuck in 640x480 res. This laptop has a damn Nvidia card in it. Is there a way to bootstrap the G04 drivers to work with the 6.6.7 kernel, or do I need to do the normal build from the .bin package?
If I do need to build from the .bin, is there a TW package or patch that would work?
Branched and patched nvidia-gfxG04 for the 6.6 kernel, but the damn buildservice scheduler hasn't picked the package up yet. The build "finished" hours ago, but the status is still stuck at "finished". See: https://build.opensuse.org/package/show/home:drankinatty:branches:X11:Driver... Would it be better to patch the nvidia-drm source locally and attempt to force a driver rebuild on this laptop rather than building and installing a new driver package? -- David C. Rankin, J.D.,P.E.
On 12/20/23 00:59, Andrei Borzenkov wrote:
Try the current kernel from https://build.opensuse.org/project/show/Kernel:stable:Backport, assuming you are using Leap (you never told us).
Done, Just ran everything from the console. It makes no difference. SDIO works fine for benchmarks, SPI hangs before outputting the write statistics. Write indicator LED on the SD breakout and the Pico LED shows proper activity for the length of the write, a short blip and then activity for the proper length of the read, but no output is received. Hitting [Enter] restores the prompt for the little shell and all things continue normally (ls of the card contents, cp of files, mv, etc...) There is something odd somewhere with /dev/ttyACM0 setup, because it only fails on openSUSE, and works in windows (same USB port) and Arch (different box) -- David C. Rankin, J.D.,P.E.
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 12/20/23 01:12, Roger Oberholtzer wrote:
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/
No, Access is fine. This is a "way down in the weeds" subtle issue that only affect *some* I/O between the card and openSUSE. Specifically when accessing a SD card using SPI communication protocol. When using SDIO all it fine. The test it impacts is the bechmarks test. Using SDIO, the card responds showing the average access times for read/write to the SD card, e.g.
bench Type is FAT32 Card size: 1305.67 GB (GB = 1E9 bytes)
Manufacturer ID: 0x27 OEM ID: PHProduct: SD32G Revision: 6.0 Serial number: 0xb55b72da Manufacturing date: 11/2022 FILE_SIZE_MB = 5 BUF_SIZE = 65536 Starting write test, please wait. write speed and latency speed,max,min,avg KB/Sec,usec,usec,usec 6033.2,11064,10798,10835 6033.2,11069,10796,10809 Starting read test, please wait. read speed and latency speed,max,min,avg KB/Sec,usec,usec,usec 6981.2,9608,9367,9383 6990.5,9607,9367,9377 Done However, when using SPI the bench test hangs before showing the write speed results, e.g.
bench Type is FAT32 Card size: 1305.67 GB (GB = 1E9 bytes)
Manufacturer ID: 0x27 OEM ID: PHProduct: SD32G Revision: 6.0 Serial number: 0xb55b72da Manufacturing date: 11/2022 FILE_SIZE_MB = 5 BUF_SIZE = 65536 Starting write test, please wait. write speed and latency speed,max,min,avg KB/Sec,usec,usec,usec <port hangs, nothing else received from bench, LED access lights show test completes normally> This isn't a hard-lockup, all I have to do is press [Enter] and the test code drops back to the little shell prompt that is running on the Pico. This may also explain the bug downloading photos from the iPhone with gphoto2, Iphone10X - Error (-7: 'I/O problem') after 397 files downloaded (repeatable on file 398) https://bugzilla.opensuse.org/show_bug.cgi?id=1206534 which has been open and unsolved for years. Here is to hoping Andrei's crystal ball is working normally today. -- David C. Rankin, J.D.,P.E.
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.
participants (4)
-
Andrei Borzenkov -
David C. Rankin -
Roger Oberholtzer -
sflees