Bug#1032493: linux-image-6.1.0-5-amd64: Kernel freezes computer on CPU soft lockup - CPU thread getting stuck
Package: src:linux Version: 6.1.20-1 Followup-For: Bug #1032493 Dear Maintainer, I'm adding current system's information to this bug. Best regards, Dario Susman -- Package-specific info: ** Version: Linux version 6.1.0-7-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-1 (2023-03-19) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-7-amd64 root=/dev/sda1 ro initrd=/install/initrd.gz net.ifnames=0 apparmor=0 crashkernel=384M-:128M ** Not tainted ** Kernel log: [4.356275] input: HD-Audio Generic Front Headphone as /devices/pci:00/:00:08.1/:09:00.3/sound/card1/input10 [4.357647] [drm] radeon kernel modesetting enabled. [4.360434] radeon :07:00.0: vgaarb: deactivate vga console [4.361103] Console: switching to colour dummy device 80x25 [4.361365] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x174B:0xE164 0x00). [4.361425] ATOM BIOS: C09302 [4.361481] radeon :07:00.0: VRAM: 1024M 0x - 0x3FFF (1024M used) [4.361486] radeon :07:00.0: GTT: 1024M 0x4000 - 0x7FFF [4.361491] [drm] Detected VRAM RAM=1024M, BAR=256M [4.361493] [drm] RAM width 64bits DDR [4.361519] [drm] radeon: 1024M of VRAM memory ready [4.361521] [drm] radeon: 1024M of GTT memory ready. [4.361528] [drm] Loading CEDAR Microcode [4.365219] radeon :07:00.0: firmware: direct-loading firmware radeon/CEDAR_pfp.bin [4.366805] radeon :07:00.0: firmware: direct-loading firmware radeon/CEDAR_me.bin [4.367488] radeon :07:00.0: firmware: direct-loading firmware radeon/CEDAR_rlc.bin [4.368457] radeon :07:00.0: firmware: direct-loading firmware radeon/CEDAR_smc.bin [4.368462] [drm] Internal thermal controller with fan control [4.395064] [drm] radeon: dpm initialized [4.395959] radeon :07:00.0: firmware: direct-loading firmware radeon/CYPRESS_uvd.bin [4.395995] [drm] GART: num cpu pages 262144, num gpu pages 262144 [4.396817] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [4.413737] [drm] PCIE GART of 1024M enabled (table at 0x0014C000). [4.413843] radeon :07:00.0: WB enabled [4.413848] radeon :07:00.0: fence driver on ring 0 use gpu addr 0x4c00 [4.413853] radeon :07:00.0: fence driver on ring 3 use gpu addr 0x4c0c [4.414223] radeon :07:00.0: fence driver on ring 5 use gpu addr 0x0005c418 [4.420991] radeon :07:00.0: radeon: MSI limited to 32-bit [4.421059] radeon :07:00.0: radeon: using MSI. [4.421085] [drm] radeon: irq initialized. [4.437229] [drm] ring test on 0 succeeded in 1 usecs [4.437238] [drm] ring test on 3 succeeded in 2 usecs [4.437416] SVM: TSC scaling supported [4.437421] kvm: Nested Virtualization enabled [4.437423] SVM: kvm: Nested Paging enabled [4.437426] SEV supported: 16 ASIDs [4.437434] SVM: Virtual VMLOAD VMSAVE supported [4.437436] SVM: Virtual GIF supported [4.437438] SVM: LBR virtualization supported [4.452802] MCE: In-kernel MCE decoding enabled. [4.458346] intel_rapl_common: Found RAPL domain package [4.458351] intel_rapl_common: Found RAPL domain core [4.613025] [drm] ring test on 5 succeeded in 1 usecs [4.613038] [drm] UVD initialized successfully. [4.613213] [drm] ib test on ring 0 succeeded in 0 usecs [4.613252] [drm] ib test on ring 3 succeeded in 0 usecs [5.293395] [drm] ib test on ring 5 succeeded [5.293795] [drm] Radeon Display Connectors [5.293800] [drm] Connector 0: [5.293802] [drm] HDMI-A-1 [5.293805] [drm] HPD2 [5.293807] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [5.293812] [drm] Encoders: [5.293815] [drm] DFP1: INTERNAL_UNIPHY1 [5.293817] [drm] Connector 1: [5.293820] [drm] DVI-I-1 [5.293822] [drm] HPD4 [5.293824] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [5.293829] [drm] Encoders: [5.293831] [drm] DFP2: INTERNAL_UNIPHY [5.293834] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [5.293837] [drm] Connector 2: [5.293839] [drm] VGA-1 [5.293841] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [5.293846] [drm] Encoders: [5.293848] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [5.341778] [drm] fb mappable at 0xE034D000 [5.341784] [drm] vram apper at 0xE000 [5.341787] [drm] size 5242880 [5.341790] [drm] fb depth is 24 [5.341793] [drm]pitch is 5120 [5.341908] fbcon: radeondrmfb (fb0) is primary device [5.382641] Console: switching to colour frame buffer device 160x64 [5.384988] radeon :07:00.0: [drm] fb0: radeondrmfb frame buffer device [5.421744] [drm] Initialized radeon 2.50.0 20080528 for :07:00.0 on minor 0 [6.798209]
Processed: Remove moreinfo tag
Processing commands for cont...@bugs.debian.org: > tags 1033732 - 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 Removed tag(s) moreinfo. > End of message, stopping processing here. Please contact me if you need assistance. -- 1033732: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033732 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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
firmware-nonfree_20230310-1~exp1_source.changes ACCEPTED into experimental
Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 01 Apr 2023 20:38:58 +0200
Source: firmware-nonfree
Architecture: source
Version: 20230310-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian Kernel Team
Changed-By: Salvatore Bonaccorso
Changes:
firmware-nonfree (20230310-1~exp1) experimental; urgency=medium
.
* New upstream version:
- amdgpu: Update GC 11.0.1 firmware
- ath10k: WCN3990 hw1.0: update board-2.bin
- ath11k: WCN6750 hw1.0: update board-2.bin
- ath11k: WCN6855 hw2.0: update board-2.bin
- rtl_bt: Update RTL8852C BT USB firmware to 0xD7B8_FABF
- rtl_bt: Update RTL8822C BT UART firmware to 0x05C6_D2E3
- rtl_bt: Update RTL8822C BT USB firmware to 0x0CC6_D2E3
.
[ Salvatore Bonaccorso ]
* Exclude ath9k_htc/htc_{7010,9271}-1.4.0.fw files from generated orig
tarball
* intel-sound: catpt: Add AudioDSP base firmware for BDW platforms
* atheros: ath10k: QCA6174 hw3.0: update firmware-sdio-6.bin to version
WLAN.RMH.4.4.1-00174
* atheros: ath11k: WCN6855 hw2.0: update to
WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
* realtek: rtw89: 8852b: update fw to v0.29.26.0
* realtek: rtw89: 8852b: update fw to v0.29.29.0
* misc-nonfree: linux-firmware: update firmware for MT7921 WiFi device
* misc-nonfree: linux-firmware: update firmware for mediatek bluetooth chip
(MT7921)
* iwlwifi: iwlwifi: update core69 and core72 firmwares for Ty device
* iwlwifi: Add missing stanza for iwlwifi-so-a0-gf4-a0-72.ucode firmware
* Update to linux-support 6.1.0-7
.
[ Diederik de Haas ]
* d/patches/gitignore: Add DEP-3 header
* d/README.source: Expand steps to regenerate debian/control
* d/config/*/defines: Replace 'wifi' with 'Wi-Fi'
Checksums-Sha1:
094daf8e0b8590d6a14028f5bf036285488bd608 4296
firmware-nonfree_20230310-1~exp1.dsc
16d7f4efbcbb0bdfc1c651352170a4ad032c0e3d 223457984
firmware-nonfree_20230310.orig.tar.xz
2bc2e4e730e9399bfab7ca3532393065d6e1937a 827516
firmware-nonfree_20230310-1~exp1.debian.tar.xz
8e2fa6e897f543997b36a9d0d75fb0cca5c70b10 6052
firmware-nonfree_20230310-1~exp1_source.buildinfo
Checksums-Sha256:
5b0ff7c214ddb5fd96a02323fa4c648f4f0ae1e4c8137e42f92f8133dea891c6 4296
firmware-nonfree_20230310-1~exp1.dsc
b38fae78b9c86d180061c2d30ded6e93143ba0229a4d4a864facc515d16e5fe6 223457984
firmware-nonfree_20230310.orig.tar.xz
7f17587092b3bb3e54e56cf20ac2a4b71f7813690c36ef344dc3f668c60a91d2 827516
firmware-nonfree_20230310-1~exp1.debian.tar.xz
f8794d060b85a62e56ca80c41c82c6bf9f4827dc49e4de16f80173bc53a7e7c9 6052
firmware-nonfree_20230310-1~exp1_source.buildinfo
Files:
fb34c2225b3d684251184b86bdf1fd06 4296 non-free-firmware/kernel optional
firmware-nonfree_20230310-1~exp1.dsc
3c1dafa5ff129c529a473818a4204b41 223457984 non-free-firmware/kernel optional
firmware-nonfree_20230310.orig.tar.xz
18ef9fcadb34681307ddaf2a97015c70 827516 non-free-firmware/kernel optional
firmware-nonfree_20230310-1~exp1.debian.tar.xz
c3b8de099f4e8fd3a6391b8f4908deab 6052 non-free-firmware/kernel optional
firmware-nonfree_20230310-1~exp1_source.buildinfo
-BEGIN PGP SIGNATURE-
iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmQoe8RfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk
ZWJpYW4ub3JnAAoJEAVMuPMTQ89EG7kP/ixGkYMihbuijKv2xvLMKcRG5+Ovge6U
TmAc2rwH68gEnn0UEtHaM3zDIcK396MmlxqhobCvqM72ywmwaZiGhQ3NiXHT5tTt
m9f3kJJiQ1pN2t4pzBRK/fMQpMlleionlW/1+m8FgyEYsID5P4RZRJ4MeCvuxpmn
4IFDG4JjSDTzZKu4IWlyNrYWYk30/NF8tStnN0LHQjbuD0fTceHS2+TvdZuwiSPe
NBFlQ32XTA0CHJeNWsQbFSyi3ccwgvvbK1fsKXNc5hNXLaZOrtUKkmuQTSPkLfUG
bf/EHKx17RFtbM4etbs8m0RmWVwQHRfGGvnEnQb+iQFo+GAG0JrrYEiFPUWKBGNu
MV8NZ2S1nMDdWyfjryO4PRvJI/Ng95bH+odak0x9H/UNnogwZ67vh0PsH1J0hfEl
PSr10wBB3YXCvEwaiJhjCwXWJ8v6M78WxPdudA7BaJdCp7oOZxF/8TKnRDh2oBbY
zjE7QazpcuvJWhdXaxgrTX9NaIiwfIGfwLLwABjVqnBeXJDPsYqGUf6gEjsbFpbD
IyzUQoj2s14YQHZ0fzJQgui1P/ehQT/PS86/1YI0+7bWXmbhIX6zIdOrXHdUCSVn
z0RhX0QnC1nm5GX3SfQcuea8RIti9iuIYRUs5NppVvckKrUS0BeBKi8HOG2zK46k
P5ylMYyceaht
=Gg4J
-END PGP SIGNATURE-
Processing of firmware-nonfree_20230310-1~exp1_source.changes
firmware-nonfree_20230310-1~exp1_source.changes uploaded successfully to localhost along with the files: firmware-nonfree_20230310-1~exp1.dsc firmware-nonfree_20230310.orig.tar.xz firmware-nonfree_20230310-1~exp1.debian.tar.xz firmware-nonfree_20230310-1~exp1_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
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
