Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #68028 > unrolled thread

Bug#964839: Debugging results

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#964839: Debugging results Felix Dörre <debian@felixdoerre.de> - 2020-09-07 15:50 +0200
    Bug#964839: Debugging results Salvatore Bonaccorso <carnil@debian.org> - 2020-09-07 22:00 +0200
      Bug#964839: Debugging results Salvatore Bonaccorso <carnil@debian.org> - 2020-09-08 06:40 +0200

#68028 — Bug#964839: Debugging results

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?

-- 
Kind regards,
Felix Dörre

[toc] | [next] | [standalone]

#68041

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

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#68047

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web