XPost: linux.debian.bugs.dist   
   From: carnil@debian.org   
      
   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-b430-2   
   c086268936@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).   
      
   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-common-t   
   sks.html#id-1.6.6.4,   
   let me know though if you need help to make the patch to be used).   
      
   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.   
      
   Regards,   
   Salvatore   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)