Kernel 6.12.47: CDC ACM driver fails to create /dev/ttyACM0 device nodes

[pavliha]

Description

On Raspberry Pi with kernel 6.12.47, the CDC ACM USB driver fails to properly create device nodes for USB CDC ACM devices (e.g., ArduPilot flight controllers). The driver reports successful registration in kernel logs, but the device node is never actually created, making the devices completely unusable.

Environment

• Kernel Version: 6.12.47+rpt-rpi-v8 var->green.length may be left uninitialized #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1~bookworm (2025-09-16)
• Hardware: Raspberry Pi (aarch64)
• OS: Debian Bookworm
• Affected Device: ArduPilot SpeedyBeeF405WING (USB VID:PID 1209:5741)

Symptoms

1. Kernel logs show device creation:

   [  187.540902] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
   

2. /dev/ttyACM0 does not exist:

   $ ls /dev/ttyACM*
   ls: cannot access '/dev/ttyACM*': No such file or directory

3. No sysfs entry is created:

   $ find /sys/devices -name 'ttyACM*'
   # No output - device doesn't exist in sysfs

4. Driver shows as unbound:

   $ cat /sys/kernel/debug/usb/devices | grep -A8 'Vendor=1209 ProdID=5741'
   I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=(none)

5. Device is visible in lsusb:

   Bus 001 Device 007: ID 1209:5741 Generic SpeedyBeeF405WING
   

Steps to Reproduce

1. Connect a USB CDC ACM device (e.g., ArduPilot flight controller with VID 1209, PID 5741)
2. Check kernel logs: dmesg | grep ttyACM shows device creation message
3. Check device node: ls /dev/ttyACM* shows no device
4. Check USB debug: cat /sys/kernel/debug/usb/devices shows Driver=(none)

Analysis

The cdc_acm driver appears to have a silent failure where:

• cdc_acm_probe() reports success and logs device creation
• The TTY device is never actually registered with the kernel
• No error messages are generated
• The driver never binds to the USB interface

Manual attempts to bind the driver also fail silently:

$ echo '1-1.3:1.0' | sudo tee /sys/bus/usb/drivers/cdc_acm/bind
# Kernel logs show "ttyACM0: USB ACM device" but device still doesn't exist

Impact

• All USB CDC ACM devices are completely unusable on kernel 6.12.47
• This affects: ArduPilot/PX4 flight controllers, Arduino boards, 3D printer controllers, and other CDC ACM devices
• Users report this worked fine on earlier kernels (likely 6.6.x)

Related Information

• Multiple users report USB device failures after upgrading from kernel 6.6 to 6.12
• Similar issue reported: Kernel 6.12 makes external USB3 drive disappear. #6755 (USB3 drive disappearance on 6.12)
• Other reports of USB connectivity issues on kernel 6.12

Expected Behavior

The cdc_acm driver should:

1. Bind to the USB CDC ACM interface
2. Create the /dev/ttyACM0 device node
3. Register the device in sysfs at /sys/class/tty/ttyACM0

Workaround

Using a USB-to-Serial adapter (FTDI/CH340) with different drivers works correctly on this kernel.

Request

Please investigate this regression and provide a fix or guidance on downgrading to a working kernel version (6.6.x).

[pavliha]

Additional Diagnostic Information

Hardware

• Model: Raspberry Pi Zero 2 W Rev 1.0
• Revision: 902120
• Serial: 00000000068b85e2

Software Versions

• Kernel: Linux 6.12.47+rpt-rpi-v8 var->green.length may be left uninitialized #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1~bookworm (2025-09-16)
• Compiler: aarch64-linux-gnu-gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0
• Firmware: Aug 20 2025 17:04:09 (version cd866525580337c0aee4b25880e1f5f9f674fb24)

USB Device Details (lsusb -v)

Bus 001 Device 007: ID 1209:5741 Generic SpeedyBeeF405WING
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1209 Generic
  idProduct          0x5741 
  bcdDevice            2.00
  iManufacturer           1 ArduPilot
  iProduct                2 SpeedyBeeF405WING
  iSerial                 3 240037001947333033333939
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0043
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

Kernel Messages

The only kernel message related to the device is:

[  262.394852] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device

No error messages are generated. The driver silently fails to create the device node.

Driver Binding Status

$ cat /sys/kernel/debug/usb/devices | grep -A10 'Vendor=1209 ProdID=5741'
P:  Vendor=1209 ProdID=5741 Rev= 2.00
S:  Manufacturer=ArduPilot
S:  Product=SpeedyBeeF405WING
S:  SerialNumber=240037001947333033333939
C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=(none)
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

Driver=(none) confirms the driver never actually binds, despite the kernel log message claiming success.

Previous Working Version

The user reports this worked fine on an earlier kernel, most likely 6.6.x, before the system was upgraded to 6.12.47.

[pavliha]

Reproducibility

This issue is 100% reproducible and consistent (unlike #6755 which became intermittent):

• ❌ FAILS every single time on kernel 6.12.47 - tested across multiple:

  • Device reconnections
  • System reboots
  • Manual driver binding attempts

• ✅ User confirmed it worked on earlier kernel versions

• 🔄 Consistently reproducible behavior:

  • Kernel logs always show "ttyACM0: USB ACM device"
  • /dev/ttyACM0 never gets created
  • Driver always shows as unbound: Driver=(none)
  • No error messages are ever generated

This is NOT an intermittent/environmental issue - it's a reliable regression that can be consistently reproduced for investigation.

[P33M]

Don't use LLMs to generate bug reports. Lots of cruft here that's not relevant.

You're using Bookworm which is no longer supported, but there have been no other reports of USB CDC devices not being functional on either Trixie or Bookworm.

Do you have a userspace process that is unbinding the interface and/or claiming it? Post the output of sudo udevadm monitor when hotplugging the ACM device.

[6by9]

The Raspberry Pi DebugProbe also uses the cdc_acm driver for the UART.

Running 6.12.47 on a Pi4, on connecting a debug probe gives me the kernel logs

[   38.359372] usb 1-1.2: new full-speed USB device number 7 using dwc2
[   38.473683] usb 1-1.2: New USB device found, idVendor=2e8a, idProduct=000c, bcdDevice= 1.01
[   38.473688] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   38.473690] usb 1-1.2: Product: Debug Probe (CMSIS-DAP)
[   38.473692] usb 1-1.2: Manufacturer: Raspberry Pi
[   38.473694] usb 1-1.2: SerialNumber: E6616407E357C32A
[   38.486917] cdc_acm 1-1.2:1.1: ttyACM0: USB ACM device
[   38.486940] usbcore: registered new interface driver cdc_acm
[   38.486942] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

and /dev/ttyACM0 exists. So it's not a generic issue with USB CDC devices.
(Whilst a Pi4 does have the VLI805 for USB3 which the Pi02 does not, this happens to be connected via the USB-C power connector and a dock, so is connected via the dwc2 USB controller).