Hi Felix, On Mon, Sep 07, 2020 at 09:55:02PM +0200, Salvatore Bonaccorso wrote: > Hi Felix, > > Many thanks for your debugging work! > > On Mon, Sep 07, 2020 at 03:39:25PM +0200, Felix Dörre wrote: > > Hi, > > > > Thanks for the notes. I did not install the 5.8.7-kernel because it did not > > automatically arrive via apt (and I am not sure which packages exactly I > > should install). So I went directly into trying to bisecting: > > > > Bisecting did not help at all. The first few kernels generated by the > > commits indicated by bisect did not boot at all (loading the initramfs > > hangs). So as I already had a linux kerrnel I tried compiling the versions > > that I tested previously (just to see if they would boot and show the same > > problem): 5.6.14 and 5.7.6. That worked. > > > > So I went with the 5.7.6-kernel and added printk-calls to understand what > > happens: > > > > The mechanism to send the notifications on PM_SUSPEND allows many modules to > > register handlers. Adding prints there showed, that the handler was not > > "completely" broken. Handlers from other modules were invoked. However the > > mechanism that allows handlers to "break" the notification-chain and > > preventing all subsequent handlers to be executed. This is done, by > > returning "NOTIFY_STOP" from the handler. Searching the diff between 5.6.14 > > and 5.7.6 for that constant showed a suspicious line at the end of > > hci_suspend_notifier in net/bluetooth/hci_core.c: > > > > return ret ? notifier_from_errno(-EBUSY) : NOTIFY_STOP; > > > > This line was introduced with 9952d90ea2885d7cbf80cd233f694f09a9c0eaec > > (which is in 5.7.6 and not in 5.6.14). > > > > The handler was modified and improved upon between 5.7.6 and 5.8.7, but is > > still present in 5.8.7, where the handler always returns NOTIFY_STOP. In > > master the bug seems resolved, as there the handler returns (correctly) > > NOTIFY_DONE. The fix was made in 24b065727ceba53cc5bec0e725672417154df24f. > > Currently that commit is only contained in the tags: v5.9-rc1, v5.9-rc2, > > v5.9-rc3. To verify that this is indeed the problem I took the 5.7.6-kernel > > and adjusted: > > > > return ret ? notifier_from_errno(-EBUSY) : NOTIFY_STOP; > > > > to > > > > > > return ret ? notifier_from_errno(-EBUSY) : NOTIFY_DONE; > > > > which gave me a working 5.7.6-kernel. > > > > Will you try to backport a fix or do I just need to wait until 5.9 for a > > kernel that might handle suspend properly again? > > I cherry-picked the commit and applied it to our packaging branch for > the next upload to unstable: > https://salsa.debian.org/kernel-team/linux/-/commit/a00d070d0498b28b5236420faf976d46fdb74362
It has additionally been queued for v5.8.y stable series: https://lore.kernel.org/stable/20200907222024.GP8670@sasha-vm/T/#t Regards, Salvatore
