Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
I sent the requested report. And indeed received a new patch to be tested. In progress... Le 02/04/2023 à 10:30, Diederik de Haas a écrit : On Sunday, 2 April 2023 00:24:26 CEST Diederik de Haas wrote: 2) The commit that Bjørn identified also contained a "Link:" tag: https://lore.kernel.org/r/20230105041059.39366-1-kvija...@amd.com The best thing to do is to respond to that thread and explain the issue you ran into. If you feel 'uncomfortable' or something like that, we can do this part too. If/when a new patch arrives, we will need your help in testing that though.
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
On Sunday, 2 April 2023 00:24:26 CEST Diederik de Haas wrote: > 2) The commit that Bjørn identified also contained a "Link:" tag: > https://lore.kernel.org/r/20230105041059.39366-1-kvija...@amd.com > > The best thing to do is to respond to that thread and explain the issue you > ran into. If you feel 'uncomfortable' or something like that, we can do this part too. If/when a new patch arrives, we will need your help in testing that though. signature.asc Description: This is a digitally signed message part.
Processed: Re: Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Processing control commands: > tag -1 upstream Bug #1033732 [src:linux] linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message Added tag(s) upstream. -- 1033732: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033732 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Control: tag -1 upstream On Saturday, 1 April 2023 22:47:35 CEST Guy Durrieu wrote: > I just finished to build the patched kernel. Well done! > After installing it, the system 6.1.0-7 boots again and run fine. > Thus the source was well identified by Bjørn Mork. This is great :-) > I just had problems trying to install > linux-headers-6.1.0-7-amd64_6.1.20-1a~test_amd64.deb, for dependencies > reasons not so clear for me. It is not mandatory anyway. Yeah, there are some improvements to be made for the procedure. > Thanks a lot to all of you for your help ! You're welcome and thanks for doing this. > What next ? 1) Now you get to brag to all your family and friends that you build a Linux kernel :-D 2) The commit that Bjørn identified also contained a "Link:" tag: https://lore.kernel.org/r/20230105041059.39366-1-kvija...@amd.com The best thing to do is to respond to that thread and explain the issue you ran into. At the bottom of the page you can find instructions on how to do that. The To/CC list is quite large, but don't be alarmed by that, that's rather common with kernel development. It's probably a good idea to add 1033...@bugs.debian.org to that list. The instructions also contain this part: "Avoid top-posting and favor interleaved quoting" That's what I've been doing and is considered rather important, so try your best to do that too. In your reply you should put the following things: 1) Your system worked find with kernel 6.1.15, but stopped booting after upgrading to 6.1.20 and resulted in a kernel panic 2) Copy the part between "" from your initial report so that it shows the kernel panic, your motherboard info and the stack trace 3) Indicate that Bjørn identified ce7d894bed1a539a8d6cff42f6f78f9db0c9c26b from the linux-6.1.y branch as the likely culprit 4) After building a 6.1.20 kernel with just that commit reverted, your system booted normally again. 5) You reported that all to https://bugs.debian.org/1033732 and were asked to report the issue 'upstream' (which is what that mail is). It could be that they'll ask you to test a patch. If it's just a simple/single patch you should be able to try that with the same procedure as you've already done, but replace the patch I provided with one they provide. If you don't understand what they're asking or f.e. the kernel build is/seems too complicated, feel free to ask for help in (just) this bug. Good luck and thanks in advance :-) signature.asc Description: This is a digitally signed message part.
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Hello everybody, I just finished to build the patched kernel. After installing it, the system 6.1.0-7 boots again and run fine. Thus the source was well identified by Bjørn Mork. I just had problems trying to install linux-headers-6.1.0-7-amd64_6.1.20-1a~test_amd64.deb, for dependencies reasons not so clear for me. It is not mandatory anyway. Thanks a lot to all of you for your help ! What next ? Best regards. -- Guy Le 01/04/2023 à 19:48, Guy Durrieu a écrit : Thanks for your help ! That was more or less my conclusion, but it would indeed be useful to clarify that 4.1 and 4.21. are mutually exclusive. And I must admit that the # vs $ steps had escaped me :( Best regards. -- Guy Le 01/04/2023 à 18:56, Diederik de Haas a écrit : On Saturday, 1 April 2023 17:44:21 CEST Guy Durrieu wrote: I am in trouble... I first did "Obtaining the kernel source", and at the end I got a /root/linux-source-6.1/ directory. Then I did "Rebuilding official Debian kernel packages" and "Preparation", and then I got among others a /root/linux-source-6.1/linux-6.1.20 the content of which is similar to the parent one, and where I can find, by the way, a debian directory. It seems strange to me, is it correct? No, this is not correct. No worries though as this is a great way to learn how we can improve the documentation :-) With "Preparation" I meant paragraph 4.2.1 and you don't need to follow 4.1. Also worth noting is that command prefixed by `#` should be done as root, but the commands prefixed by `$` should be done as (normal) user. So this is what you need to do: # apt-get install build-essential fakeroot # apt-get build-dep linux While we're 'root', do this too: # apt-get install devscripts And then (as user): $ apt-get source linux $ cd linux-6.1.20 If you then do ``ls -lh`` you will see a ``debian`` directory. So now you can run this: $ bash debian/bin/test-patches And now it should build a patched kernel for you. If it is correct, in what order to do the patches (debian patches and the revert patch)? When you look at the output of the ``apt-get source linux`` you'll see it download the linux source code and (automatically) applies the debian patches which are always applied when building a debian kernel. This is excluding the patch I send earlier, but that gets applied when you run the ``bash debian/bin/test-patches`` command. HTH, Diederik
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Thanks for your help ! That was more or less my conclusion, but it would indeed be useful to clarify that 4.1 and 4.21. are mutually exclusive. And I must admit that the # vs $ steps had escaped me :( Best regards. -- Guy Le 01/04/2023 à 18:56, Diederik de Haas a écrit : On Saturday, 1 April 2023 17:44:21 CEST Guy Durrieu wrote: I am in trouble... I first did "Obtaining the kernel source", and at the end I got a /root/linux-source-6.1/ directory. Then I did "Rebuilding official Debian kernel packages" and "Preparation", and then I got among others a /root/linux-source-6.1/linux-6.1.20 the content of which is similar to the parent one, and where I can find, by the way, a debian directory. It seems strange to me, is it correct? No, this is not correct. No worries though as this is a great way to learn how we can improve the documentation :-) With "Preparation" I meant paragraph 4.2.1 and you don't need to follow 4.1. Also worth noting is that command prefixed by `#` should be done as root, but the commands prefixed by `$` should be done as (normal) user. So this is what you need to do: # apt-get install build-essential fakeroot # apt-get build-dep linux While we're 'root', do this too: # apt-get install devscripts And then (as user): $ apt-get source linux $ cd linux-6.1.20 If you then do ``ls -lh`` you will see a ``debian`` directory. So now you can run this: $ bash debian/bin/test-patches And now it should build a patched kernel for you. If it is correct, in what order to do the patches (debian patches and the revert patch)? When you look at the output of the ``apt-get source linux`` you'll see it download the linux source code and (automatically) applies the debian patches which are always applied when building a debian kernel. This is excluding the patch I send earlier, but that gets applied when you run the ``bash debian/bin/test-patches`` command. HTH, Diederik
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Thanks for your help ! That was more or less my conclusion, but it would indeed be useful to clarify that 4.1 and 4.21. are mutually exclusive. And I must admit that the # vs $ steps had escaped me :( Best regards. -- Guy Le 01/04/2023 à 18:56, Diederik de Haas a écrit : On Saturday, 1 April 2023 17:44:21 CEST Guy Durrieu wrote: I am in trouble... I first did "Obtaining the kernel source", and at the end I got a /root/linux-source-6.1/ directory. Then I did "Rebuilding official Debian kernel packages" and "Preparation", and then I got among others a /root/linux-source-6.1/linux-6.1.20 the content of which is similar to the parent one, and where I can find, by the way, a debian directory. It seems strange to me, is it correct? No, this is not correct. No worries though as this is a great way to learn how we can improve the documentation :-) With "Preparation" I meant paragraph 4.2.1 and you don't need to follow 4.1. Also worth noting is that command prefixed by `#` should be done as root, but the commands prefixed by `$` should be done as (normal) user. So this is what you need to do: # apt-get install build-essential fakeroot # apt-get build-dep linux While we're 'root', do this too: # apt-get install devscripts And then (as user): $ apt-get source linux $ cd linux-6.1.20 If you then do ``ls -lh`` you will see a ``debian`` directory. So now you can run this: $ bash debian/bin/test-patches And now it should build a patched kernel for you. If it is correct, in what order to do the patches (debian patches and the revert patch)? When you look at the output of the ``apt-get source linux`` you'll see it download the linux source code and (automatically) applies the debian patches which are always applied when building a debian kernel. This is excluding the patch I send earlier, but that gets applied when you run the ``bash debian/bin/test-patches`` command. HTH, Diederik
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
On Saturday, 1 April 2023 17:44:21 CEST Guy Durrieu wrote: > I am in trouble... I first did "Obtaining the kernel source", and at the > end I got a /root/linux-source-6.1/ directory. > > Then I did "Rebuilding official Debian kernel packages" and > "Preparation", and then I got among others a > /root/linux-source-6.1/linux-6.1.20 the content of which is similar to > the parent one, and where I can find, by the way, a debian directory. > > It seems strange to me, is it correct? No, this is not correct. No worries though as this is a great way to learn how we can improve the documentation :-) With "Preparation" I meant paragraph 4.2.1 and you don't need to follow 4.1. Also worth noting is that command prefixed by `#` should be done as root, but the commands prefixed by `$` should be done as (normal) user. So this is what you need to do: # apt-get install build-essential fakeroot # apt-get build-dep linux While we're 'root', do this too: # apt-get install devscripts And then (as user): $ apt-get source linux $ cd linux-6.1.20 If you then do ``ls -lh`` you will see a ``debian`` directory. So now you can run this: $ bash debian/bin/test-patches And now it should build a patched kernel for you. > If it is correct, in what order to do the patches (debian patches and > the revert patch)? When you look at the output of the ``apt-get source linux`` you'll see it download the linux source code and (automatically) applies the debian patches which are always applied when building a debian kernel. This is excluding the patch I send earlier, but that gets applied when you run the ``bash debian/bin/test-patches`` command. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
I am in trouble... I first did "Obtaining the kernel source", and at the end I got a /root/linux-source-6.1/ directory. Then I did "Rebuilding official Debian kernel packages" and "Preparation", and then I got among others a /root/linux-source-6.1/linux-6.1.20 the content of which is similar to the parent one, and where I can find, by the way, a debian directory. It seems strange to me, is it correct? If it is correct, in what order to do the patches (debian patches and the revert patch)? Thanks in advance for your help ! Best regards. -- Guy Le 01/04/2023 à 16:55, Diederik de Haas a écrit : > > On April 1, 2023 4:31:49 PM GMT+02:00, Guy Durrieu > wrote: >> Thanks for your help ! >> >> There is something not clear for me in the section 4.2.2. Simple >> patching and building... >> >> I ran apt-get install devscripts but I can't find any debian >> directory nor patches. Is it sufficient to apply the patch given by >> Diederik de Haas ? > > I'm guessing you forgot to do the Preparation from 4.2.1 > >> Le 01/04/2023 à 15:28, Salvatore Bonaccorso a écrit : >>> Hi, >>> >>> On Sat, Apr 01, 2023 at 11:51:38AM +0200, Guy Durrieu wrote: Hello, This is something I have never done, but I can try. However some time ago, for solving a previous issue, a guy from Debian compiled for me an unofficial release including the patch to be tested, along with some credentials. I know this is not the recommended procedure :) but it worked. >>> Seems there was a race on responding. If you look at the >>> documentation referenced by Diederik there are instructions on >>> how to do it with a single patch applied on top. If you run into >>> trouble let us know though. >>> >>> Regards, Salvatore >> >
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
On April 1, 2023 4:31:49 PM GMT+02:00, Guy Durrieu wrote: >Thanks for your help ! > >There is something not clear for me in the section 4.2.2. Simple patching and >building... > >I ran apt-get install devscripts but I can't find any debian directory nor >patches. Is it sufficient to apply the patch given by Diederik de Haas ? I'm guessing you forgot to do the Preparation from 4.2.1 >Le 01/04/2023 à 15:28, Salvatore Bonaccorso a écrit : >> Hi, >> >> On Sat, Apr 01, 2023 at 11:51:38AM +0200, Guy Durrieu wrote: >>> Hello, >>> >>> This is something I have never done, but I can try. >>> >>> However some time ago, for solving a previous issue, a guy from Debian >>> compiled for me an unofficial release including the patch to be tested, >>> along with some credentials. I know this is not the recommended procedure :) >>> but it worked. >> Seems there was a race on responding. If you look at the documentation >> referenced by Diederik there are instructions on how to do it with a >> single patch applied on top. If you run into trouble let us know >> though. >> >> Regards, >> Salvatore > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Thanks for your help ! There is something not clear for me in the section 4.2.2. Simple patching and building... I ran apt-get install devscripts but I can't find any debian directory nor patches. Is it sufficient to apply the patch given by Diederik de Haas ? Regards. -- Guy Le 01/04/2023 à 15:28, Salvatore Bonaccorso a écrit : Hi, On Sat, Apr 01, 2023 at 11:51:38AM +0200, Guy Durrieu wrote: Hello, This is something I have never done, but I can try. However some time ago, for solving a previous issue, a guy from Debian compiled for me an unofficial release including the patch to be tested, along with some credentials. I know this is not the recommended procedure :) but it worked. Seems there was a race on responding. If you look at the documentation referenced by Diederik there are instructions on how to do it with a single patch applied on top. If you run into trouble let us know though. Regards, Salvatore
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Hi, On Sat, Apr 01, 2023 at 11:51:38AM +0200, Guy Durrieu wrote: > Hello, > > This is something I have never done, but I can try. > > However some time ago, for solving a previous issue, a guy from Debian > compiled for me an unofficial release including the patch to be tested, > along with some credentials. I know this is not the recommended procedure :) > but it worked. Seems there was a race on responding. If you look at the documentation referenced by Diederik there are instructions on how to do it with a single patch applied on top. If you run into trouble let us know though. Regards, Salvatore
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Salvatore Bonaccorso writes: > AFAIK there is no commit upstream with fixes tag on that commit. But > Bjorn suspects that might be the suspicious commit introducing the > issue. Yes, I noticed that, so I could very well be wrong... But it stood out as the only change to any x86 IOAPIC stuff since Linux 6.1.0-6-amd64. That's of course not any guarantee. But worth testing. Bjørn
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Hello, This is something I have never done, but I can try. However some time ago, for solving a previous issue, a guy from Debian compiled for me an unofficial release including the patch to be tested, along with some credentials. I know this is not the recommended procedure :) but it worked. Best regards, -- Guy Le 01/04/2023 à 11:00, Salvatore Bonaccorso a écrit : Control: tags -1 + moreinfo Hi Guy, On Sat, Apr 01, 2023 at 10:09:09AM +0200, Guy Durrieu wrote: Hello, Thanks for your answer ! Before receiving it I tried to update my BIOS to the last available version (F51h). Without any effect. I am not sure I understand everything that is said in your link, except I must wait for the next updates... Right ? AFAIK there is no commit upstream with fixes tag on that commit. But Bjorn suspects that might be the suspicious commit introducing the issue. Would you be able to build a kernel 6.1.20 with that patch reverted on top and see if it resolved your issue? Regards, Salvatore
Processed: Re: Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Processing control commands: > tags -1 + moreinfo Bug #1033732 [src:linux] linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message Added tag(s) moreinfo. -- 1033732: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033732 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Control: tags -1 + moreinfo Hi Guy, On Sat, Apr 01, 2023 at 10:09:09AM +0200, Guy Durrieu wrote: > Hello, > > Thanks for your answer ! > > Before receiving it I tried to update my BIOS to the last available version > (F51h). Without any effect. > > I am not sure I understand everything that is said in your link, except I > must wait for the next updates... Right ? AFAIK there is no commit upstream with fixes tag on that commit. But Bjorn suspects that might be the suspicious commit introducing the issue. Would you be able to build a kernel 6.1.20 with that patch reverted on top and see if it resolved your issue? Regards, Salvatore
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
On Saturday, 1 April 2023 10:09:09 CEST Guy Durrieu wrote:
> Le 01/04/2023 à 09:25, Bjørn Mork a écrit :
> > Guy Durrieu writes:
> >>
> >> [ 0.117782] Kernel panic — not syncing: timer doesn’t work through
> >> Interrupt-
> >> remapped I0-APIC
> >> [ 0.117848] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-7-and64 #1
> >> Debian
> >> 6.1.20-1
> >> [ 0.117913] Hardware name: Gigabyte Technology Co., Ltd. ABS50M-Gaming
> >> 3/AB350M-Gaming 3-CF, BIOS F50d 07/02/2020
> >> [ 0.117982] Call Trace:
> >> [ 0.118634]
> >> [ 0.118685] dump_stack_lvl+0x44/0x5c
> >> [ 0.118143] panic+0x118/0x2ed
> >> [ 0.118198] panic_if_irq_remap.cold+0x5/0x5
> >> [ 0.118256] setup_I0_APIC+0x3db/0x64b
> >> [ 0.118313] ? _raw_spin_unlock_irqrestore+0x23/0x40
> >> [ 0.118372] ? clear_IO_APIC_pin+0x169/0x240
> >> [ 0.118429] apic_intr_node_init+0x101/0x106
> >> [ 0.118485] x86_late_time_init+0x20/0x34
> >> [ 0.118542] start_kerne1+0x667/0x727
> >> [ 0.118598] secondary_startup_64_no_verify+0xe5/0xeb
> >> [ 0.118658]
> >> [ 0.118711] ---[ end Kernel panic - not syncing: timer doesn’t work
> >> through
> >> Interrupt-remapped IO-APIC J---
> >>
> >
> > Extremely suspiscious commit in the v6.1.15..v6.1.20 update:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > /commit/?id=ce7d894bed1a539a8d6cff42f6f78f9db0c9c26b
>
> I am not sure I understand everything that is said in your link, except
> I must wait for the next updates... Right ?
When triaging a bug, we usually try to find the upstream commit which *caused*
the issue and Bjørn thinks it's the one referenced.
To test whether that's indeed the case, there's a procedure here:
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.1
These are preliminary steps to the actual one which is para 4.2.2 and I have
attached a patch which reverts the referenced commit and that .patch file is
what you give as an argument to `bash debian/bin/test-patches`.
If you could try that to see if that indeed fixes the issue, that would be
very helpful.
HTH
>From 2e6223080905caf4c775680201700b243caa91a9 Mon Sep 17 00:00:00 2001
From: Diederik de Haas
Date: Sat, 1 Apr 2023 10:32:31 +0200
Subject: [PATCH] Revert "x86/acpi/boot: Do not register processors that cannot
be onlined for x2APIC"
This reverts commit ce7d894bed1a539a8d6cff42f6f78f9db0c9c26b.
---
arch/x86/kernel/acpi/boot.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 518bda50068c..907cc98b1938 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -188,17 +188,6 @@ static int acpi_register_lapic(int id, u32 acpiid, u8 enabled)
return cpu;
}
-static bool __init acpi_is_processor_usable(u32 lapic_flags)
-{
- if (lapic_flags & ACPI_MADT_ENABLED)
- return true;
-
- if (acpi_support_online_capable && (lapic_flags & ACPI_MADT_ONLINE_CAPABLE))
- return true;
-
- return false;
-}
-
static int __init
acpi_parse_x2apic(union acpi_subtable_headers *header, const unsigned long end)
{
@@ -223,10 +212,6 @@ acpi_parse_x2apic(union acpi_subtable_headers *header, const unsigned long end)
if (apic_id == 0x)
return 0;
- /* don't register processors that cannot be onlined */
- if (!acpi_is_processor_usable(processor->lapic_flags))
- return 0;
-
/*
* We need to register disabled CPU as well to permit
* counting disabled CPUs. This allows us to size
@@ -265,7 +250,9 @@ acpi_parse_lapic(union acpi_subtable_headers * header, const unsigned long end)
return 0;
/* don't register processors that can not be onlined */
- if (!acpi_is_processor_usable(processor->lapic_flags))
+ if (acpi_support_online_capable &&
+ !(processor->lapic_flags & ACPI_MADT_ENABLED) &&
+ !(processor->lapic_flags & ACPI_MADT_ONLINE_CAPABLE))
return 0;
/*
--
2.40.0
signature.asc
Description: This is a digitally signed message part.
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Hello, Thanks for your answer ! Before receiving it I tried to update my BIOS to the last available version (F51h). Without any effect. I am not sure I understand everything that is said in your link, except I must wait for the next updates... Right ? Best regards. -- Guy Le 01/04/2023 à 09:25, Bjørn Mork a écrit : Guy Durrieu writes: [ 0.117782] Kernel panic — not syncing: timer doesn’t work through Interrupt- remapped I0-APIC [ 0.117848] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-7-and64 #1 Debian 6.1.20-1 [ 0.117913] Hardware name: Gigabyte Technology Co., Ltd. ABS50M-Gaming 3/AB350M-Gaming 3-CF, BIOS F50d 07/02/2020 [ 0.117982] Call Trace: [ 0.118634] [ 0.118685] dump_stack_lvl+0x44/0x5c [ 0.118143] panic+0x118/0x2ed [ 0.118198] panic_if_irq_remap.cold+0x5/0x5 [ 0.118256] setup_I0_APIC+0x3db/0x64b [ 0.118313] ? _raw_spin_unlock_irqrestore+0x23/0x40 [ 0.118372] ? clear_IO_APIC_pin+0x169/0x240 [ 0.118429] apic_intr_node_init+0x101/0x106 [ 0.118485] x86_late_time_init+0x20/0x34 [ 0.118542] start_kerne1+0x667/0x727 [ 0.118598] secondary_startup_64_no_verify+0xe5/0xeb [ 0.118658] [ 0.118711] ---[ end Kernel panic - not syncing: timer doesn’t work through Interrupt-remapped IO-APIC J--- Extremely suspiscious commit in the v6.1.15..v6.1.20 update: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=ce7d894bed1a539a8d6cff42f6f78f9db0c9c26b Bjørn
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Guy Durrieu writes: > > [ 0.117782] Kernel panic — not syncing: timer doesn’t work through > Interrupt- > remapped I0-APIC > [ 0.117848] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-7-and64 #1 > Debian > 6.1.20-1 > [ 0.117913] Hardware name: Gigabyte Technology Co., Ltd. ABS50M-Gaming > 3/AB350M-Gaming 3-CF, BIOS F50d 07/02/2020 > [ 0.117982] Call Trace: > [ 0.118634] > [ 0.118685] dump_stack_lvl+0x44/0x5c > [ 0.118143] panic+0x118/0x2ed > [ 0.118198] panic_if_irq_remap.cold+0x5/0x5 > [ 0.118256] setup_I0_APIC+0x3db/0x64b > [ 0.118313] ? _raw_spin_unlock_irqrestore+0x23/0x40 > [ 0.118372] ? clear_IO_APIC_pin+0x169/0x240 > [ 0.118429] apic_intr_node_init+0x101/0x106 > [ 0.118485] x86_late_time_init+0x20/0x34 > [ 0.118542] start_kerne1+0x667/0x727 > [ 0.118598] secondary_startup_64_no_verify+0xe5/0xeb > [ 0.118658] > [ 0.118711] ---[ end Kernel panic - not syncing: timer doesn’t work through > Interrupt-remapped IO-APIC J--- > Extremely suspiscious commit in the v6.1.15..v6.1.20 update: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=ce7d894bed1a539a8d6cff42f6f78f9db0c9c26b Bjørn
Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message
Package: src:linux Version: 6.1.20-1 Severity: critical Justification: breaks the whole system Dear Maintainer, Up to now I worked with Linux 6.1.0-7-amd64, without any trouble. I just installed Linux 6.1.0-7-amd64 and I get a kernel panic when launching it. Here is a transcription of what appears on the screen (OCR on a screen picture, I hope there are no remaining errors). [ 0.117782] Kernel panic — not syncing: timer doesn’t work through Interrupt- remapped I0-APIC [ 0.117848] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-7-and64 #1 Debian 6.1.20-1 [ 0.117913] Hardware name: Gigabyte Technology Co., Ltd. ABS50M-Gaming 3/AB350M-Gaming 3-CF, BIOS F50d 07/02/2020 [ 0.117982] Call Trace: [ 0.118634] [ 0.118685] dump_stack_lvl+0x44/0x5c [ 0.118143] panic+0x118/0x2ed [ 0.118198] panic_if_irq_remap.cold+0x5/0x5 [ 0.118256] setup_I0_APIC+0x3db/0x64b [ 0.118313] ? _raw_spin_unlock_irqrestore+0x23/0x40 [ 0.118372] ? clear_IO_APIC_pin+0x169/0x240 [ 0.118429] apic_intr_node_init+0x101/0x106 [ 0.118485] x86_late_time_init+0x20/0x34 [ 0.118542] start_kerne1+0x667/0x727 [ 0.118598] secondary_startup_64_no_verify+0xe5/0xeb [ 0.118658] [ 0.118711] ---[ end Kernel panic - not syncing: timer doesn’t work through Interrupt-remapped IO-APIC J--- Hope it helps. Thanks in advance for your help. Best regards. -- Guy Durrieu -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Gigabyte Technology Co., Ltd. product_name: AB350M-Gaming 3 product_version: Default string chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends Inc. bios_version: F50d board_vendor: Gigabyte Technology Co., Ltd. board_name: AB350M-Gaming 3-CF board_version: x.x -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-6.1.0-7-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.142 ii kmod 30+20221128-1 ii linux-base 4.9 Versions of packages linux-image-6.1.0-7-amd64 recommends: ii apparmor 3.0.8-3 ii firmware-linux-free 20200122-1 Versions of packages linux-image-6.1.0-7-amd64 suggests: pn debian-kernel-handbook ii grub-efi-amd64 2.06-8 pn linux-doc-6.1 Versions of packages linux-image-6.1.0-7-amd64 is related to: ii firmware-amd-graphics 20230210-4 pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas ii firmware-linux-nonfree 20230210-4 ii firmware-misc-nonfree 20230210-4 pn firmware-myricom pn firmware-netxen pn firmware-qlogic ii firmware-realtek 20230210-4 pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
