Buster udev rules for ttyUSB ports broken

[jsjames70]

Hi - I have several udev rules to map by ttyUSB* ports to a logical/stable name. I recently upgraded to Buster and instead of the symbolic link of those devices linking to the appropriate ttyUSB port, they link to gpiochip*.

lrwxrwxrwx 1 root root 9 Aug 23 18:24 ttyAD2USB -> gpiochip2
lrwxrwxrwx 1 root root 9 Aug 23 18:24 ttyInsteonPLM -> gpiochip3

Here my sample udev rules that worked in previous versions.

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A60335LE", SYMLINK+="ttyInsteonPLM"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A5003uIM", SYMLINK+="ttyAD2USB"

Any suggestions? Does this look like a bug in the Buster?

Thanks,
Jeff

[epoch1970]

I think you need to specify the abs path for the link, e.g. /dev/mydevice

[DougieLawson]

Can you post the results from udevadm info --attribute-walk --path=/sys/bus/usb-serial/devices/ttyUSB0 and udevadm info --attribute-walk --path=/sys/bus/usb-serial/devices/ttyUSB1?

[jsjames70]

Thanks for the help.

Here is the result for USB0

looking at device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.0/ttyUSB0':
KERNEL=="ttyUSB0"
SUBSYSTEM=="usb-serial"
DRIVER=="ftdi_sio"
ATTR{port_number}=="0"
ATTR{latency_timer}=="16"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.0':
KERNELS=="1-1.4:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="ftdi_sio"
ATTRS{bInterfaceProtocol}=="ff"
ATTRS{bInterfaceClass}=="ff"
ATTRS{interface}=="FT232R USB UART"
ATTRS{authorized}=="1"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bInterfaceSubClass}=="ff"
ATTRS{supports_autosuspend}=="1"
ATTRS{bNumEndpoints}=="02"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4':
KERNELS=="1-1.4"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{serial}=="A60335LE"
ATTRS{maxchild}=="0"
ATTRS{quirks}=="0x0"
ATTRS{speed}=="12"
ATTRS{urbnum}=="3075807"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{manufacturer}=="FTDI"
ATTRS{bcdDevice}=="0600"
ATTRS{idVendor}=="0403"
ATTRS{ltm_capable}=="no"
ATTRS{bNumConfigurations}=="1"
ATTRS{idProduct}=="6001"
ATTRS{bConfigurationValue}=="1"
ATTRS{bDeviceClass}=="00"
ATTRS{authorized}=="1"
ATTRS{version}==" 2.00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{devnum}=="3"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{product}=="FT232R USB UART"
ATTRS{busnum}=="1"
ATTRS{bMaxPacketSize0}=="8"
ATTRS{devpath}=="1.4"
ATTRS{devspec}=="(null)"
ATTRS{rx_lanes}=="1"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bmAttributes}=="a0"
ATTRS{bMaxPower}=="90mA"
ATTRS{tx_lanes}=="1"
ATTRS{removable}=="unknown"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1':
KERNELS=="1-1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceClass}=="09"
ATTRS{configuration}==""
ATTRS{bMaxPacketSize0}=="64"
ATTRS{bDeviceProtocol}=="01"
ATTRS{tx_lanes}=="1"
ATTRS{bcdDevice}=="0421"
ATTRS{idProduct}=="3431"
ATTRS{version}==" 2.10"
ATTRS{busnum}=="1"
ATTRS{devpath}=="1"
ATTRS{idVendor}=="2109"
ATTRS{maxchild}=="4"
ATTRS{ltm_capable}=="no"
ATTRS{bNumConfigurations}=="1"
ATTRS{rx_lanes}=="1"
ATTRS{speed}=="480"
ATTRS{authorized}=="1"
ATTRS{urbnum}=="45"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{bConfigurationValue}=="1"
ATTRS{bNumInterfaces}==" 1"
ATTRS{removable}=="unknown"
ATTRS{bDeviceSubClass}=="00"
ATTRS{quirks}=="0x0"
ATTRS{bmAttributes}=="e0"
ATTRS{bMaxPower}=="100mA"
ATTRS{product}=="USB2.0 Hub"
ATTRS{devspec}=="(null)"
ATTRS{devnum}=="2"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1':
KERNELS=="usb1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{maxchild}=="1"
ATTRS{devspec}=="(null)"
ATTRS{urbnum}=="22"
ATTRS{bDeviceClass}=="09"
ATTRS{product}=="xHCI Host Controller"
ATTRS{interface_authorized_default}=="1"
ATTRS{authorized}=="1"
ATTRS{quirks}=="0x0"
ATTRS{bNumInterfaces}==" 1"
ATTRS{bDeviceProtocol}=="01"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
ATTRS{configuration}==""
ATTRS{devpath}=="0"
ATTRS{ltm_capable}=="no"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bNumConfigurations}=="1"
ATTRS{devnum}=="1"
ATTRS{bMaxPower}=="0mA"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{rx_lanes}=="1"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{speed}=="480"
ATTRS{serial}=="0000:01:00.0"
ATTRS{bcdDevice}=="0504"
ATTRS{busnum}=="1"
ATTRS{authorized_default}=="1"
ATTRS{version}==" 2.00"
ATTRS{tx_lanes}=="1"
ATTRS{manufacturer}=="Linux 5.4.51-v7l+ xhci-hcd"
ATTRS{removable}=="unknown"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="e0"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0':
KERNELS=="0000:01:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="xhci_hcd"
ATTRS{device}=="0x3483"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{dma_mask_bits}=="64"
ATTRS{ari_enabled}=="0"
ATTRS{local_cpus}=="f"
ATTRS{irq}=="56"
ATTRS{class}=="0x0c0330"
ATTRS{subsystem_vendor}=="0x1106"
ATTRS{current_link_width}=="1"
ATTRS{enable}=="1"
ATTRS{driver_override}=="(null)"
ATTRS{subsystem_device}=="0x3483"
ATTRS{broken_parity_status}=="0"
ATTRS{current_link_speed}=="5 GT/s"
ATTRS{vendor}=="0x1106"
ATTRS{msi_bus}=="1"
ATTRS{max_link_speed}=="5 GT/s"
ATTRS{local_cpulist}=="0-3"
ATTRS{devspec}==""
ATTRS{revision}=="0x01"
ATTRS{max_link_width}=="1"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0':
KERNELS=="0000:00:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{subsystem_device}=="0x0000"
ATTRS{aer_rootport_total_err_fatal}=="0"
ATTRS{broken_parity_status}=="0"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{ari_enabled}=="0"
ATTRS{vendor}=="0x14e4"
ATTRS{secondary_bus_number}=="1"
ATTRS{local_cpulist}=="0-3"
ATTRS{local_cpus}=="f"
ATTRS{devspec}==""
ATTRS{max_link_width}=="1"
ATTRS{subordinate_bus_number}=="1"
ATTRS{dma_mask_bits}=="32"
ATTRS{msi_bus}=="1"
ATTRS{device}=="0x2711"
ATTRS{class}=="0x060400"
ATTRS{driver_override}=="(null)"
ATTRS{enable}=="1"
ATTRS{max_link_speed}=="5 GT/s"
ATTRS{current_link_speed}=="5 GT/s"
ATTRS{current_link_width}=="1"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{aer_rootport_total_err_cor}=="0"
ATTRS{irq}=="55"
ATTRS{aer_rootport_total_err_nonfatal}=="0"
ATTRS{revision}=="0x10"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

