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

Bug #1949869 reported by Stefan Bader
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Kernel SRU Workflow
In Progress
Medium
Unassigned
Snap-certification-testing
Incomplete
Medium
Canonical Hardware Certification
Snap-prepare
Fix Released
Medium
Canonical Kernel Team
Snap-release-to-beta
Fix Released
Medium
Canonical Kernel Team
Snap-release-to-candidate
New
Medium
Canonical Kernel Team
Snap-release-to-edge
Fix Released
Medium
Canonical Kernel Team
Snap-release-to-stable
New
Medium
Canonical Kernel Team

Bug Description

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

Stefan Bader (smb)
tags: added: kernel-release-tracking-bug-live
description: updated
tags: added: kernel-sru-cycle-2021.11.08-1
description: updated
tags: added: kernel-sru-derivative-of-1949870
Changed in kernel-sru-workflow:
status: New → Confirmed
importance: Undecided → Medium
Changed in kernel-sru-workflow:
status: Confirmed → Triaged
summary: - bionic/linux-raspi2: <version to be filled> snap-debs
+ bionic/linux-raspi2: <version to be filled> snap-debs snap:pi-kernel
description: updated
Changed in kernel-sru-workflow:
status: Triaged → In Progress
summary: - bionic/linux-raspi2: <version to be filled> snap-debs snap:pi-kernel
+ bionic/linux-raspi2: 4.15.0-1099.105 snap-debs snap:pi-kernel
description: updated
description: updated
description: updated
description: updated
description: updated
Revision history for this message
Paul Larson (pwlars) wrote :

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.

tags: added: certification-testing-failed
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Certification Testing FAILURE

The bug was tagged as certification-testing-failed

description: updated
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.

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

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers