]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 5.10
authorSasha Levin <sashal@kernel.org>
Sun, 2 Mar 2025 14:46:05 +0000 (09:46 -0500)
committerSasha Levin <sashal@kernel.org>
Sun, 2 Mar 2025 14:46:05 +0000 (09:46 -0500)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-5.10/series
queue-5.10/x86-cpu-fix-warm-boot-hang-regression-on-amd-sc1100-.patch [new file with mode: 0644]

index fa49d94e20caa7fcbca4b0df2efd4972dd63e12b..fb9a6665c76d0f0419a21f3edb41c91c74067f29 100644 (file)
@@ -379,3 +379,4 @@ net-use-indirect-call-helpers-for-dst_output.patch
 include-net-add-static-inline-dst_dev_overhead-to-ds.patch
 net-ipv6-rpl_iptunnel-mitigate-2-realloc-issue.patch
 net-ipv6-fix-dst-ref-loop-on-input-in-rpl-lwt.patch
+x86-cpu-fix-warm-boot-hang-regression-on-amd-sc1100-.patch
diff --git a/queue-5.10/x86-cpu-fix-warm-boot-hang-regression-on-amd-sc1100-.patch b/queue-5.10/x86-cpu-fix-warm-boot-hang-regression-on-amd-sc1100-.patch
new file mode 100644 (file)
index 0000000..e9d8c05
--- /dev/null
@@ -0,0 +1,95 @@
+From 72ba0605c604921d211fc579be1fcd0b61febbf7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 25 Feb 2025 22:31:20 +0100
+Subject: x86/CPU: Fix warm boot hang regression on AMD SC1100 SoC systems
+
+From: Russell Senior <russell@personaltelco.net>
+
+[ Upstream commit bebe35bb738b573c32a5033499cd59f20293f2a3 ]
+
+I still have some Soekris net4826 in a Community Wireless Network I
+volunteer with. These devices use an AMD SC1100 SoC. I am running
+OpenWrt on them, which uses a patched kernel, that naturally has
+evolved over time.  I haven't updated the ones in the field in a
+number of years (circa 2017), but have one in a test bed, where I have
+intermittently tried out test builds.
+
+A few years ago, I noticed some trouble, particularly when "warm
+booting", that is, doing a reboot without removing power, and noticed
+the device was hanging after the kernel message:
+
+  [    0.081615] Working around Cyrix MediaGX virtual DMA bugs.
+
+If I removed power and then restarted, it would boot fine, continuing
+through the message above, thusly:
+
+  [    0.081615] Working around Cyrix MediaGX virtual DMA bugs.
+  [    0.090076] Enable Memory-Write-back mode on Cyrix/NSC processor.
+  [    0.100000] Enable Memory access reorder on Cyrix/NSC processor.
+  [    0.100070] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
+  [    0.110058] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
+  [    0.120037] CPU: NSC Geode(TM) Integrated Processor by National Semi (family: 0x5, model: 0x9, stepping: 0x1)
+  [...]
+
+In order to continue using modern tools, like ssh, to interact with
+the software on these old devices, I need modern builds of the OpenWrt
+firmware on the devices. I confirmed that the warm boot hang was still
+an issue in modern OpenWrt builds (currently using a patched linux
+v6.6.65).
+
+Last night, I decided it was time to get to the bottom of the warm
+boot hang, and began bisecting. From preserved builds, I narrowed down
+the bisection window from late February to late May 2019. During this
+period, the OpenWrt builds were using 4.14.x. I was able to build
+using period-correct Ubuntu 18.04.6. After a number of bisection
+iterations, I identified a kernel bump from 4.14.112 to 4.14.113 as
+the commit that introduced the warm boot hang.
+
+  https://github.com/openwrt/openwrt/commit/07aaa7e3d62ad32767d7067107db64b6ade81537
+
+Looking at the upstream changes in the stable kernel between 4.14.112
+and 4.14.113 (tig v4.14.112..v4.14.113), I spotted a likely suspect:
+
+  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=20afb90f730982882e65b01fb8bdfe83914339c5
+
+So, I tried reverting just that kernel change on top of the breaking
+OpenWrt commit, and my warm boot hang went away.
+
+Presumably, the warm boot hang is due to some register not getting
+cleared in the same way that a loss of power does. That is
+approximately as much as I understand about the problem.
+
+More poking/prodding and coaching from Jonas Gorski, it looks
+like this test patch fixes the problem on my board: Tested against
+v6.6.67 and v4.14.113.
+
+Fixes: 18fb053f9b82 ("x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors")
+Debugged-by: Jonas Gorski <jonas.gorski@gmail.com>
+Signed-off-by: Russell Senior <russell@personaltelco.net>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Link: https://lore.kernel.org/r/CAHP3WfOgs3Ms4Z+L9i0-iBOE21sdMk5erAiJurPjnrL9LSsgRA@mail.gmail.com
+Cc: Matthew Whitehead <tedheadster@gmail.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/kernel/cpu/cyrix.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
+index 1d9b8aaea06c8..c062d3e90eca8 100644
+--- a/arch/x86/kernel/cpu/cyrix.c
++++ b/arch/x86/kernel/cpu/cyrix.c
+@@ -152,8 +152,8 @@ static void geode_configure(void)
+       u8 ccr3;
+       local_irq_save(flags);
+-      /* Suspend on halt power saving and enable #SUSP pin */
+-      setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
++      /* Suspend on halt power saving */
++      setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x08);
+       ccr3 = getCx86(CX86_CCR3);
+       setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);       /* enable MAPEN */
+-- 
+2.39.5
+