looking at parent device '/devices/platform/scb/fd500000.pcie':
KERNELS=="fd500000.pcie"
SUBSYSTEMS=="platform"
DRIVERS=="brcm-pcie"
ATTRS{driver_override}=="(null)"

looking at parent device '/devices/platform/scb':
KERNELS=="scb"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{driver_override}=="(null)"

looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""

and USB1

looking at device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB1':
KERNEL=="ttyUSB1"
SUBSYSTEM=="usb-serial"
DRIVER=="ftdi_sio"
ATTR{port_number}=="0"
ATTR{latency_timer}=="16"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0':
KERNELS=="1-1.3:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="ftdi_sio"
ATTRS{supports_autosuspend}=="1"
ATTRS{bInterfaceSubClass}=="ff"
ATTRS{interface}=="FT232R USB UART"
ATTRS{bNumEndpoints}=="02"
ATTRS{bInterfaceProtocol}=="ff"
ATTRS{bInterfaceClass}=="ff"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}=="00"
ATTRS{authorized}=="1"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3':
KERNELS=="1-1.3"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{devnum}=="4"
ATTRS{tx_lanes}=="1"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{configuration}==""
ATTRS{bDeviceProtocol}=="00"
ATTRS{version}==" 2.00"
ATTRS{devspec}=="(null)"
ATTRS{urbnum}=="16"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="0"
ATTRS{bMaxPower}=="90mA"
ATTRS{bDeviceSubClass}=="00"
ATTRS{ltm_capable}=="no"
ATTRS{busnum}=="1"
ATTRS{authorized}=="1"
ATTRS{product}=="FT232R USB UART"
ATTRS{bConfigurationValue}=="1"
ATTRS{idProduct}=="6001"
ATTRS{bDeviceClass}=="00"
ATTRS{idVendor}=="0403"
ATTRS{bMaxPacketSize0}=="8"
ATTRS{rx_lanes}=="1"
ATTRS{bNumInterfaces}==" 1"
ATTRS{serial}=="A5003uIM"
ATTRS{quirks}=="0x0"
ATTRS{devpath}=="1.3"
ATTRS{bmAttributes}=="a0"
ATTRS{manufacturer}=="FTDI"
ATTRS{removable}=="unknown"
ATTRS{bcdDevice}=="0600"
ATTRS{speed}=="12"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1':
KERNELS=="1-1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{devnum}=="2"
ATTRS{bConfigurationValue}=="1"
ATTRS{idVendor}=="2109"
ATTRS{product}=="USB2.0 Hub"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="4"
ATTRS{bDeviceClass}=="09"
ATTRS{bMaxPower}=="100mA"
ATTRS{bcdDevice}=="0421"
ATTRS{idProduct}=="3431"
ATTRS{bNumInterfaces}==" 1"
ATTRS{ltm_capable}=="no"
ATTRS{tx_lanes}=="1"
ATTRS{speed}=="480"
ATTRS{rx_lanes}=="1"
ATTRS{removable}=="unknown"
ATTRS{authorized}=="1"
ATTRS{busnum}=="1"
ATTRS{quirks}=="0x0"
ATTRS{devpath}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{bDeviceSubClass}=="00"
ATTRS{urbnum}=="45"
ATTRS{bDeviceProtocol}=="01"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{bmAttributes}=="e0"
ATTRS{version}==" 2.10"
ATTRS{devspec}=="(null)"
ATTRS{configuration}==""

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1':
KERNELS=="usb1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bcdDevice}=="0504"
ATTRS{bDeviceProtocol}=="01"
ATTRS{bMaxPower}=="0mA"
ATTRS{bNumInterfaces}==" 1"
ATTRS{speed}=="480"
ATTRS{quirks}=="0x0"
ATTRS{authorized_default}=="1"
ATTRS{bConfigurationValue}=="1"
ATTRS{serial}=="0000:01:00.0"
ATTRS{idVendor}=="1d6b"
ATTRS{authorized}=="1"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{removable}=="unknown"
ATTRS{tx_lanes}=="1"
ATTRS{bNumConfigurations}=="1"
ATTRS{bDeviceClass}=="09"
ATTRS{configuration}==""
ATTRS{manufacturer}=="Linux 5.4.51-v7l+ xhci-hcd"
ATTRS{rx_lanes}=="1"
ATTRS{product}=="xHCI Host Controller"
ATTRS{devnum}=="1"
ATTRS{urbnum}=="22"
ATTRS{devpath}=="0"
ATTRS{bmAttributes}=="e0"
ATTRS{ltm_capable}=="no"
ATTRS{version}==" 2.00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{idProduct}=="0002"
ATTRS{devspec}=="(null)"
ATTRS{interface_authorized_default}=="1"
ATTRS{busnum}=="1"
ATTRS{maxchild}=="1"
ATTRS{bMaxPacketSize0}=="64"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0':
KERNELS=="0000:01:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="xhci_hcd"
ATTRS{enable}=="1"
ATTRS{current_link_speed}=="5 GT/s"
ATTRS{broken_parity_status}=="0"
ATTRS{local_cpus}=="f"
ATTRS{device}=="0x3483"
ATTRS{revision}=="0x01"
ATTRS{dma_mask_bits}=="64"
ATTRS{subsystem_device}=="0x3483"
ATTRS{devspec}==""
ATTRS{subsystem_vendor}=="0x1106"
ATTRS{vendor}=="0x1106"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{max_link_speed}=="5 GT/s"
ATTRS{max_link_width}=="1"
ATTRS{msi_bus}=="1"
ATTRS{class}=="0x0c0330"
ATTRS{driver_override}=="(null)"
ATTRS{local_cpulist}=="0-3"
ATTRS{current_link_width}=="1"
ATTRS{ari_enabled}=="0"
ATTRS{irq}=="56"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0':
KERNELS=="0000:00:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{revision}=="0x10"
ATTRS{devspec}==""
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{aer_rootport_total_err_cor}=="0"
ATTRS{max_link_speed}=="5 GT/s"
ATTRS{max_link_width}=="1"
ATTRS{device}=="0x2711"
ATTRS{local_cpulist}=="0-3"
ATTRS{current_link_speed}=="5 GT/s"
ATTRS{current_link_width}=="1"
ATTRS{aer_rootport_total_err_nonfatal}=="0"
ATTRS{ari_enabled}=="0"
ATTRS{aer_rootport_total_err_fatal}=="0"
ATTRS{subsystem_device}=="0x0000"
ATTRS{class}=="0x060400"
ATTRS{enable}=="1"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{secondary_bus_number}=="1"
ATTRS{vendor}=="0x14e4"
ATTRS{dma_mask_bits}=="32"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"
ATTRS{subordinate_bus_number}=="1"
ATTRS{driver_override}=="(null)"
ATTRS{local_cpus}=="f"
ATTRS{irq}=="55"

