jsjames70
Posts: 9
Joined: Mon Aug 24, 2020 1:31 am

Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 1:41 am

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
Posts: 7857
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 1:34 pm

I think you need to specify the abs path for the link, e.g. /dev/mydevice
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

User avatar
DougieLawson
Posts: 42177
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 1:57 pm

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?
Languages using left-hand whitespace for syntax are ridiculous

DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors - are all on my foes list.

The use of crystal balls and mind reading is prohibited.

jsjames70
Posts: 9
Joined: Mon Aug 24, 2020 1:31 am

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 2:07 pm

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==""

User avatar
DougieLawson
Posts: 42177
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 2:19 pm

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?
Languages using left-hand whitespace for syntax are ridiculous

DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors - are all on my foes list.

The use of crystal balls and mind reading is prohibited.

jsjames70
Posts: 9
Joined: Mon Aug 24, 2020 1:31 am

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 2:54 pm

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
Posts: 12309
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 3:20 pm

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

User avatar
RamaSpaceShip
Posts: 230
Joined: Sun Apr 26, 2020 12:19 pm

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 3:44 pm

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
Posts: 12309
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 4:25 pm

RamaSpaceShip wrote:
Mon Aug 24, 2020 3:44 pm
SUBSYSTEM=="usb-serial"
That doesn't work for me on my 3B, prevents what was working with SUBSYSTEMS=="usb" from working.

jsjames70
Posts: 9
Joined: Mon Aug 24, 2020 1:31 am

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 4:31 pm

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

User avatar
DougieLawson
Posts: 42177
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 4:39 pm

Run sudo apt update; sudo apt dist-upgrade -y and see if today's new kernel works better for you.
Languages using left-hand whitespace for syntax are ridiculous

DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors - are all on my foes list.

The use of crystal balls and mind reading is prohibited.

jsjames70
Posts: 9
Joined: Mon Aug 24, 2020 1:31 am

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 5:57 pm

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
Posts: 12309
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 6:28 pm

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.

User avatar
DougieLawson
Posts: 42177
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 6:41 pm

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.
Languages using left-hand whitespace for syntax are ridiculous

DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors - are all on my foes list.

The use of crystal balls and mind reading is prohibited.

hippy
Posts: 12309
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 7:11 pm

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
Posts: 9
Joined: Mon Aug 24, 2020 1:31 am

Re: Buster udev rules for ttyUSB ports broken

Mon Aug 24, 2020 9:55 pm

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
Posts: 12309
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Buster udev rules for ttyUSB ports broken

Tue Aug 25, 2020 11:09 am

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
Posts: 6
Joined: Sun Dec 06, 2020 2:48 pm

Re: Buster udev rules for ttyUSB ports broken

Sun Dec 06, 2020 3:01 pm

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 8-)

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
Posts: 9
Joined: Mon Aug 24, 2020 1:31 am

Re: Buster udev rules for ttyUSB ports broken

Mon Dec 07, 2020 4:40 pm

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
Posts: 6
Joined: Sun Dec 06, 2020 2:48 pm

Re: Buster udev rules for ttyUSB ports broken

Mon Dec 07, 2020 7:48 pm

I did, but the link is easily missed:

Reported an issue for Pi Kernel

Fuchks
Posts: 6
Joined: Sun Dec 06, 2020 2:48 pm

Re: Buster udev rules for ttyUSB ports broken

Wed Dec 09, 2020 8:41 pm

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
Posts: 9
Joined: Mon Aug 24, 2020 1:31 am

Re: Buster udev rules for ttyUSB ports broken

Wed Dec 09, 2020 8:47 pm

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.


User avatar
scruss
Posts: 4854
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON

Re: Buster udev rules for ttyUSB ports broken

Tue Dec 22, 2020 2:44 pm

Fuchks wrote:
Sun Dec 06, 2020 3:01 pm
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 8-)
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.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.
Pronouns: he/him

User avatar
ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6383
Joined: Fri Jul 29, 2011 5:36 pm

Re: Buster udev rules for ttyUSB ports broken

Wed Jan 06, 2021 11:16 am

RamaSpaceShip wrote:
Mon Aug 24, 2020 3:44 pm
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.

Return to “Raspberry Pi OS”