bionic/linux-raspi2: 4.15.0-1099.105 snap-debs snap:pi-kernel

[Stefan Bader]

This bug will contain status and test results related to a kernel source (or snap) as stated in the title.

For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

-- swm properties --
kernel-stable-master-bug: 1949870
phase: Certification Testing
phase-changed: Wednesday, 17. November 2021 12:56 UTC
reason:
  snap-certification-testing: Stalled -- testing FAILED
snap-name: pi-kernel
variant: snap-debs

[Paul Larson (pwlars)]

It looks like the rpi3 devices where this kernel is tested on uc18 fail to find the bluetooth controller. the pi-bluetooth snap normally takes care of the uart settings, but failed to run it's setup properly after refreshing to this kernel:
ubuntu@localhost:~$ sudo snap logs pi-bluetooth
2021-11-17T22:07:58Z pi-bluetooth.btuart[1422]: No controller attached
2021-11-17T22:07:58Z pi-bluetooth.btuart[1422]: Attaching Primary controller to /dev/ttyAMA0
2021-11-17T22:07:58Z systemd[1]: snap.pi-bluetooth.btuart.service: Main process exited, code=exited, status=1/FAILURE
2021-11-17T22:07:58Z systemd[1]: snap.pi-bluetooth.btuart.service: Failed with result 'exit-code'.
2021-11-17T22:07:58Z systemd[1]: snap.pi-bluetooth.btuart.service: Service hold-off time over, scheduling restart.
2021-11-17T22:07:58Z systemd[1]: snap.pi-bluetooth.btuart.service: Scheduled restart job, restart counter is at 5.
2021-11-17T22:07:58Z systemd[1]: Stopped Service for snap application pi-bluetooth.btuart.
2021-11-17T22:07:58Z systemd[1]: snap.pi-bluetooth.btuart.service: Start request repeated too quickly.
2021-11-17T22:07:58Z systemd[1]: snap.pi-bluetooth.btuart.service: Failed with result 'exit-code'.
2021-11-17T22:07:58Z systemd[1]: Failed to start Service for snap application pi-bluetooth.btuart.

Reverting to the previous stable kernel made it work again, and refreshing again makes it fail again, so it seems pretty easily reproducible. I noticed that rfkill with the working kernel shows both hci0 and hci1 (even though only one of these is really valid), but only an hci0 is seen by rfkill after refreshing to this kernel.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

The bug was tagged as certification-testing-failed

[Dave Jones (waveform)]

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.

[Dave Jones (waveform)]

Some additional notes: it transpired that the pi-bluetooth snap additionally needs bluetooth-control connected with the kernel change that introduced the regression. The change has been reverted for now to permit the SRU to continue, but I have applied for this connection to be automatically made (https://forum.snapcraft.io/t/auto-connection-request-pi-bluetooth/27748) so that the change can go through in future.