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: [email protected] > > 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/[email protected]/ > > 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-tasks.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
