Comment 3 for bug 1949869

Revision history for this message
Dave Jones (waveform) wrote :

Investigated this and confirmed that merely upgrading the kernel to the beta channel results in this failure (absent any other changes). The full journal output includes a few more interesting lines:

waveform@localhost:~$ sudo journalctl --unit snap.pi-bluetooth.btuart.service
-- Logs begin at Fri 2021-11-19 13:01:05 UTC, end at Fri 2021-11-19 14:55:43 UTC. --
Nov 19 14:54:41 localhost systemd[1]: Started Service for snap application pi-bluetooth.btuart.
Nov 19 14:54:44 localhost systemd[1]: snap.pi-bluetooth.btuart.service: Main process exited, code=exited, status=1/FAILURE
Nov 19 14:54:44 localhost pi-bluetooth.btuart[1023]: Failed set serial line discipline: Operation not permitted
Nov 19 14:54:44 localhost pi-bluetooth.btuart[1023]: No controller attached
Nov 19 14:54:44 localhost pi-bluetooth.btuart[1023]: Attaching Primary controller to /dev/ttyAMA0
Nov 19 14:54:44 localhost systemd[1]: snap.pi-bluetooth.btuart.service: Failed with result 'exit-code'.
Nov 19 14:54:44 localhost systemd[1]: snap.pi-bluetooth.btuart.service: Service hold-off time over, scheduling restart.
Nov 19 14:54:44 localhost systemd[1]: snap.pi-bluetooth.btuart.service: Scheduled restart job, restart counter is at 1.
Nov 19 14:54:44 localhost systemd[1]: Stopped Service for snap application pi-bluetooth.btuart.

However, as regards the "Failed set serial line discipline" error I can't find any differences in the permissions for the device node, or any of the relevant portions under /sys/class/tty/ttyAMA0. Has something changed within the PL011 kernel driver that would deny this operation?

Incidentally, this is why the hci0 device isn't showing up; btuart calls btattach to connect the UART (/dev/ttyAMA0) to the bluetooth stack which in turn produces the hci0 device. As it's failing to configure the serial port as required, the hci0 bluetooth device never shows up.