Your message dated Fri, 18 Aug 2023 21:29:25 +0100 with message-id <2dadb28ca368809acbb9900196ab200e626ae565.ca...@adam-barratt.org.uk> and subject line Re: Bug#1044518: linux: "RIP: 0010:get_xsave_addr+0x9b/0xb0" stacktrace in early boot with -24 bullseye kernel has caused the Debian Bug report #1044518, regarding regression: kernel WARNING at arch/x86/kernel/fpu/xstate.c:973 get_xsave_addr+0x9b/0xb0 to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1044518: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1044518 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Source: linux Version: 5.10.179-5 Severity: important X-Debbugs-Cc: b.zeim...@conova.com, m.viertha...@conova.com Hi, since updating the bullseye kernel to 5.10.179-5, we get the following kernel WARNING (and so a tainted kernel) while running under vmware ESX: [ 0.087938] ------------[ cut here ]------------ [ 0.087940] get of unsupported state [ 0.087947] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:973 get_xsave_addr+0x9b/0xb0 [ 0.087948] Modules linked in: [ 0.087952] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-24-amd64 #1 Debian 5.10.179-5 [ 0.087953] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 [ 0.087954] RIP: 0010:get_xsave_addr+0x9b/0xb0 [ 0.087956] Code: 48 83 c4 08 5b e9 15 80 bc 00 80 3d 8d 7c 80 01 00 75 a8 48 c7 c7 97 de cb 99 89 74 24 04 c6 05 79 7c 80 01 01 e8 f5 96 88 00 <0f> 0b 8b 74 24 04 eb 89 31 c0 e9 e6 7f bc 00 66 0f 1f 44 00 00 89 [ 0.087957] RSP: 0000:ffffffff9a203ec8 EFLAGS: 00010282 [ 0.087958] RAX: 0000000000000000 RBX: ffffffff9a46a600 RCX: ffff8b635fdfffa8 [ 0.087959] RDX: c0000000ffff7fff RSI: 00000000ffff7fff RDI: 0000000000000247 [ 0.087960] RBP: ffffffff9a46a4a0 R08: 0000000000000000 R09: ffffffff9a203ce8 [ 0.087960] R10: ffffffff9a203ce0 R11: ffff8b637fec18a8 R12: 0000000000000246 [ 0.087961] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 0.087962] FS: 0000000000000000(0000) GS:ffff8b635fe00000(0000) knlGS:0000000000000000 [ 0.087962] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.087963] CR2: ffff8b5d8d602000 CR3: 00000001cbc0a001 CR4: 00000000007300b0 [ 0.087977] Call Trace: [ 0.087982] identify_cpu+0x51f/0x540 [ 0.087985] identify_boot_cpu+0xc/0x94 [ 0.087986] arch_cpu_finalize_init+0x5/0x47 [ 0.087988] start_kernel+0x4ec/0x599 [ 0.087991] secondary_startup_64_no_verify+0xb0/0xbb [ 0.087993] ---[ end trace 8ac8962c4c9dda0c ]--- This sounds like the issue described in https://lore.kernel.org/lkml/2023081511-easing-exerciser-c356@gregkh/ Could you please follow up and include the fix in case its not in the next kernel pointrelease? Thanks, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer http://bzed.de http://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--- End Message ---
--- Begin Message ---Version: 5.10.191-1 Hi, On Tue, 2023-08-15 at 23:08 +0200, Salvatore Bonaccorso wrote: > Hi Adam, > > On Tue, Aug 15, 2023 at 10:48:35PM +0200, Salvatore Bonaccorso wrote: > > Control: tags -1 + upstream > > > > Hi Adam, > > > > On Tue, Aug 15, 2023 at 10:06:16PM +0200, Salvatore Bonaccorso > > wrote: > > > Hi Adam, > > > > > > On Tue, Aug 15, 2023 at 09:37:36PM +0200, Salvatore Bonaccorso > > > wrote: > > > > Control: tags -1 + confirmed > > > > > > > > Hi Adam, > > > > > > > > On Tue, Aug 15, 2023 at 06:26:59PM +0100, Adam D. Barratt > > > > wrote: > > > > > On Sun, 2023-08-13 at 18:21 +0100, Adam D. Barratt wrote: > > > > > > Since the kernels on both the host and guests were upgraded > > > > > > to > > > > > > 5.10.179-5 (from 5.10.179-3), the guests on one of our > > > > > > Ganeti > > > > > > clusters > > > > > > have been reporting as tainted. Looking at dmesg shows the > > > > > > following > > > > > > trace early in boot: > > > > > > [...] > > Quick summary: v5.10.190 upstream exhibit the same problem, so not > > a > > backporting problem, and v5.10.191-rc1 for the upcoming 5.10.191 > > seems > > to fix the issue. > > This should be fixed by b3607269ff57 ("x86/pkeys: Revert a5eff7259790 > ("x86/pkeys: Add PKRU value to init_fpstate")")[1] upstream, which is > going to be a pplied in 5.10.191. > > [1] > https://git.kernel.org/linus/b3607269ff57fd3c9690cb25962c5e4b91a0fd3b > I'm happy to confirm that the 5.10.191-1 kernel fixes this issue for us; closing appropriately. Regards, Adam
--- End Message ---