looking at parent device '/devices/platform/scb/fd500000.pcie/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

looking at parent device '/devices/platform/scb/fd500000.pcie':
KERNELS=="fd500000.pcie"
SUBSYSTEMS=="platform"
DRIVERS=="brcm-pcie"
ATTRS{driver_override}=="(null)"

looking at parent device '/devices/platform/scb':
KERNELS=="scb"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{driver_override}=="(null)"

looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""

[DougieLawson]

Everything from those two commands works OK. You've got the right idVendor, idProduct and serial values - so udev should be able to uniquely identify the two FTDI adapters.

Where have you created your two rules? Are they in a new file in /etc/udev/rules.d/x.y.z.z.y.rules or have you edited them into /lib/udev/rules.d/60-rpi.gpio-common.rules? Is there anything else in your rules files?

[jsjames70]

I have a file in /etc/udev/rules.d i called 99-myusb.rules. The rules worked before I upgraded to Buster. It does create a link with the appropriate name, but instead of creating to the /dev/ttyUSB* device, it creates it to the gpiochip*.

[hippy]

Can't help with the odd symlinks you have. But I can confirm this works for me on a 3B using Buster (32-bit), 4B Buster, (64-bit kernel, 32-bit userland) ...

Code: Select all

pi@Pi3B:~ $ cat /etc/udev/rules.d/99-xxx.rules 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTBT0L0C", SYMLINK+="ttyCOM1"

