- Package:
- linux-image-amd64
- Source:
- linux-image-amd64
- Description:
- Linux for 64-bit PCs (meta-package)
- Submitter:
- Michael Gordon
- Date:
- 2025-01-01 07:03:02 UTC
- Severity:
- normal
- Tags:
Version: 6.7.12-1 Hardware: Huananzhi F8D-Plus (C612 Intel Chipset), 2*Xeon 2680v4, 128 GB RAM Raid controller: Adaptec ASR-5805Z Hello! I've encountered an issue booting up Debian Testing with the latest kernel. The system reports something about kernel panic caused by aacraid module, then hangs completely during fsck step. Information about the installed system is in the attached .txt file. Note that hardware is different, because the SSD with Debian Testing has been extracted from the server for investigation. Using the kernel parameters "pci=nocrs single" I was able to boot into emergency mode and see the error messages related to kernel panic. Photos attached. Pulling the RAID controller out of the PCI-E slot restores normal boot. I tried different linux distributions to check hypothesis about regression in the latest kernel. Results are shown below. Distribution Kernel version Result Debian Testing KDE Linux *6.6.15*-amd64 #1 Debian 6.6.15-2 *Kernel panic* messages, boot hangs at fsck step. Kubuntu 24.04 LTS Linux KubuntuPortable *6.8.0*-36-generic #36-Ubuntu SMP PREEMPT_DYNAMIC Mon Jun 10 10:49:14 UTC 2024 x86_64 GNU/Linux *Kernel panic* messages, boot hangs at fsck step. Fedora Workstation Live x86_64-40-1.14 Linux localhost-live *6.8.5*-301.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 11 20:00:10 UTC 2024 x86_64 GNU/Linux *Boot hangs*. Linux Mint 21.1 Xfce 64-bit Linux mint *5.15.0*-56-generic #62-Ubuntu SMP Tue Nov 19:54:14 UTC 2022 x86_64 GNU/Linux *Normal boot*, ext4 partition on the RAID5 array is accessible. Debian Stable KDE Live Linux debian *6.1.0*-22-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.94-1 (2024-06-21) x86_64 GNU/Linux *Normal boot,* ext4 partition on the RAID5 array is accessible. Windows Server 2016 NA *Normal boot*. Adaptec Storage Manager reports optimal condition for the RAID5 array. *No errors reported for HDDs*. Ext4 partition on the array is accessible from Windows. Expected behavior: normal boot Actual result: system hangs during boot As a workaround, I installed kernel 6.1.0 from the Bookworm repository. IMG_20240628_180225.jpg <https://drive.google.com/file/d/1gw4LeXFP1BzqX1mTws8AVuhEE1Xjg-Sv/view?usp=drive_web> IMG_20240628_180411.jpg <https://drive.google.com/file/d/1oQPH23vhCDgeDuYzpHqVSvcv-okzAkY-/view?usp=drive_web> IMG_20240628_180419.jpg <https://drive.google.com/file/d/1g89ljiHNS5_I5cI-Z-1kitge_tJY9V-o/view?usp=drive_web> Gordon Mikhail, bioinformatician Genetics of Plant-Microbe Interactions lab | ARRIAM Guar Physiological genetics lab | VIR
You wrote: [...] There are (at least) 2 bugs here: 1. Something is preventing aacraid and ehci-hcd from allocating DMA buffers: "ehci-pci 0000:00:1a.0: init 0000:00:1a.0 fail, -12" "aacraid: unable to create mapping." 2. aacraid then double-frees a chunk of memory while handling the failure, causing the panic: "kernel BUG at mm/slub.c:448!" I'm attaching a patch which should fix bug #2, which may help to get more information about bug #1. In principle you should be able to test this by following the instructions at <https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4> but currently the test-patches script has not been updated along with the package and will take a lot more time and space than it should. So instead I would suggest building a custom kernel based on the Debian configuration, following the instructions at <https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-building> and applying this patch before you run "make clean". Let us know if you have any difficulty with this. If the system is able to boot with a patched kernel, please send the full kernel log. Ben.
Just FYI, I had the exact same issue as the reporter, and it turned out that one of my kernel commandline args (previously set for a no-longer present SATA controller) was causing it. I'm not sure exactly which it was, but removing the following args fixed it. libata.noacpi=1 pci=assign-busses,ecrc=on,realloc,hpmemsize=512M,nocrs
hi, As we have seen no followup on this, we are closing the bug report (for now). In case you can retest with the above, can you please reopen the bug and removing the moreinfo tag. Regards, Salvatore
hi, As we have seen no followup on this, we are closing the bug report (for now). In case you can retest with the above, can you please reopen the bug and removing the moreinfo tag. Regards, Salvatore
Dear all, I couldn't test Ben's patch yet, because the server machine had to be online. Now it is possible to pull the server out of rack for several days. I'll check if the patch is working and let you know. Since I've never messed with linux kernel compilation before, I'm relying on this guide https://passthroughpo.st/patch-kernel-debian . It suggests using a *patch -p1* instead of *debian/bin/test-patches* , *quilt *or *dquilt*. Or maybe it is easier to add two lines by hand. I've also noticed a Greg's message <gregkh@linuxfoundation.org> suggesting to apply this patch to all kernel versions including 5.15. Not sure if the result of the patch could be observed on versions 5.15.* Gordon Mikhail, bioinformatician Genetics of Plant-Microbe Interactions lab | ARRIAM Guar Physiological genetics lab | VIR On Sat, 24 Aug 2024 at 09:55, Salvatore Bonaccorso <carnil@debian.org> wrote:
Dear all, I couldn't test Ben's patch yet, because the server machine had to be online. Now it is possible to pull the server out of rack for several days. I'll check if the patch is working and let you know. Since I've never messed with linux kernel compilation before, I'm relying on this guide https://passthroughpo.st/patch-kernel-debian . It suggests using a *patch -p1* instead of *debian/bin/test-patches* , *quilt *or *dquilt*. Or maybe it is easier to add two lines by hand. I've also noticed a Greg's message <gregkh@linuxfoundation.org> suggesting to apply this patch to all kernel versions including 5.15. Not sure if the result of the patch could be observed on versions 5.15.* Gordon Mikhail, bioinformatician Genetics of Plant-Microbe Interactions lab | ARRIAM Guar Physiological genetics lab | VIR On Sat, 24 Aug 2024 at 09:55, Salvatore Bonaccorso <carnil@debian.org> wrote:
Remember that the patch I wrote is only intended to fix the crash (bug 2). The probe failure of aacraid (bug 1) is still a mystery. The Debian Kernel Handbook <https://kernel-team.pages.debian.net/kernel-handbook/> is an official guide maintained by the Debian kernel team (mostly me), and I would recommend that over the blog you found. The problem with test-patches that I mentioned earlier has been fixed. [...] The crash bug was introduced way back in Linux 2.6.15, which is why my fix was applied to all supported versions. Ben.
Hi Michael, Ben's patch to fix the crash bug was applied in 6.11-rc6 and down the road to various stable series (in particular it is in v6.10.8 and 6.1.108). Do you still see Bug #1? I'm closing the bug but please do reopen the bug and rmeoving the moreinfo tag if you still encounter the issue. In this case you please attach updated information, fresh bootlogs? Regards, Salvatore
Hi Michael, Ben's patch to fix the crash bug was applied in 6.11-rc6 and down the road to various stable series (in particular it is in v6.10.8 and 6.1.108). Do you still see Bug #1? I'm closing the bug but please do reopen the bug and rmeoving the moreinfo tag if you still encounter the issue. In this case you please attach updated information, fresh bootlogs? Regards, Salvatore