Hi Björn,
On Sun, Oct 17, 2021 at 05:40:43PM +0000, Björn Wiberg wrote:
> Hello Salvatore!
>
> Many thanks for your reply!
>
> I’m afraid I cannot switch to unstable (or ”mix”), and if I
> understand it correctly, the unsigned kernel from backports won’t
> boot if Secure Boot is being used (which is the case on this
> server)?
Right but i expect the signed packages to appear "soonish" as well.
The signing machinery needs to be triggered once the respective
linux-signed-{amd64,i386,arm64} are there. So we can afford to wait a
couple of days yet if you are open to test the bpo kernel version.
>
> Not sure about the best way to go forward – should I attempt to
> report it upstream, or will you be doing so?
It would be best if you can report it directly, otherwise we the
kernel maintainers are the bottleneck, help from people actually able
to do tests is more than welcome :). The reason I asked to test as
well the bpo version is that this brings us nearer to mainline.
I checked possible commits in the driver, and there is not much
so I wanted to check if you can reproduce the issue still as well with
newer stable version or ideally even better with mainline directly.
https://git.kernel.org/linus/49e851de7e573529885fd1df4365e2459c6030ee
is already for fixing an issue at probe time, so not sure.
> Another option would of course be to wait and see if anything
> changes in future versions. This bug report will still be
> searchable for others, and can be resurrected if needed.
>From my point of view keeping the list of bugs
https://bugs.debian.org/src:linux shorter than longer (with bugs where
we cannot really do something -- not to hide problems, but to have
them reported where it's more sensible, in many cases its just better
to handle upstream) is better.
So with the report downstream now with Debian, there should go along
at least a reporting upstream to narrow it down at the right place.
Hope this makes sense.
When you report it upstream, let us know as well in case we miss it.
Regards,
Salvatore