Code: Select all

pi@Pi3B:~ $ ls -al /dev/ttyC*
lrwxrwxrwx 1 root root 7 Aug 24 16:00 /dev/ttyCOM1 -> ttyUSB0

Also worked without "SUBSYSTEMS==" and without "ATTRS{serial}==".

Unplugging the cable had that disappear as expected, and plugging it back in, gave me ...

Code: Select all

pi@Pi3B:~ $ ls -al /dev/ttyC*
lrwxrwxrwx 1 root root 15 Aug 24 16:06 /dev/ttyCOM1 -> bus/usb/001/009

Which matches what 'lsusb' shows so I presume that's okay.

What do you get when you only have one cable connected and you reboot ? Does that still symlink to 'gpiochip*' ?

[RamaSpaceShip]

Can you change (note also the removal of ending 'S' to SUBSYSTEM ) your udev rules to:
SUBSYSTEM=="usb-serial", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A60335LE", SYMLINK+="ttyInsteonPLM"
SUBSYSTEM=="usb-serial", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A5003uIM", SYMLINK+="ttyAD2USB"

And tell the result?

[hippy]

SUBSYSTEM=="usb-serial"

That doesn't work for me on my 3B, prevents what was working with SUBSYSTEMS=="usb" from working.

[jsjames70]

