XPost: linux.debian.bugs.dist   
   From: carnil@debian.org   
      
   Control: tags -1 + upstream   
   Control: tags -1 - moreinfo   
      
   Hi Peter,   
      
   On Thu, Nov 13, 2025 at 01:14:37PM +0000, Peter Morrow wrote:   
   > Hi Salvatore,   
   >   
   > Thank you for your reply and maintainership!   
      
   Welcome :)   
      
   > On Thu, 13 Nov 2025 at 06:20, Salvatore Bonaccorso  wrote:   
   > >   
   > > Control: tags -1 + moreinfo   
   > >   
   > > Hi Peter,   
   > >   
   > > Thanks a lot for the report.   
   > >   
   > > On Wed, Nov 12, 2025 at 10:56:38PM +0000, Peter Morrow wrote:   
   > > > Package: src:linux   
   > > > Version: 6.12.57-1   
   > > > Severity: important   
   > > > X-Debbugs-Cc: pdmorrow@gmail.com   
   > > >   
   > > > Dear Maintainer,   
   > > >   
   > > > I'm seeing a kernel crash quite soon after boot on a debian trixie based   
   > > > system running 6.12.57+deb13-amd64, unfortunately the kernel panics   
   before   
   > > > I can access the system to gather more information. Thus I'll provide   
   details   
   > > > of the system using a previously known good version. The panic is   
   happening   
   > > > 100% of the time unfortunately. I have access to the serial console   
   however   
   > > > so can enable any required verbose logging during boot if necessary.   
   > > >   
   > > > Crucially the crash is not seen with kernel version 6.12.41+deb13-amd64   
   with the   
   > > > same userspace. We had pinned to that version until very recently to in   
   order   
   > > > to work around https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109676   
   > > >   
   > > > I'm running a dpdk application here (VPP) on Azure, VM form factor is a   
   > > > "Standard DS3 v2 (4 vcpus, 14 GiB memory)".   
   > > >   
   > > > The only relevant upstream commit in this area (as far as I can see) is:   
   > > >   
   > > > https://lore.kernel.org/linux-hyperv/1bb599ee-fe28-409d-b4   
   0-2fc086268936@linux.microsoft.com/   
   > > >   
   > > > The comment regarding avoiding races at start adds a bit more weight   
   behind this   
   > > > hunch, though it's only a hunch as I am most definitely nowhere near an   
   expert   
   > > > in this area.   
   > >   
   > > I have a couple of questions. As you pinned 6.12.41+deb13-amd64, but   
   > > this was not the most recent kernel for trixie, can you confirm you   
   > > are seeing or not seeing the issue as well with 6.12.48-1 (this was   
   > > released via security update).   
   >   
   > I installed linux-image-6.12.48+deb13-amd64 and can confirm it's working   
   fine,   
   > no crashes on boot.   
      
   Thanks for doing so.   
      
   > >   
   > > This would help narrowing the range further.   
   > >   
   > > The commit b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of   
   > > interrupt mask") was backported to 6.12.53, so if you do not see the   
   > > problem with 6.12.48-1 then this further weight for the offending   
   > > commit.   
   > >   
   > > Secondly: Would you have either the possibility to bisect the changes   
   > > between the given range of good/bad kernel to isolate the offending   
   > > commit with a proof? Alternatively could you build 6.12.57-1 with the   
   > > commit reverted only? (you can use the debian/bin/test-patches script   
   > > for that, instructions in   
   > > https://kernel-team.pages.debian.net/kernel-handbook/ch-comm   
   n-tasks.html#id-1.6.6.4,   
   > > let me know though if you need help to make the patch to be used).   
   >   
   > I was able to build 6.12.57-1 with b15b7d2a1b09 reverted using test-patches   
   and   
   > confirm that the kernel does not panic on boot. So it looks fairly   
   > conclusive to me that   
   > b15b7d2a1b09 is the culprit for me.   
      
   Ok that is already a good result thank you. The next step is to   
   forward it upstream, will do shortly, still the following point:   
      
   > >   
   > > Could you additionally (just to test, then revert back to the regular   
   > > trixie kernel series) test the 6.17.7-2 kernel from unstable? This one   
   > > would include as well a backport of b15b7d2a1b09.   
   >   
   > Would you still like this test done? I suspect it's not required now with the   
   > data we have on b15b7d2a1b09.   
      
   Not necessarily if it is a problem for deploying it for your   
   enviornment. If you can, then we have the benefit to confirm to   
   upstream that indeed it is still affecting more recent versions, and   
   unlikely that some other changes inbetween make the issue disapear   
   (even if there is no commit with fixes tag to the orginal commit).   
      
   So not necessary, but still helpful to confirm that even newer   
   branches are affected.   
      
   I will preapre the report upstream, and upstream might have questions   
   back to you.   
      
   Regards,   
   Salvatore   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)