XPost: linux.debian.bugs.dist   
   From: pdmorrow@gmail.com   
      
   Hi Salvatore,   
      
   On Thu, 13 Nov 2025 at 13:57, Salvatore Bonaccorso  wrote:   
   >   
   > 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-   
   430-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-co   
   mon-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.   
      
   It was straight forward to try out, Interestingly I am not seeing the   
   panic on 6.17.7-2:   
      
   gnos@vEdgeOlder:~$ uname -a   
   Linux vEdgeOlder 6.17.7+deb14+1-amd64 #1 SMP PREEMPT_DYNAMIC Debian   
   6.17.7-2 (2025-11-06) x86_64 GNU/Linux   
   gnos@vEdgeOlder:~$   
      
   I also then retried 6.12.57-1 to make sure I am not hallucinating   
   today, and it indeed still panic'd on boot:   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)