Same result - SUBSYSTEM=="usb-serial" does not work for me.

udev seems to be finding and processing my original rule - if I do a udevadm test $(udevadm info -q path -n /dev/ttyUSB1), I get the below result - where in the DEVLINKS it adds the /dev/ttyAD2USB:

Rules contain 196608 bytes tokens (16384 * 12 bytes), 23947 bytes strings
15395 strings (125590 bytes), 13068 de-duplicated (103971 bytes), 2328 trie nodes used
Invalid inotify descriptor.
Starting 'usb_modeswitch --symlink-name /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB1/tty/ttyUSB1 0403 6001 '
Process 'usb_modeswitch --symlink-name /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB1/tty/ttyUSB1 0403 6001 ' succeeded.
DEVPATH=/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB1/tty/ttyUSB1
DEVNAME=/dev/ttyUSB1
MAJOR=188
MINOR=1
ACTION=add
SUBSYSTEM=tty
ID_BUS=usb
ID_VENDOR_ID=0403
ID_MODEL_ID=6001
ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
ID_PCI_INTERFACE_FROM_DATABASE=XHCI
ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd
ID_MODEL_FROM_DATABASE=FT232 Serial (UART) IC
ID_VENDOR=FTDI
ID_VENDOR_ENC=FTDI
ID_MODEL=FT232R_USB_UART
ID_MODEL_ENC=FT232R\x20USB\x20UART
ID_REVISION=0600
ID_SERIAL=FTDI_FT232R_USB_UART_A5003uIM
ID_SERIAL_SHORT=A5003uIM
ID_TYPE=generic
ID_USB_INTERFACES=:ffffff:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=ftdi_sio
.ID_PORT=0
ID_PATH=platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0
ID_PATH_TAG=platform-fd500000_pcie-pci-0000_01_00_0-usb-0_1_3_1_0
DEVLINKS=/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0 /dev/ttyAD2USB /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A5003uIM-if00-port0
TAGS=:systemd:
USEC_INITIALIZED=5408700
Unload module index
Unloaded link configuration context.


Not sure why when it finally creates the link though - it creates:

lrwxrwxrwx 1 root root 9 Aug 24 09:26 /dev/ttyAD2USB -> gpiochip3

[DougieLawson]

Run sudo apt update; sudo apt dist-upgrade -y and see if today's new kernel works better for you.

[jsjames70]

I did the apt-get update and apt-get dist-upgrade and the original rules had the same effect of creating a symbolic link to:

lrwxrwxrwx 1 root root 9 Aug 24 10:50 /dev/ttyAD2USB -> gpiochip3
lrwxrwxrwx 1 root root 9 Aug 24 10:50 /dev/ttyInsteonPLM -> gpiochip4

here are my sources to make sure I'm grabbing from the latest release.

Hit:1 https://repos.influxdata.com/debian buster InRelease
Hit:2 https://packages.grafana.com/oss/deb stable InRelease
Ign:3 http://repos.azulsystems.com/debian stable InRelease
Hit:4 http://repos.azulsystems.com/debian stable Release
Hit:5 http://archive.raspberrypi.org/debian buster InRelease
Hit:6 http://raspbian.raspberrypi.org/raspbian buster InRelease

[hippy]

Did you try it with just one cable attached ?

That will at least clarify whether the odd symlinks are being created only when the cable is connected or are more persistent.

[DougieLawson]

If you create a new SDCard with plain RaspiOS Buster, boot it, run apt update and apt dist-upgrade (to get the latest updates) and nothing else that's odd does that work?

You can then look in /etc/udev/rules.d and /lib/udev/rules.d to see if your non-standard alien packages add/update any broken new udev rules.

[hippy]

I connected two USB-serial adaptors to my Pi4 with an FTDI as /dev/ttyUSB1 and ran your "udevadm test $(udevadm info -q path -n /dev/ttyUSB1)" command. It's pretty much the same up to and including the DEVLINKS= line ...

Yours

Code: Select all

SUBSYSTEM=tty
ID_BUS=usb

Code: Select all

DEVLINKS=/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0 /dev/ttyAD2USB /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A5003uIM-if00-port0
TAGS=:systemd:
USEC_INITIALIZED=5408700
Unload module index
Unloaded link configuration context.

Mine

Code: Select all

SUBSYSTEM=tty
TAGS=:seat:systemd:uaccess:
ID_BUS=usb

Code: Select all

DEVLINKS=/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0 /dev/ttyCOM1 /dev/serial/by-id/usb-FTDI_USB_to_Serial_Cable_FTBT0L0C-if00-port0
ID_FOR_SEAT=tty-platform-fd500000_pcie-pci-0000_01_00_0-usb-0_1_3_1_0
ID_MM_CANDIDATE=1
USEC_INITIALIZED=4274643820
run: 'uaccess'
Unload module index
Unloaded link configuration context.

Our "TAGS=" are somewhat different, and in different places but likely not relevant, and I am getting those "ID_FOR_SEAT=", "ID_MM_CANDIDATE=1" and "run: 'uaccess'" which you don't.

Don't know if that helps anyone with trying to figure things out.

[jsjames70]

I did a fresh SDIO install and the issue still exists. (apt-get update/dist-upgrade had 0 files to update). I believe there is a timing hole that is getting exposed. See the following set of commands after a reboot:

jeff@raspberrypi:~$ ls -l /dev/ttyAD2USB
lrwxrwxrwx 1 root root 9 Aug 24 14:47 /dev/ttyAD2USB -> gpiochip4
jeff@raspberrypi:~$ sudo udevadm control --reload
jeff@raspberrypi:~$ sudo udevadm trigger
jeff@raspberrypi:~$ ls -l /dev/ttyAD2USB
lrwxrwxrwx 1 root root 7 Aug 24 14:49 /dev/ttyAD2USB -> ttyUSB2
jeff@raspberrypi:~$ sudo udevadm control --reload
jeff@raspberrypi:~$ sudo udevadm trigger
jeff@raspberrypi:~$ ls -l /dev/ttyAD2USB
lrwxrwxrwx 1 root root 7 Aug 24 14:49 /dev/ttyAD2USB -> ttyUSB2

I thought I could make it light-switch my renaming the /etc/udev/rules.d/99-com.rules, but that did not reliably fix it. Also, I have seen it occasionally boot up correctly as well.

[hippy]

I think the only way you are going to get to the bottom of things is to check to see what 'udev' is doing when it boots with cables attached and not.

Something is symlinking your device go 'gpiochip' and I would focus on that, more than why it's not linking to 'ttyUSB'.

Most of the stuff I found on the internet for debugging 'udev' did not work, I couldn't get '/var/log/udev' to ever appear. The only way I got 'udev' to do any useful logging was by editing '/etc/udev/udev.conf' to set "udev_log=debug", rebooting, and then '/var/log/syslog' at least contained some references to the "ttyCOM1" I create.

Beyond that I can't help much. I'm just glad its one Circle of Linux Hell I'm not having to walk through.

[Fuchks]

Have the same problem with a Pi2B on Buster.
Excluding the following lines from the stock /etc/udev/rules.d/99-com.rules solved the issue:

Code: Select all

#SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
#SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
#       chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
#       chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
#       chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
#'"

I am not that experienced to say what exactly causes the issue with that rule - but maybe one of the experienced readers can knock it down

Edit: As stated before, this only solves the issue partly, instead of symlinking to gpiochip everytime, it does it for most of the time correct, but not always - at least on my Pi.

Reported an issue for Pi Kernel

[jsjames70]

Yes, I had also tried that and it worked as a solution off & on. I believe there is still a timing hole in udev or boot system where this sometimes works and sometimes doesn't. With the rule you mentioned commented out, one of my ports does get mapped correct and 2 of them stlll map to a gpiochip#.

lrwxrwxrwx 1 root root 7 Dec 6 18:19 /dev/ttyAD2USB -> ttyUSB2
lrwxrwxrwx 1 root root 9 Dec 6 18:19 /dev/ttyInsteonPLM -> gpiochip3
lrwxrwxrwx 1 root root 9 Dec 6 18:19 /dev/ttyRS422 -> gpiochip2

Does anyone know if there is a place to register a bug in the raspberry buster support?

Thanks,
Jeff

[Fuchks]

I did, but the link is easily missed:

Reported an issue for Pi Kernel

[Fuchks]

My workaround as i do not need this gpio stuff:

Exclude the following lines from the stock /etc/udev/rules.d/99-com.rules:

Code: Select all

#SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
#SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
#       chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
#       chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
#       chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
#'"

Add the line to /etc/rc.local:

Code: Select all

sudo udevadm control --reload-rules && sudo udevadm trigger

Let me know if this works reliable on your system too

[jsjames70]

Thanks. I didn't think about adding a command to rc.local. I did the same and it looks like this is a good workaround. Thanks again.

[Fuchks]

Reported in: Buster bug report thread

[scruss]

I am not that experienced to say what exactly causes the issue with that rule - but maybe one of the experienced readers can knock it down

I think Raspberry Pi OS is looking for one of those remote GPIO extenders that you can use via gpiozero. They use USB serial ports.

If you're using more than one serial port, something in /dev/serial/by-id/ might be a better endpoint, not one of the semi-random /dev/tty???n ports which can enumerate any old how.

[ShiftPlusOne]

Can you change (note also the removal of ending 'S' to SUBSYSTEM ) your udev rules to:
SUBSYSTEM=="usb-serial", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A60335LE", SYMLINK+="ttyInsteonPLM"
SUBSYSTEM=="usb-serial", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A5003uIM", SYMLINK+="ttyAD2USB"

And tell the result?

...so close. In my testing, SUBSYSTEM=="tty" seems to be the right set of udev runes.

I've added a comment on the issue https://github.com/raspberrypi/linux/is ... -755231352 , would be good to get a confirmation that this works for everybody else too.