* [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
@ 2025-04-21 8:12 kernel test robot
2025-04-22 10:16 ` Arnd Bergmann
0 siblings, 1 reply; 47+ messages in thread
From: kernel test robot @ 2025-04-21 8:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: oe-lkp, lkp, linux-kernel, Ingo Molnar, Linus Torvalds,
oliver.sang
Hello,
by this commit, we notice big config diff [1]
then in this rcutorture tests, parent runs quite clean, f388f60ca9 shows
various random issues.
=========================================================================================
tbox_group/testcase/rootfs/kconfig/compiler/runtime/test/torture_type:
vm-snb/rcutorture/debian-11.1-i386-20220923.cgz/i386-randconfig-r071-20250410/gcc-12/300s/default/tasks-tracing
fc2d5cbe541032e7 f388f60ca9041a95c9b3f157d31
---------------- ---------------------------
fail:runs %reproduction fail:runs
| | |
:500 30% 149:500 last_state.booting
:500 7% 35:500 dmesg.BUG:kernel_hang_in_boot_stage
:500 9% 45:500 dmesg.BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
:500 10% 51:500 dmesg.BUG:workqueue_lockup-pool
:500 0% 1:500 dmesg.EIP:__timer_delete_sync
:500 1% 5:500 dmesg.EIP:_raw_spin_unlock_irq
:500 0% 2:500 dmesg.EIP:_raw_spin_unlock_irqrestore
:500 0% 1:500 dmesg.EIP:console_emit_next_record
:500 0% 1:500 dmesg.EIP:handle_softirqs
:500 1% 3:500 dmesg.EIP:lock_acquire
:500 0% 2:500 dmesg.EIP:lock_release
:500 0% 1:500 dmesg.EIP:queue_delayed_work_on
:500 9% 45:500 dmesg.EIP:timekeeping_notify
:500 3% 14:500 dmesg.INFO:rcu_preempt_detected_stalls_on_CPUs/tasks
:500 6% 32:500 dmesg.INFO:task_blocked_for_more_than#seconds
:500 1% 3:500 dmesg.IP-Config:Auto-configuration_of_network_failed
:500 9% 45:500 dmesg.Kernel_panic-not_syncing:softlockup:hung_tasks
:500 29% 146:500 dmesg.boot_failures
we don't have enough knowledge to dig deep these issues. so just make this
report to consult with you if these issues are related with config diff.
and if so, is this config diff reasonable by this commit?
below our normal report just FYI.
kernel test robot noticed "BUG:soft_lockup-CPU##stuck_for#s![swapper:#]" on:
commit: f388f60ca9041a95c9b3f157d316ed7c8f297e44 ("x86/cpu: Drop configuration options for early 64-bit CPUs")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
[test failed on linus/master e618ee89561b6b0fdc69f79e6fd0c33375d3e6b4]
[test failed on linux-next/master 01c6df60d5d4ae00cd5c1648818744838bba7763]
in testcase: rcutorture
version:
with following parameters:
runtime: 300s
test: default
torture_type: tasks-tracing
config: i386-randconfig-r071-20250410
compiler: gcc-12
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202504211553.3ba9400-lkp@intel.com
[ 721.016745][ C0] watchdog: BUG: soft lockup - CPU#0 stuck for 626s! [swapper:1]
[ 721.016779][ C0] CPU#0 Utilization every 96s during lockup:
[ 721.016779][ C0] #1: 39% system, 0% softirq, 0% hardirq, 0% idle
[ 721.016779][ C0] #2: 42% system, 0% softirq, 0% hardirq, 0% idle
[ 721.016779][ C0] #3: 47% system, 0% softirq, 0% hardirq, 0% idle
[ 721.016779][ C0] #4: 34% system, 0% softirq, 0% hardirq, 0% idle
[ 721.016779][ C0] #5: 32% system, 0% softirq, 0% hardirq, 0% idle
[ 721.016779][ C0] Modules linked in:
[ 721.016779][ C0] irq event stamp: 159506
[ 721.016779][ C0] hardirqs last enabled at (159505): timekeeping_notify (arch/x86/include/asm/irqflags.h:42 arch/x86/include/asm/irqflags.h:97 arch/x86/include/asm/irqflags.h:155 include/linux/stop_machine.h:154 include/linux/stop_machine.h:161 kernel/time/timekeeping.c:1521)
[ 721.016779][ C0] hardirqs last disabled at (159506): sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049)
[ 721.016779][ C0] softirqs last enabled at (159174): handle_softirqs (kernel/softirq.c:408 kernel/softirq.c:589)
[ 721.016779][ C0] softirqs last disabled at (159159): __do_softirq (kernel/softirq.c:596)
[ 721.016779][ C0] CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.14.0-rc3-00037-gf388f60ca904 #1
[ 721.016779][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 721.016779][ C0] EIP: timekeeping_notify (kernel/time/timekeeping.c:1522)
[ 721.016779][ C0] Code: 5f e9 ff ff 8d 45 e8 e8 57 d4 ff ff 85 ff 74 16 8b 57 5c 85 d2 74 04 89 f8 ff d2 8b 87 88 00 00 00 e8 d5 3e ff ff 85 f6 75 9b <e8> 7f b9 00 00 31 c0 39 1d a4 70 14 84 0f 95 c0 f7 d8 8b 55 f0 2b
All code
========
0: 5f pop %rdi
1: e9 ff ff 8d 45 jmp 0x458e0005
6: e8 e8 57 d4 ff call 0xffffffffffd457f3
b: ff 85 ff 74 16 8b incl -0x74e98b01(%rbp)
11: 57 push %rdi
12: 5c pop %rsp
13: 85 d2 test %edx,%edx
15: 74 04 je 0x1b
17: 89 f8 mov %edi,%eax
19: ff d2 call *%rdx
1b: 8b 87 88 00 00 00 mov 0x88(%rdi),%eax
21: e8 d5 3e ff ff call 0xffffffffffff3efb
26: 85 f6 test %esi,%esi
28: 75 9b jne 0xffffffffffffffc5
2a:* e8 7f b9 00 00 call 0xb9ae <-- trapping instruction
2f: 31 c0 xor %eax,%eax
31: 39 1d a4 70 14 84 cmp %ebx,-0x7beb8f5c(%rip) # 0xffffffff841470db
37: 0f 95 c0 setne %al
3a: f7 d8 neg %eax
3c: 8b 55 f0 mov -0x10(%rbp),%edx
3f: 2b .byte 0x2b
Code starting with the faulting instruction
===========================================
0: e8 7f b9 00 00 call 0xb984
5: 31 c0 xor %eax,%eax
7: 39 1d a4 70 14 84 cmp %ebx,-0x7beb8f5c(%rip) # 0xffffffff841470b1
d: 0f 95 c0 setne %al
10: f7 d8 neg %eax
12: 8b 55 f0 mov -0x10(%rbp),%edx
15: 2b .byte 0x2b
[ 721.016779][ C0] EAX: 00026f11 EBX: 8316b7e0 ECX: 00000006 EDX: 7e26f13f
[ 721.016779][ C0] ESI: 00000200 EDI: 835e7220 EBP: 86d15ed8 ESP: 86d15ec0
[ 721.016779][ C0] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00000206
[ 721.016779][ C0] CR0: 80050033 CR2: ffdaa000 CR3: 03a16000 CR4: 000406d0
[ 721.016779][ C0] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 721.016779][ C0] DR6: fffe0ff0 DR7: 00000400
[ 721.016779][ C0] Call Trace:
[ 721.016779][ C0] ? show_regs (arch/x86/kernel/dumpstack.c:478)
[ 721.016779][ C0] ? watchdog_timer_fn (kernel/watchdog.c:767)
[ 721.016779][ C0] ? schedule_work (drivers/usb/core/hub.c:919)
[ 721.016779][ C0] ? __hrtimer_run_queues+0x12f/0x1cf
[ 721.016779][ C0] ? hrtimer_run_queues (kernel/time/hrtimer.c:2023)
[ 721.016779][ C0] ? update_process_times (kernel/time/timer.c:2458 kernel/time/timer.c:2514)
[ 721.016779][ C0] ? tick_periodic (kernel/time/tick-common.c:103)
[ 721.016779][ C0] ? tick_handle_periodic (kernel/time/tick-common.c:144)
[ 721.016779][ C0] ? vmware_sched_clock (arch/x86/kernel/apic/apic.c:1049)
[ 721.016779][ C0] ? __sysvec_apic_timer_interrupt (arch/x86/include/asm/trace/irq_vectors.h:41 arch/x86/include/asm/trace/irq_vectors.h:41 arch/x86/kernel/apic/apic.c:1056)
[ 721.016779][ C0] ? sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)
[ 721.016779][ C0] ? handle_exception (arch/x86/entry/entry_32.S:1055)
[ 721.016779][ C0] ? vmware_sched_clock (arch/x86/kernel/apic/apic.c:1049)
[ 721.016779][ C0] ? timekeeping_notify (kernel/time/timekeeping.c:1522)
[ 721.016779][ C0] ? vmware_sched_clock (arch/x86/kernel/apic/apic.c:1049)
[ 721.016779][ C0] ? timekeeping_notify (kernel/time/timekeeping.c:1522)
[ 721.016779][ C0] __clocksource_select (kernel/time/clocksource.c:1077 (discriminator 1))
[ 721.016779][ C0] ? boot_override_clock (kernel/time/clocksource.c:1109)
[ 721.016779][ C0] clocksource_select (kernel/time/clocksource.c:1094)
[ 721.016779][ C0] clocksource_done_booting (kernel/time/clocksource.c:1118)
[ 721.016779][ C0] do_one_initcall (init/main.c:1257)
[ 721.016779][ C0] ? rdinit_setup (init/main.c:1305)
[ 721.016779][ C0] do_initcalls (init/main.c:1318 init/main.c:1335)
[ 721.016779][ C0] ? rest_init (init/main.c:1449)
[ 721.016779][ C0] kernel_init_freeable (init/main.c:1572)
[ 721.016779][ C0] kernel_init (init/main.c:1459)
[ 721.016779][ C0] ret_from_fork (arch/x86/kernel/process.c:154)
[ 721.016779][ C0] ? rest_init (init/main.c:1449)
[ 721.016779][ C0] ret_from_fork_asm (arch/x86/entry/entry_32.S:737)
[ 721.016779][ C0] entry_INT80_32 (arch/x86/entry/entry_32.S:945)
[ 721.016779][ C0] Kernel panic - not syncing: softlockup: hung tasks
[ 721.016779][ C0] CPU: 0 UID: 0 PID: 1 Comm: swapper Tainted: G L 6.14.0-rc3-00037-gf388f60ca904 #1
[ 721.016779][ C0] Tainted: [L]=SOFTLOCKUP
[ 721.016779][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 721.016779][ C0] Call Trace:
[ 721.016779][ C0] dump_stack_lvl (lib/dump_stack.c:124)
[ 721.016779][ C0] dump_stack (lib/dump_stack.c:130)
[ 721.016779][ C0] panic (kernel/panic.c:258 kernel/panic.c:375)
[ 721.016779][ C0] watchdog_timer_fn (kernel/watchdog.c:740)
[ 721.016779][ C0] ? schedule_work (drivers/usb/core/hub.c:919)
[ 721.016779][ C0] __hrtimer_run_queues+0x12f/0x1cf
[ 721.016779][ C0] hrtimer_run_queues (kernel/time/hrtimer.c:2023)
[ 721.016779][ C0] update_process_times (kernel/time/timer.c:2458 kernel/time/timer.c:2514)
[ 721.016779][ C0] tick_periodic (kernel/time/tick-common.c:103)
[ 721.016779][ C0] tick_handle_periodic (kernel/time/tick-common.c:144)
[ 721.016779][ C0] ? vmware_sched_clock (arch/x86/kernel/apic/apic.c:1049)
[ 721.016779][ C0] __sysvec_apic_timer_interrupt (arch/x86/include/asm/trace/irq_vectors.h:41 arch/x86/include/asm/trace/irq_vectors.h:41 arch/x86/kernel/apic/apic.c:1056)
[ 721.016779][ C0] sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)
[ 721.016779][ C0] handle_exception (arch/x86/entry/entry_32.S:1055)
[ 721.016779][ C0] EIP: timekeeping_notify (kernel/time/timekeeping.c:1522)
[ 721.016779][ C0] Code: 5f e9 ff ff 8d 45 e8 e8 57 d4 ff ff 85 ff 74 16 8b 57 5c 85 d2 74 04 89 f8 ff d2 8b 87 88 00 00 00 e8 d5 3e ff ff 85 f6 75 9b <e8> 7f b9 00 00 31 c0 39 1d a4 70 14 84 0f 95 c0 f7 d8 8b 55 f0 2b
All code
========
0: 5f pop %rdi
1: e9 ff ff 8d 45 jmp 0x458e0005
6: e8 e8 57 d4 ff call 0xffffffffffd457f3
b: ff 85 ff 74 16 8b incl -0x74e98b01(%rbp)
11: 57 push %rdi
12: 5c pop %rsp
13: 85 d2 test %edx,%edx
15: 74 04 je 0x1b
17: 89 f8 mov %edi,%eax
19: ff d2 call *%rdx
1b: 8b 87 88 00 00 00 mov 0x88(%rdi),%eax
21: e8 d5 3e ff ff call 0xffffffffffff3efb
26: 85 f6 test %esi,%esi
28: 75 9b jne 0xffffffffffffffc5
2a:* e8 7f b9 00 00 call 0xb9ae <-- trapping instruction
2f: 31 c0 xor %eax,%eax
31: 39 1d a4 70 14 84 cmp %ebx,-0x7beb8f5c(%rip) # 0xffffffff841470db
37: 0f 95 c0 setne %al
3a: f7 d8 neg %eax
3c: 8b 55 f0 mov -0x10(%rbp),%edx
3f: 2b .byte 0x2b
Code starting with the faulting instruction
===========================================
0: e8 7f b9 00 00 call 0xb984
5: 31 c0 xor %eax,%eax
7: 39 1d a4 70 14 84 cmp %ebx,-0x7beb8f5c(%rip) # 0xffffffff841470b1
d: 0f 95 c0 setne %al
10: f7 d8 neg %eax
12: 8b 55 f0 mov -0x10(%rbp),%edx
15: 2b .byte 0x2b
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20250421/202504211553.3ba9400-lkp@intel.com
[1]
--- /pkg/linux/i386-randconfig-r071-20250410/gcc-12/fc2d5cbe541032e74a66599ba843803cebbfed0e/.config 2025-04-15 15:41:11.316836213 +0800
+++ /pkg/linux/i386-randconfig-r071-20250410/gcc-12/f388f60ca9041a95c9b3f157d316ed7c8f297e44/.config 2025-04-15 15:41:17.009901645 +0800
@@ -321,7 +321,7 @@ CONFIG_ARCH_CPUIDLE_HALTPOLL=y
# CONFIG_PVH is not set
# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
CONFIG_PARAVIRT_CLOCK=y
-# CONFIG_M486SX is not set
+CONFIG_M486SX=y
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
@@ -333,7 +333,6 @@ CONFIG_PARAVIRT_CLOCK=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
-CONFIG_MK8=y
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
@@ -344,26 +343,24 @@ CONFIG_MK8=y
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
-# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
+CONFIG_X86_F00F_BUG=y
+CONFIG_X86_INVD_BUG=y
+CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_INTEL_USERCOPY=y
-CONFIG_X86_USE_PPRO_CHECKSUM=y
-CONFIG_X86_TSC=y
-CONFIG_X86_HAVE_PAE=y
-CONFIG_X86_CMPXCHG64=y
-CONFIG_X86_CMOV=y
-CONFIG_X86_MINIMUM_CPU_FAMILY=6
-CONFIG_X86_DEBUGCTLMSR=y
+CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_IA32_FEAT_CTL=y
CONFIG_X86_VMX_FEATURE_NAMES=y
CONFIG_CPU_SUP_INTEL=y
+CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_HYGON=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
+CONFIG_CPU_SUP_UMC_32=y
CONFIG_CPU_SUP_ZHAOXIN=y
CONFIG_CPU_SUP_VORTEX_32=y
CONFIG_HPET_TIMER=y
@@ -410,7 +407,6 @@ CONFIG_X86_MSR=y
# CONFIG_X86_CPUID is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
-# CONFIG_HIGHMEM64G is not set
# CONFIG_VMSPLIT_3G is not set
# CONFIG_VMSPLIT_3G_OPT is not set
CONFIG_VMSPLIT_2G=y
@@ -418,7 +414,6 @@ CONFIG_VMSPLIT_2G=y
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0x80000000
CONFIG_HIGHMEM=y
-# CONFIG_X86_PAE is not set
# CONFIG_X86_CPA_STATISTICS is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
@@ -427,6 +422,7 @@ CONFIG_ILLEGAL_POINTER_VALUE=0
# CONFIG_HIGHPTE is not set
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
+# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
@@ -472,8 +468,8 @@ CONFIG_USE_X86_SEG_SUPPORT=y
CONFIG_CC_HAS_SLS=y
CONFIG_CC_HAS_RETURN_THUNK=y
CONFIG_CC_HAS_ENTRY_PADDING=y
-CONFIG_FUNCTION_PADDING_CFI=0
-CONFIG_FUNCTION_PADDING_BYTES=4
+CONFIG_FUNCTION_PADDING_CFI=11
+CONFIG_FUNCTION_PADDING_BYTES=16
CONFIG_CPU_MITIGATIONS=y
# CONFIG_MITIGATION_RETPOLINE is not set
# CONFIG_MITIGATION_GDS is not set
@@ -741,7 +737,8 @@ CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
CONFIG_HAVE_GCC_PLUGINS=y
# CONFIG_GCC_PLUGINS is not set
CONFIG_FUNCTION_ALIGNMENT_4B=y
-CONFIG_FUNCTION_ALIGNMENT=4
+CONFIG_FUNCTION_ALIGNMENT_16B=y
+CONFIG_FUNCTION_ALIGNMENT=16
# end of General architecture-dependent options
CONFIG_RT_MUTEXES=y
@@ -1114,7 +1111,6 @@ CONFIG_NFC_SHDLC=y
#
# Near Field Communication (NFC) devices
#
-# CONFIG_NFC_MEI_PHY is not set
# CONFIG_NFC_SIM is not set
# CONFIG_NFC_PORT100 is not set
# CONFIG_NFC_PN544_I2C is not set
@@ -1607,9 +1603,7 @@ CONFIG_EEPROM_IDT_89HPESX=y
# CONFIG_CB710_CORE is not set
CONFIG_SENSORS_LIS3_I2C=y
CONFIG_ALTERA_STAPL=y
-CONFIG_INTEL_MEI=y
-CONFIG_INTEL_MEI_ME=y
-# CONFIG_INTEL_MEI_TXE is not set
+# CONFIG_INTEL_MEI is not set
# CONFIG_VMWARE_VMCI is not set
CONFIG_ECHO=y
# CONFIG_MISC_ALCOR_PCI is not set
@@ -3412,7 +3406,6 @@ CONFIG_TQMX86_WDT=y
CONFIG_W83977F_WDT=y
CONFIG_MACHZ_WDT=y
CONFIG_SBC_EPX_C3_WATCHDOG=y
-# CONFIG_INTEL_MEI_WDT is not set
CONFIG_NI903X_WDT=y
# CONFIG_NIC7018_WDT is not set
# CONFIG_MEN_A21_WDT is not set
@@ -5752,7 +5745,6 @@ CONFIG_GENERIC_NET_UTILS=y
# CONFIG_PRIME_NUMBERS is not set
CONFIG_RATIONAL=y
CONFIG_GENERIC_IOMAP=y
-CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
CONFIG_ARCH_USE_SYM_ANNOTATIONS=y
@@ -6186,7 +6178,6 @@ CONFIG_SAMPLE_VFIO_MDEV_MDPY=y
CONFIG_SAMPLE_VFIO_MDEV_MBOCHS=y
CONFIG_SAMPLE_ANDROID_BINDERFS=y
CONFIG_SAMPLE_VFS=y
-# CONFIG_SAMPLE_INTEL_MEI is not set
# CONFIG_SAMPLE_TPS6594_PFSM is not set
CONFIG_SAMPLE_WATCHDOG=y
CONFIG_SAMPLE_WATCH_QUEUE=y
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
2025-04-21 8:12 [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#] kernel test robot
@ 2025-04-22 10:16 ` Arnd Bergmann
2025-04-24 2:12 ` Oliver Sang
0 siblings, 1 reply; 47+ messages in thread
From: Arnd Bergmann @ 2025-04-22 10:16 UTC (permalink / raw)
To: kernel test robot
Cc: oe-lkp, kernel test robot, linux-kernel, Ingo Molnar,
Linus Torvalds
On Mon, Apr 21, 2025, at 10:12, kernel test robot wrote:
> Hello,
>
> by this commit, we notice big config diff [1]
>
> then in this rcutorture tests, parent runs quite clean, f388f60ca9 shows
> various random issues.
Thanks for the report!
From my initial reading, my patch most likely caught a preexisting bug,
but my patch itself is correct. It's worth investigating regardless,
at the minimum we should perhaps prevent an invalid configuration from
building or from booting.
> config: i386-randconfig-r071-20250410
Generally, I would not expect 'randconfig' kernels to pass all tests,
and what happened here is that removing the CONFIG_MK8 option made it
pick some completely different CPU
> compiler: gcc-12
> test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
The most relevant options here are
-# CONFIG_M486SX is not set
+CONFIG_M486SX=y
# CONFIG_SMP is not set
CONFIG_X86_GENERIC=y
In theory, setting X86_GENERIC should make a kernel built for an
older CPU work on any newer one. In practice, I'm not surprised
that this fails: While AMD K8 is ten years older than Intel Sandy
Bridge, they are architecturally still very similar. The i486SX
is another decade older, but its design is as far removed from
both K8 and Sandy Bridge as it gets.
It would be nice to not have to support 486sx any more.
We have discussed removing support for older CPUs without
TSC, FPU and CX8 in the past, but so far always kept them
around.
> [ 721.016779][ C0] hardirqs last disabled at (159506):
> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049)
> [ 721.016779][ C0] softirqs last enabled at (159174): handle_softirqs
> (kernel/softirq.c:408 kernel/softirq.c:589)
> [ 721.016779][ C0] softirqs last disabled at (159159): __do_softirq
> (kernel/softirq.c:596)
> [ 721.016779][ C0] CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted
> 6.14.0-rc3-00037-gf388f60ca904 #1
> [ 721.016779][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX,
> 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> [ 721.016779][ C0] EIP: timekeeping_notify
> (kernel/time/timekeeping.c:1522)
Timekeeping code could be related, I see that CONFIG_X86_TSC
is disabled for i486SX configurations, so even if a TSC is present
in the emulated machine, it is not being used to measure time
accurately.
> -CONFIG_X86_CMPXCHG64=y
This could be another issue, if there is code that relies on
the cx8/cmpxchg8b feature to be used. Since this is a non-SMP
kernel, this is less likely to be the cause of the problem.
Can you try what happens when you enable the two options, either
by changing CONFIG_M486SX to CONFIG_M586TSC, or with a patch
like the one below? Note that CONFIG_X86_CMPXCHG64 recently
got renamed to CONFIG_X86_CX8, but they are the exact same thing.
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index f928cf6e3252..ac6cc69060f1 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -317,7 +317,6 @@ config X86_USE_PPRO_CHECKSUM
config X86_TSC
def_bool y
- depends on (MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MATOM) || X86_64
config X86_HAVE_PAE
def_bool y
@@ -325,7 +324,6 @@ config X86_HAVE_PAE
config X86_CX8
def_bool y
- depends on X86_HAVE_PAE || M586TSC || M586MMX || MK6 || MK7 || MGEODEGX1 || MGEODE_LX
# this should be set for all -march=.. options where the compiler
# generates cmov.
Arnd
^ permalink raw reply related [flat|nested] 47+ messages in thread* Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
2025-04-22 10:16 ` Arnd Bergmann
@ 2025-04-24 2:12 ` Oliver Sang
2025-04-24 7:59 ` Arnd Bergmann
0 siblings, 1 reply; 47+ messages in thread
From: Oliver Sang @ 2025-04-24 2:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: oe-lkp, kernel test robot, linux-kernel, Ingo Molnar,
Linus Torvalds, oliver.sang
hi, Arnd,
On Tue, Apr 22, 2025 at 12:16:33PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 21, 2025, at 10:12, kernel test robot wrote:
> > Hello,
> >
> > by this commit, we notice big config diff [1]
> >
> > then in this rcutorture tests, parent runs quite clean, f388f60ca9 shows
> > various random issues.
>
> Thanks for the report!
>
> From my initial reading, my patch most likely caught a preexisting bug,
> but my patch itself is correct. It's worth investigating regardless,
> at the minimum we should perhaps prevent an invalid configuration from
> building or from booting.
>
> > config: i386-randconfig-r071-20250410
>
> Generally, I would not expect 'randconfig' kernels to pass all tests,
> and what happened here is that removing the CONFIG_MK8 option made it
> pick some completely different CPU
>
> > compiler: gcc-12
> > test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>
> The most relevant options here are
>
> -# CONFIG_M486SX is not set
> +CONFIG_M486SX=y
> # CONFIG_SMP is not set
> CONFIG_X86_GENERIC=y
>
> In theory, setting X86_GENERIC should make a kernel built for an
> older CPU work on any newer one. In practice, I'm not surprised
> that this fails: While AMD K8 is ten years older than Intel Sandy
> Bridge, they are architecturally still very similar. The i486SX
> is another decade older, but its design is as far removed from
> both K8 and Sandy Bridge as it gets.
>
> It would be nice to not have to support 486sx any more.
> We have discussed removing support for older CPUs without
> TSC, FPU and CX8 in the past, but so far always kept them
> around.
>
> > [ 721.016779][ C0] hardirqs last disabled at (159506):
> > sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049)
> > [ 721.016779][ C0] softirqs last enabled at (159174): handle_softirqs
> > (kernel/softirq.c:408 kernel/softirq.c:589)
> > [ 721.016779][ C0] softirqs last disabled at (159159): __do_softirq
> > (kernel/softirq.c:596)
> > [ 721.016779][ C0] CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted
> > 6.14.0-rc3-00037-gf388f60ca904 #1
> > [ 721.016779][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX,
> > 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> > [ 721.016779][ C0] EIP: timekeeping_notify
> > (kernel/time/timekeeping.c:1522)
>
> Timekeeping code could be related, I see that CONFIG_X86_TSC
> is disabled for i486SX configurations, so even if a TSC is present
> in the emulated machine, it is not being used to measure time
> accurately.
>
> > -CONFIG_X86_CMPXCHG64=y
>
> This could be another issue, if there is code that relies on
> the cx8/cmpxchg8b feature to be used. Since this is a non-SMP
> kernel, this is less likely to be the cause of the problem.
thanks a lot for all these details!
>
> Can you try what happens when you enable the two options, either
> by changing CONFIG_M486SX to CONFIG_M586TSC, or with a patch
> like the one below? Note that CONFIG_X86_CMPXCHG64 recently
> got renamed to CONFIG_X86_CX8, but they are the exact same thing.
I applied your patch directly upon f388f60ca9 (change for X86_CMPXCHG64
instead of X86_CX8 as you metnioned), commit id is
c1f7ef63239411313163a7b1bff654236f48351c
after building, the config has below diff to f388f60ca9
--- f388f60ca9041a95c9b3f157d316ed7c8f297e44/.config 2025-04-15 15:41:17.009901645 +0800
+++ c1f7ef63239411313163a7b1bff654236f48351c/.config 2025-04-23 09:36:43.718421931 +0800
@@ -351,7 +351,9 @@ CONFIG_X86_F00F_BUG=y
CONFIG_X86_INVD_BUG=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_INTEL_USERCOPY=y
-CONFIG_X86_MINIMUM_CPU_FAMILY=4
+CONFIG_X86_TSC=y
+CONFIG_X86_CMPXCHG64=y
+CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_IA32_FEAT_CTL=y
CONFIG_X86_VMX_FEATURE_NAMES=y
CONFIG_CPU_SUP_INTEL=y
@@ -5745,6 +5747,7 @@ CONFIG_GENERIC_NET_UTILS=y
# CONFIG_PRIME_NUMBERS is not set
CONFIG_RATIONAL=y
CONFIG_GENERIC_IOMAP=y
+CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
CONFIG_ARCH_USE_SYM_ANNOTATIONS=y
by running same tests, now it backs to the clean status like
fc2d5cbe541032e7 (parent of f388f60ca9)
(the statistics data for fc2d5cbe541032e7 and f388f60ca9 has some difference to
the data we shared last time due to some auto cleanup logic in our service which
removes some results which are suspiciously caused by our env problem)
fc2d5cbe541032e7 f388f60ca9041a95c9b3f157d31 c1f7ef63239411313163a7b1bff
---------------- --------------------------- ---------------------------
fail:runs %reproduction fail:runs %reproduction fail:runs
| | | | |
:496 29% 145:494 0% :500 last_state.booting
:496 7% 35:494 0% :500 dmesg.BUG:kernel_hang_in_boot_stage
:496 9% 45:494 0% :500 dmesg.BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
:496 0% 1:494 0% :500 dmesg.EIP:__timer_delete_sync
:496 1% 5:494 0% :500 dmesg.EIP:_raw_spin_unlock_irq
:496 0% 2:494 0% :500 dmesg.EIP:_raw_spin_unlock_irqrestore
:496 0% 1:494 0% :500 dmesg.EIP:console_emit_next_record
:496 0% 1:494 0% :500 dmesg.EIP:handle_softirqs
:496 1% 3:494 0% :500 dmesg.EIP:lock_acquire
:496 0% 2:494 0% :500 dmesg.EIP:lock_release
:496 0% 1:494 0% :500 dmesg.EIP:queue_delayed_work_on
:496 9% 45:494 0% :500 dmesg.EIP:timekeeping_notify
:496 3% 14:494 0% :500 dmesg.INFO:rcu_preempt_detected_stalls_on_CPUs/tasks
:496 6% 32:494 0% :500 dmesg.INFO:task_blocked_for_more_than#seconds
:496 9% 45:494 0% :500 dmesg.Kernel_panic-not_syncing:softlockup:hung_tasks
>
> diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
> index f928cf6e3252..ac6cc69060f1 100644
> --- a/arch/x86/Kconfig.cpu
> +++ b/arch/x86/Kconfig.cpu
> @@ -317,7 +317,6 @@ config X86_USE_PPRO_CHECKSUM
>
> config X86_TSC
> def_bool y
> - depends on (MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MATOM) || X86_64
>
> config X86_HAVE_PAE
> def_bool y
> @@ -325,7 +324,6 @@ config X86_HAVE_PAE
>
> config X86_CX8
> def_bool y
> - depends on X86_HAVE_PAE || M586TSC || M586MMX || MK6 || MK7 || MGEODEGX1 || MGEODE_LX
>
> # this should be set for all -march=.. options where the compiler
> # generates cmov.
>
> Arnd
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
2025-04-24 2:12 ` Oliver Sang
@ 2025-04-24 7:59 ` Arnd Bergmann
2025-04-24 16:07 ` Linus Torvalds
2025-04-27 5:48 ` Oliver Sang
0 siblings, 2 replies; 47+ messages in thread
From: Arnd Bergmann @ 2025-04-24 7:59 UTC (permalink / raw)
To: kernel test robot
Cc: oe-lkp, kernel test robot, linux-kernel, Ingo Molnar,
Linus Torvalds, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
On Thu, Apr 24, 2025, at 04:12, Oliver Sang wrote:
> On Tue, Apr 22, 2025 at 12:16:33PM +0200, Arnd Bergmann wrote:
Cc: x86 and timekeeping maintainers, see
https://lore.kernel.org/lkml/202504211553.3ba9400-lkp@intel.com/
for the thread so far.
>> > [ 721.016779][ C0] hardirqs last disabled at (159506):
>> > sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049)
>> > [ 721.016779][ C0] softirqs last enabled at (159174): handle_softirqs
>> > (kernel/softirq.c:408 kernel/softirq.c:589)
>> > [ 721.016779][ C0] softirqs last disabled at (159159): __do_softirq
>> > (kernel/softirq.c:596)
>> > [ 721.016779][ C0] CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted
>> > 6.14.0-rc3-00037-gf388f60ca904 #1
>> > [ 721.016779][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX,
>> > 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
>> > [ 721.016779][ C0] EIP: timekeeping_notify
>> > (kernel/time/timekeeping.c:1522)
>>
>> Timekeeping code could be related, I see that CONFIG_X86_TSC
>> is disabled for i486SX configurations, so even if a TSC is present
>> in the emulated machine, it is not being used to measure time
>> accurately.
>>
>> > -CONFIG_X86_CMPXCHG64=y
>>
>> This could be another issue, if there is code that relies on
>> the cx8/cmpxchg8b feature to be used. Since this is a non-SMP
>> kernel, this is less likely to be the cause of the problem.
>
> thanks a lot for all these details!
>
>>
>> Can you try what happens when you enable the two options, either
>> by changing CONFIG_M486SX to CONFIG_M586TSC, or with a patch
>> like the one below? Note that CONFIG_X86_CMPXCHG64 recently
>> got renamed to CONFIG_X86_CX8, but they are the exact same thing.
>
> I applied your patch directly upon f388f60ca9 (change for X86_CMPXCHG64
> instead of X86_CX8 as you metnioned), commit id is
> c1f7ef63239411313163a7b1bff654236f48351c
>
...
> by running same tests, now it backs to the clean status like
> fc2d5cbe541032e7 (parent of f388f60ca9)
Thanks for confirming. So a 486-targeted kernel still passes
your tests on modern hardware if we force TSC and CX8 to
be enabled, but the boot fails if the options are turned
off in Kconfig (though available in emulated hardware).
To be completely sure, you could re-run the same test with
just one of these enabled, but I'm rather sure that the TSC
is the root cause. I tried reproducing the problem locally
with your .config on a qemu/tcg emulation running on an
arm64 host, but this seems to run fine, including the
rcutorture tests.
Comparing my results with your log file, I see that your
crash happens while changing the clocksource:
Your dmesg:
[ 92.548514][ T1] hpet0: 3 comparators, 64-bit 100.000000 MHz counter
[ 721.016745][ C0] watchdog: BUG: soft lockup - CPU#0 stuck for 626s! [swapper:1]
My dmesg:
[ 1.154511][ T1] hpet0: 3 comparators, 64-bit 100.000000 MHz counter
[ 1.157896][ T1] clocksource: Switched to clocksource tsc-early
There are also clearly some differences between TCG and KVM in
the handling of TSC, e.g. I get this warning from qemu itself
for the SandyBridge CPU:
qemu-system-i386: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
I tried a few other variations, including KVM on an x86 laptop
(using kvmclock or tsc-early clocksource), but none of them failed
the way yours did.
Arnd
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
2025-04-24 7:59 ` Arnd Bergmann
@ 2025-04-24 16:07 ` Linus Torvalds
2025-04-24 17:54 ` [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs Ingo Molnar
2025-04-26 4:06 ` [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#] H. Peter Anvin
2025-04-27 5:48 ` Oliver Sang
1 sibling, 2 replies; 47+ messages in thread
From: Linus Torvalds @ 2025-04-24 16:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kernel test robot, oe-lkp, kernel test robot, linux-kernel,
Ingo Molnar, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
On Thu, 24 Apr 2025 at 01:01, Arnd Bergmann <arnd@arndb.de> wrote:
>
> Thanks for confirming. So a 486-targeted kernel still passes
> your tests on modern hardware if we force TSC and CX8 to
> be enabled, but the boot fails if the options are turned
> off in Kconfig (though available in emulated hardware).
I wouldn't expect CX8 to really matter - it causes us to generate
extra code to pick one over the other, but on modern hardware we'll
still always then dynamically pick the cmpxchg8b instruction.
Could it trigger bugs in our alternatives, or some miscompilation due
to the extra complexity? Sure. But it does sound unlikely.
> To be completely sure, you could re-run the same test with
> just one of these enabled, but I'm rather sure that the TSC
> is the root cause.
Agreed.
Particularly when the lockup is then in timekeeping_notify() during
the initial initcalls -> clocksource_select(), I'm pretty sure this is
purely about TSC.
That said, maybe the problem is in the watchdog logic, because
clocksource_done_booting() is what starts the watchdog thread .
So it might be the watchdog code itself that then gets confused
(because of some "don't use tsc" case that never gets any testing in
real life) and triggers immediately - and then points the finger at
the clocksource code only because that's what is still running.
Because CONFIG_X86_TSC does cause some oddities: we end up still
*using* the TSC for many things if the hardware supports it (which
modern hardware obviously does), but then other things get disabled
entirely.
For example, this:
/*
* Boot-time check whether the TSCs are synchronized across
* all CPUs/cores:
*/
#ifdef CONFIG_X86_TSC
extern bool tsc_store_and_check_tsc_adjust(bool bootcpu);
extern void tsc_verify_tsc_adjust(bool resume);
extern void check_tsc_sync_target(void);
#else
static inline bool tsc_store_and_check_tsc_adjust(bool bootcpu) {
return false; }
static inline void tsc_verify_tsc_adjust(bool resume) { }
static inline void check_tsc_sync_target(void) { }
#endif
So that tsc_store_and_check_tsc_adjust() thing etc never gets run,
even though we actually *do* use TSC for get_cycles() and friends,
because *that* code checks the runtime status too:
Now, none of that should matter - because all *those* things are about
details that simply aren't relevant for any of this case - but maybe
there is some other situation that has similar "I'm actually using the
TSC through get_cycles(), but I didn't do some setup because X86_TSC
wasn't on.."
I really get the feeling that it's time to leave i486 support behind.
There's zero real reason for anybody to waste one second of
development effort on this kind of issue.
Linus
^ permalink raw reply [flat|nested] 47+ messages in thread* [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-04-24 16:07 ` Linus Torvalds
@ 2025-04-24 17:54 ` Ingo Molnar
2025-04-24 18:01 ` Ingo Molnar
2025-04-24 21:27 ` Arnd Bergmann
2025-04-26 4:06 ` [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#] H. Peter Anvin
1 sibling, 2 replies; 47+ messages in thread
From: Ingo Molnar @ 2025-04-24 17:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Arnd Bergmann, kernel test robot, oe-lkp, kernel test robot,
linux-kernel, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> I really get the feeling that it's time to leave i486 support behind.
> There's zero real reason for anybody to waste one second of
> development effort on this kind of issue.
Fully agreed!
And to turn this idea into code, here's a very raw RFC series that
starts removing non-TSC 586 and 486 code and related support code from
the x86 architecture, with the goal to make TSC and CX8 (CMPXCHG8B)
support unconditionally available:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/tip.git WIP.x86/cpu
The full diffstat is nice, primarily due to the removal of the math-emu
library:
83 files changed, 30 insertions(+), 14683 deletions(-)
But even without the math-emu/ removal and the drivers/ pruning it's a
substantial simplification:
20 files changed, 29 insertions(+), 629 deletions(-)
The patches most relevant to this discussion should be:
x86/cpu: Remove M486/M486SX/ELAN support
...
x86/cpu: Remove TSC-less CONFIG_M586 support
x86/cpu: Make CONFIG_X86_TSC unconditional
x86/cpu: Make CONFIG_X86_CX8 unconditional
x86/percpu: Remove !CONFIG_X86_CX8 methods
x86/atomics: Remove !CONFIG_X86_CX8 methods
If there's no big objections about the scope of removal I'll finish it
by removing the non-TSC complications as well, and send out the series
to lkml for further review.
( Note that some of the patches in there are still WIP, as the branch
name suggests. )
Thanks,
Ingo
================>
Ingo Molnar (17):
x86/cpu: Remove M486/M486SX/ELAN support
x86/cpu: Remove the CONFIG_X86_INVD_BUG quirk
x86/cpu, cpufreq: Remove AMD ELAN support
x86/fpu: Remove MATH_EMULATION and related glue code
x86/fpu: Remove the 'no387' boot option
x86/fpu: Remove the math-emu/ FPU emulation library
x86/platform: Remove CONFIG_X86_RDC321X support
arch/x86, gpio: Remove GPIO_RDC321X support
arch/x86, watchdog: Remove the RDC321X_WDT watchdog driver
arch/x86, mfd: Remove MFD_RDC321X support
x86/reboot: Remove the RDC321X reboot quirk
x86/cpu: Remove CPU_SUP_UMC_32 support
x86/cpu: Remove TSC-less CONFIG_M586 support
x86/cpu: Make CONFIG_X86_TSC unconditional
x86/cpu: Make CONFIG_X86_CX8 unconditional
x86/percpu: Remove !X86_CX8 methods
x86/atomics: Remove !CONFIG_X86_CX8 methods
Documentation/admin-guide/kernel-parameters.txt | 4 -
arch/x86/Kconfig | 71 +-
arch/x86/Kconfig.cpu | 73 +-
arch/x86/Kconfig.cpufeatures | 2 -
arch/x86/Makefile | 1 -
arch/x86/Makefile_32.cpu | 6 -
arch/x86/include/asm/asm-prototypes.h | 4 -
arch/x86/include/asm/atomic64_32.h | 17 +-
arch/x86/include/asm/cmpxchg_32.h | 86 +-
arch/x86/include/asm/fpu/api.h | 6 -
arch/x86/include/asm/percpu.h | 6 +-
arch/x86/include/asm/vermagic.h | 8 -
arch/x86/kernel/cpu/common.c | 7 -
arch/x86/kernel/cpu/umc.c | 26 -
arch/x86/kernel/fpu/core.c | 5 -
arch/x86/kernel/fpu/init.c | 9 +-
arch/x86/kernel/reboot_fixups_32.c | 14 -
arch/x86/kernel/traps.c | 21 -
arch/x86/lib/Makefile | 4 -
arch/x86/lib/atomic64_386_32.S | 195 ---
arch/x86/lib/cmpxchg8b_emu.S | 97 --
arch/x86/math-emu/Makefile | 30 -
arch/x86/math-emu/README | 427 ------
arch/x86/math-emu/control_w.h | 46 -
arch/x86/math-emu/div_Xsig.S | 367 -----
arch/x86/math-emu/div_small.S | 48 -
arch/x86/math-emu/errors.c | 686 ----------
arch/x86/math-emu/exception.h | 51 -
arch/x86/math-emu/fpu_arith.c | 153 ---
arch/x86/math-emu/fpu_asm.h | 32 -
arch/x86/math-emu/fpu_aux.c | 267 ----
arch/x86/math-emu/fpu_emu.h | 218 ---
arch/x86/math-emu/fpu_entry.c | 718 ----------
arch/x86/math-emu/fpu_etc.c | 136 --
arch/x86/math-emu/fpu_proto.h | 157 ---
arch/x86/math-emu/fpu_system.h | 130 --
arch/x86/math-emu/fpu_tags.c | 116 --
arch/x86/math-emu/fpu_trig.c | 1649 -----------------------
arch/x86/math-emu/get_address.c | 401 ------
arch/x86/math-emu/load_store.c | 322 -----
arch/x86/math-emu/mul_Xsig.S | 179 ---
arch/x86/math-emu/poly.h | 115 --
arch/x86/math-emu/poly_2xm1.c | 146 --
arch/x86/math-emu/poly_atan.c | 209 ---
arch/x86/math-emu/poly_l2.c | 245 ----
arch/x86/math-emu/poly_sin.c | 379 ------
arch/x86/math-emu/poly_tan.c | 213 ---
arch/x86/math-emu/polynom_Xsig.S | 137 --
arch/x86/math-emu/reg_add_sub.c | 334 -----
arch/x86/math-emu/reg_compare.c | 479 -------
arch/x86/math-emu/reg_constant.c | 123 --
arch/x86/math-emu/reg_constant.h | 26 -
arch/x86/math-emu/reg_convert.c | 47 -
arch/x86/math-emu/reg_divide.c | 183 ---
arch/x86/math-emu/reg_ld_str.c | 1220 -----------------
arch/x86/math-emu/reg_mul.c | 116 --
arch/x86/math-emu/reg_norm.S | 150 ---
arch/x86/math-emu/reg_round.S | 711 ----------
arch/x86/math-emu/reg_u_add.S | 169 ---
arch/x86/math-emu/reg_u_div.S | 474 -------
arch/x86/math-emu/reg_u_mul.S | 150 ---
arch/x86/math-emu/reg_u_sub.S | 274 ----
arch/x86/math-emu/round_Xsig.S | 142 --
arch/x86/math-emu/shr_Xsig.S | 89 --
arch/x86/math-emu/status_w.h | 68 -
arch/x86/math-emu/version.h | 12 -
arch/x86/math-emu/wm_shrx.S | 207 ---
arch/x86/math-emu/wm_sqrt.S | 472 -------
drivers/cpufreq/Kconfig.x86 | 26 -
drivers/cpufreq/Makefile | 2 -
drivers/cpufreq/elanfreq.c | 227 ----
drivers/cpufreq/sc520_freq.c | 137 --
drivers/gpio/Kconfig | 8 -
drivers/gpio/Makefile | 1 -
drivers/gpio/gpio-rdc321x.c | 197 ---
drivers/mfd/Kconfig | 9 -
drivers/mfd/Makefile | 1 -
drivers/mfd/rdc321x-southbridge.c | 96 --
drivers/watchdog/Kconfig | 11 -
drivers/watchdog/Makefile | 1 -
drivers/watchdog/rdc321x_wdt.c | 281 ----
include/linux/mfd/rdc321x.h | 27 -
lib/atomic64_test.c | 4 +-
83 files changed, 30 insertions(+), 14683 deletions(-)
delete mode 100644 arch/x86/kernel/cpu/umc.c
delete mode 100644 arch/x86/lib/atomic64_386_32.S
delete mode 100644 arch/x86/lib/cmpxchg8b_emu.S
delete mode 100644 arch/x86/math-emu/Makefile
delete mode 100644 arch/x86/math-emu/README
delete mode 100644 arch/x86/math-emu/control_w.h
delete mode 100644 arch/x86/math-emu/div_Xsig.S
delete mode 100644 arch/x86/math-emu/div_small.S
delete mode 100644 arch/x86/math-emu/errors.c
delete mode 100644 arch/x86/math-emu/exception.h
delete mode 100644 arch/x86/math-emu/fpu_arith.c
delete mode 100644 arch/x86/math-emu/fpu_asm.h
delete mode 100644 arch/x86/math-emu/fpu_aux.c
delete mode 100644 arch/x86/math-emu/fpu_emu.h
delete mode 100644 arch/x86/math-emu/fpu_entry.c
delete mode 100644 arch/x86/math-emu/fpu_etc.c
delete mode 100644 arch/x86/math-emu/fpu_proto.h
delete mode 100644 arch/x86/math-emu/fpu_system.h
delete mode 100644 arch/x86/math-emu/fpu_tags.c
delete mode 100644 arch/x86/math-emu/fpu_trig.c
delete mode 100644 arch/x86/math-emu/get_address.c
delete mode 100644 arch/x86/math-emu/load_store.c
delete mode 100644 arch/x86/math-emu/mul_Xsig.S
delete mode 100644 arch/x86/math-emu/poly.h
delete mode 100644 arch/x86/math-emu/poly_2xm1.c
delete mode 100644 arch/x86/math-emu/poly_atan.c
delete mode 100644 arch/x86/math-emu/poly_l2.c
delete mode 100644 arch/x86/math-emu/poly_sin.c
delete mode 100644 arch/x86/math-emu/poly_tan.c
delete mode 100644 arch/x86/math-emu/polynom_Xsig.S
delete mode 100644 arch/x86/math-emu/reg_add_sub.c
delete mode 100644 arch/x86/math-emu/reg_compare.c
delete mode 100644 arch/x86/math-emu/reg_constant.c
delete mode 100644 arch/x86/math-emu/reg_constant.h
delete mode 100644 arch/x86/math-emu/reg_convert.c
delete mode 100644 arch/x86/math-emu/reg_divide.c
delete mode 100644 arch/x86/math-emu/reg_ld_str.c
delete mode 100644 arch/x86/math-emu/reg_mul.c
delete mode 100644 arch/x86/math-emu/reg_norm.S
delete mode 100644 arch/x86/math-emu/reg_round.S
delete mode 100644 arch/x86/math-emu/reg_u_add.S
delete mode 100644 arch/x86/math-emu/reg_u_div.S
delete mode 100644 arch/x86/math-emu/reg_u_mul.S
delete mode 100644 arch/x86/math-emu/reg_u_sub.S
delete mode 100644 arch/x86/math-emu/round_Xsig.S
delete mode 100644 arch/x86/math-emu/shr_Xsig.S
delete mode 100644 arch/x86/math-emu/status_w.h
delete mode 100644 arch/x86/math-emu/version.h
delete mode 100644 arch/x86/math-emu/wm_shrx.S
delete mode 100644 arch/x86/math-emu/wm_sqrt.S
delete mode 100644 drivers/cpufreq/elanfreq.c
delete mode 100644 drivers/cpufreq/sc520_freq.c
delete mode 100644 drivers/gpio/gpio-rdc321x.c
delete mode 100644 drivers/mfd/rdc321x-southbridge.c
delete mode 100644 drivers/watchdog/rdc321x_wdt.c
delete mode 100644 include/linux/mfd/rdc321x.h
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-04-24 17:54 ` [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs Ingo Molnar
@ 2025-04-24 18:01 ` Ingo Molnar
2025-04-24 21:27 ` Arnd Bergmann
1 sibling, 0 replies; 47+ messages in thread
From: Ingo Molnar @ 2025-04-24 18:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Arnd Bergmann, kernel test robot, oe-lkp, kernel test robot,
linux-kernel, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra
* Ingo Molnar <mingo@kernel.org> wrote:
> The patches most relevant to this discussion should be:
>
> x86/cpu: Remove M486/M486SX/ELAN support
> ...
> x86/cpu: Remove TSC-less CONFIG_M586 support
> x86/cpu: Make CONFIG_X86_TSC unconditional
> x86/cpu: Make CONFIG_X86_CX8 unconditional
> x86/percpu: Remove !CONFIG_X86_CX8 methods
> x86/atomics: Remove !CONFIG_X86_CX8 methods
also:
> x86/cpu: Remove TSC-less CONFIG_M586 support
Thanks,
Ingo
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-04-24 17:54 ` [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs Ingo Molnar
2025-04-24 18:01 ` Ingo Molnar
@ 2025-04-24 21:27 ` Arnd Bergmann
2025-04-25 7:40 ` Ingo Molnar
1 sibling, 1 reply; 47+ messages in thread
From: Arnd Bergmann @ 2025-04-24 21:27 UTC (permalink / raw)
To: Ingo Molnar, Linus Torvalds
Cc: kernel test robot, oe-lkp, kernel test robot, linux-kernel,
John Stultz, Thomas Gleixner, Stephen Boyd, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra
On Thu, Apr 24, 2025, at 19:54, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> I really get the feeling that it's time to leave i486 support behind.
>> There's zero real reason for anybody to waste one second of
>> development effort on this kind of issue.
>
> Fully agreed!
>
> And to turn this idea into code, here's a very raw RFC series that
> starts removing non-TSC 586 and 486 code and related support code from
> the x86 architecture, with the goal to make TSC and CX8 (CMPXCHG8B)
> support unconditionally available:
Yes, makes sense. I had considered doing something like this in
my cleanup for large machines, but decided to keep stop there
because I know that there are users that love their museum pieces.
For embedded systems, I'm quite sure that the AMD Élan, SIS 55x,
RDC321x and Vortex86SX have ended their useful life. You may
still be able to buy Vortex86SX machines and they are probably
still running somewhere, but the entire point of those machines
is to run old software. DM&P provides patches for linux-2.6.29
and Windows CE 6.0 for the SX chips.
The desktop Socket 7 clones without CX8/TSC all got discontinued
over 25 years ago, and they were rare even then.
> x86/platform: Remove CONFIG_X86_RDC321X support
> arch/x86, gpio: Remove GPIO_RDC321X support
> arch/x86, watchdog: Remove the RDC321X_WDT watchdog driver
> arch/x86, mfd: Remove MFD_RDC321X support
> x86/reboot: Remove the RDC321X reboot quirk
I'm not sure about the RDC321X bits. Obviously the original
321x/861x/vortex86sx chips are obsolete and can be removed,
but the product line is still actively developed by RDC and
DM&P, and I suspect that some of the drivers are still used
on 586tsc-class (vortex86dx, vortex86mx) and 686-class
(vortex86dx3, vortex86ex) SoCs that do run modern kernels and
get updates.
> x86/cpu: Remove CPU_SUP_UMC_32 support
> x86/cpu: Remove TSC-less CONFIG_M586 support
I think Winchip6 (486-class, no tsc, no cx8) and Winchip3D
(486-class, with tsc but no cx8) need to go as well then.
At this point, maybe we can consider removing
CONFIG_X86_GENERIC and just always build kernels that work
across a wide set of CPUs: Only CMOV and PAE still require a
CPU with the hardware support, and X86_L1_CACHE_SHIFT needs to
be at least 6 (64 byte) for compatibility, but everything
else should just be a tuning option.
Arnd
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-04-24 21:27 ` Arnd Bergmann
@ 2025-04-25 7:40 ` Ingo Molnar
2025-04-25 9:30 ` Arnd Bergmann
0 siblings, 1 reply; 47+ messages in thread
From: Ingo Molnar @ 2025-04-25 7:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Torvalds, kernel test robot, oe-lkp, kernel test robot,
linux-kernel, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra
* Arnd Bergmann <arnd@arndb.de> wrote:
> > x86/platform: Remove CONFIG_X86_RDC321X support
> > arch/x86, gpio: Remove GPIO_RDC321X support
> > arch/x86, watchdog: Remove the RDC321X_WDT watchdog driver
> > arch/x86, mfd: Remove MFD_RDC321X support
> > x86/reboot: Remove the RDC321X reboot quirk
>
> I'm not sure about the RDC321X bits. Obviously the original
> 321x/861x/vortex86sx chips are obsolete and can be removed,
> but the product line is still actively developed by RDC and
> DM&P, and I suspect that some of the drivers are still used
> on 586tsc-class (vortex86dx, vortex86mx) and 686-class
> (vortex86dx3, vortex86ex) SoCs that do run modern kernels and
> get updates.
So CONFIG_X86_RDC321X actively selects M486:
+++ b/arch/x86/Kconfig
config X86_RDC321X
bool "RDC R-321x SoC"
depends on X86_32
depends on X86_EXTENDED_PLATFORM
select M486
^^^^^^^^^^^
select X86_REBOOTFIXUPS
But indeed the other drivers are not dependent on M486, at least
overtly:
arch/x86, mfd: Remove MFD_RDC321X support
arch/x86, watchdog: Remove the RDC321X_WDT watchdog driver
arch/x86, gpio: Remove GPIO_RDC321X support
Although the watchdog driver has this indirect dependency:
drivers/watchdog/Kconfig: depends on X86_RDC321X || COMPILE_TEST
But the 486 kernel would work on any 586/686 upgraded boards as well.
Anyway, I've dropped the mfd/watchdog/gpio removal patches, no harm in
keeping these drivers, and I've switched the watchdog driver over to
X86_32:
config RDC321X_WDT
tristate "RDC R-321x SoC watchdog"
depends on X86_32 || COMPILE_TEST
There's also no harm in keeping the southbridge reboot quirk I suppose,
so I've dropped this as well:
x86/reboot: Remove the RDC321X reboot quirk
> > x86/cpu: Remove CPU_SUP_UMC_32 support
> > x86/cpu: Remove TSC-less CONFIG_M586 support
>
> I think Winchip6 (486-class, no tsc, no cx8) and Winchip3D
> (486-class, with tsc but no cx8) need to go as well then.
Okay, agreed, I've added this patch to the tree:
bf82539ad9f6 x86/cpu: Remove CONFIG_MWINCHIP3D/MWINCHIPC6
arch/x86/Kconfig.cpu | 28 ++++------------------------
arch/x86/Makefile_32.cpu | 2 --
arch/x86/include/asm/vermagic.h | 4 ----
3 files changed, 4 insertions(+), 30 deletions(-)
> At this point, maybe we can consider removing CONFIG_X86_GENERIC and
> just always build kernels that work across a wide set of CPUs: Only
> CMOV and PAE still require a CPU with the hardware support, and
> X86_L1_CACHE_SHIFT needs to be at least 6 (64 byte) for
> compatibility, but everything else should just be a tuning option.
Agreed.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-04-25 7:40 ` Ingo Molnar
@ 2025-04-25 9:30 ` Arnd Bergmann
0 siblings, 0 replies; 47+ messages in thread
From: Arnd Bergmann @ 2025-04-25 9:30 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, kernel test robot, oe-lkp, kernel test robot,
linux-kernel, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra
On Fri, Apr 25, 2025, at 09:40, Ingo Molnar wrote:
> * Arnd Bergmann <arnd@arndb.de> wrote:
>
>> > x86/platform: Remove CONFIG_X86_RDC321X support
>> > arch/x86, gpio: Remove GPIO_RDC321X support
>> > arch/x86, watchdog: Remove the RDC321X_WDT watchdog driver
>> > arch/x86, mfd: Remove MFD_RDC321X support
>> > x86/reboot: Remove the RDC321X reboot quirk
>>
>> I'm not sure about the RDC321X bits. Obviously the original
>> 321x/861x/vortex86sx chips are obsolete and can be removed,
>> but the product line is still actively developed by RDC and
>> DM&P, and I suspect that some of the drivers are still used
>> on 586tsc-class (vortex86dx, vortex86mx) and 686-class
>> (vortex86dx3, vortex86ex) SoCs that do run modern kernels and
>> get updates.
>
> So CONFIG_X86_RDC321X actively selects M486:
>
> +++ b/arch/x86/Kconfig
>
> config X86_RDC321X
> bool "RDC R-321x SoC"
> depends on X86_32
> depends on X86_EXTENDED_PLATFORM
> select M486
> ^^^^^^^^^^^
> select X86_REBOOTFIXUPS
Right, when the code got added, it was certainly for that
specific chip, which I think is 486SX compatible.
The 'select M486' here doesn't actually do anything because
Kconfig silently ignores 'select' for 'choice' symbols.
> But indeed the other drivers are not dependent on M486, at least
> overtly:
>
> arch/x86, mfd: Remove MFD_RDC321X support
> arch/x86, watchdog: Remove the RDC321X_WDT watchdog driver
> arch/x86, gpio: Remove GPIO_RDC321X support
>
> Although the watchdog driver has this indirect dependency:
>
> drivers/watchdog/Kconfig: depends on X86_RDC321X || COMPILE_TEST
> Anyway, I've dropped the mfd/watchdog/gpio removal patches, no harm in
> keeping these drivers.
Thanks. We should still revisit all these separately and see which
ones are used on more modern RDC/Vortex86 chips, as the relation
between the brands isn't well documented.
I found an older lspci output from Xcore86MX/Vortex86MX showing
that is uses an RDC R6021/R6036 bridge instead of R6020/R6030
on the RDC321x:
https://lore.kernel.org/all/4CC80AF3.9040708@croler.net/
The Vortex86DX (585tsc compatible) datasheet in turn lists
an R6021/R6031, which means the driver won't work out of the box,
but it's probably not far off either if someone just adds
the PCI ID.
Clearly nobody has done that so far, which would indicate that
not a lot of people run vortex86 /and/ realize it's related
to rdc321x.
> and I've switched the watchdog driver over to X86_32:
>
> config RDC321X_WDT
> tristate "RDC R-321x SoC watchdog"
> depends on X86_32 || COMPILE_TEST
How about 'CPU_SUP_VORTEX_32 || COMPILE_TEST'?
> There's also no harm in keeping the southbridge reboot quirk I suppose,
> so I've dropped this as well:
>
> x86/reboot: Remove the RDC321X reboot quirk
Right. Same thing here: the code probably still works on later
R603x south bridges, but only triggers on the R6030 PCI ID
that is not used on supported chips. Most likely nothing
needs it.
Arnd
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
2025-04-24 16:07 ` Linus Torvalds
2025-04-24 17:54 ` [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs Ingo Molnar
@ 2025-04-26 4:06 ` H. Peter Anvin
1 sibling, 0 replies; 47+ messages in thread
From: H. Peter Anvin @ 2025-04-26 4:06 UTC (permalink / raw)
To: Linus Torvalds, Arnd Bergmann
Cc: kernel test robot, oe-lkp, kernel test robot, linux-kernel,
Ingo Molnar, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86
On April 24, 2025 9:07:50 AM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Thu, 24 Apr 2025 at 01:01, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> Thanks for confirming. So a 486-targeted kernel still passes
>> your tests on modern hardware if we force TSC and CX8 to
>> be enabled, but the boot fails if the options are turned
>> off in Kconfig (though available in emulated hardware).
>
>I wouldn't expect CX8 to really matter - it causes us to generate
>extra code to pick one over the other, but on modern hardware we'll
>still always then dynamically pick the cmpxchg8b instruction.
>
>Could it trigger bugs in our alternatives, or some miscompilation due
>to the extra complexity? Sure. But it does sound unlikely.
>
>> To be completely sure, you could re-run the same test with
>> just one of these enabled, but I'm rather sure that the TSC
>> is the root cause.
>
>Agreed.
>
>Particularly when the lockup is then in timekeeping_notify() during
>the initial initcalls -> clocksource_select(), I'm pretty sure this is
>purely about TSC.
>
>That said, maybe the problem is in the watchdog logic, because
>clocksource_done_booting() is what starts the watchdog thread .
>
>So it might be the watchdog code itself that then gets confused
>(because of some "don't use tsc" case that never gets any testing in
>real life) and triggers immediately - and then points the finger at
>the clocksource code only because that's what is still running.
>
>Because CONFIG_X86_TSC does cause some oddities: we end up still
>*using* the TSC for many things if the hardware supports it (which
>modern hardware obviously does), but then other things get disabled
>entirely.
>
>For example, this:
>
> /*
> * Boot-time check whether the TSCs are synchronized across
> * all CPUs/cores:
> */
> #ifdef CONFIG_X86_TSC
> extern bool tsc_store_and_check_tsc_adjust(bool bootcpu);
> extern void tsc_verify_tsc_adjust(bool resume);
> extern void check_tsc_sync_target(void);
> #else
> static inline bool tsc_store_and_check_tsc_adjust(bool bootcpu) {
>return false; }
> static inline void tsc_verify_tsc_adjust(bool resume) { }
> static inline void check_tsc_sync_target(void) { }
> #endif
>
>So that tsc_store_and_check_tsc_adjust() thing etc never gets run,
>even though we actually *do* use TSC for get_cycles() and friends,
>because *that* code checks the runtime status too:
>
>Now, none of that should matter - because all *those* things are about
>details that simply aren't relevant for any of this case - but maybe
>there is some other situation that has similar "I'm actually using the
>TSC through get_cycles(), but I didn't do some setup because X86_TSC
>wasn't on.."
>
>I really get the feeling that it's time to leave i486 support behind.
>There's zero real reason for anybody to waste one second of
>development effort on this kind of issue.
>
> Linus
Well, isn't the whole point that his patches remove the cx8 fallback code?
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
2025-04-24 7:59 ` Arnd Bergmann
2025-04-24 16:07 ` Linus Torvalds
@ 2025-04-27 5:48 ` Oliver Sang
2025-04-27 12:07 ` Arnd Bergmann
2025-04-27 16:39 ` Linus Torvalds
1 sibling, 2 replies; 47+ messages in thread
From: Oliver Sang @ 2025-04-27 5:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: oe-lkp, kernel test robot, linux-kernel, Ingo Molnar,
Linus Torvalds, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, oliver.sang
hi, Arnd,
On Thu, Apr 24, 2025 at 09:59:38AM +0200, Arnd Bergmann wrote:
> On Thu, Apr 24, 2025, at 04:12, Oliver Sang wrote:
> > On Tue, Apr 22, 2025 at 12:16:33PM +0200, Arnd Bergmann wrote:
>
> Cc: x86 and timekeeping maintainers, see
> https://lore.kernel.org/lkml/202504211553.3ba9400-lkp@intel.com/
> for the thread so far.
>
> >> > [ 721.016779][ C0] hardirqs last disabled at (159506):
> >> > sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049)
> >> > [ 721.016779][ C0] softirqs last enabled at (159174): handle_softirqs
> >> > (kernel/softirq.c:408 kernel/softirq.c:589)
> >> > [ 721.016779][ C0] softirqs last disabled at (159159): __do_softirq
> >> > (kernel/softirq.c:596)
> >> > [ 721.016779][ C0] CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted
> >> > 6.14.0-rc3-00037-gf388f60ca904 #1
> >> > [ 721.016779][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX,
> >> > 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> >> > [ 721.016779][ C0] EIP: timekeeping_notify
> >> > (kernel/time/timekeeping.c:1522)
> >>
> >> Timekeeping code could be related, I see that CONFIG_X86_TSC
> >> is disabled for i486SX configurations, so even if a TSC is present
> >> in the emulated machine, it is not being used to measure time
> >> accurately.
> >>
> >> > -CONFIG_X86_CMPXCHG64=y
> >>
> >> This could be another issue, if there is code that relies on
> >> the cx8/cmpxchg8b feature to be used. Since this is a non-SMP
> >> kernel, this is less likely to be the cause of the problem.
> >
> > thanks a lot for all these details!
> >
> >>
> >> Can you try what happens when you enable the two options, either
> >> by changing CONFIG_M486SX to CONFIG_M586TSC, or with a patch
> >> like the one below? Note that CONFIG_X86_CMPXCHG64 recently
> >> got renamed to CONFIG_X86_CX8, but they are the exact same thing.
> >
> > I applied your patch directly upon f388f60ca9 (change for X86_CMPXCHG64
> > instead of X86_CX8 as you metnioned), commit id is
> > c1f7ef63239411313163a7b1bff654236f48351c
> >
> ...
> > by running same tests, now it backs to the clean status like
> > fc2d5cbe541032e7 (parent of f388f60ca9)
>
> Thanks for confirming. So a 486-targeted kernel still passes
> your tests on modern hardware if we force TSC and CX8 to
> be enabled, but the boot fails if the options are turned
> off in Kconfig (though available in emulated hardware).
>
> To be completely sure, you could re-run the same test with
> just one of these enabled, but I'm rather sure that the TSC
> is the root cause.
just FYI. we rerun the tests. if only enable X86_TSC, the config diff is
--- /pkg/linux/i386-randconfig-r071-20250410/gcc-12/f388f60ca9041a95c9b3f157d316ed7c8f297e44/.config 2025-04-15 15:41:17.009901645 +0800
+++ /pkg/linux/i386-randconfig-r071-20250410/gcc-12/801597ddaae3bdc15546df3d0eba6e9e4e157b8d/.config 2025-04-25 14:24:49.488257697 +0800
@@ -351,6 +351,7 @@ CONFIG_X86_F00F_BUG=y
CONFIG_X86_INVD_BUG=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_INTEL_USERCOPY=y
+CONFIG_X86_TSC=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_IA32_FEAT_CTL=y
CONFIG_X86_VMX_FEATURE_NAMES=y
the various issues still exists:
fc2d5cbe541032e7 f388f60ca9041a95c9b3f157d31 801597ddaae3bdc15546df3d0eb
---------------- --------------------------- ---------------------------
fail:runs %reproduction fail:runs %reproduction fail:runs
| | | | |
:496 29% 145:494 31% 153:500 last_state.booting
:496 7% 35:494 14% 71:500 dmesg.BUG:kernel_hang_in_boot_stage
:496 0% :494 0% 1:500 dmesg.BUG:soft_lockup-CPU##stuck_for#s![kworker##:#]
:496 9% 45:494 5% 25:500 dmesg.BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
:496 0% 1:494 0% :500 dmesg.EIP:__timer_delete_sync
:496 1% 5:494 1% 3:500 dmesg.EIP:_raw_spin_unlock_irq
:496 0% 2:494 0% 1:500 dmesg.EIP:_raw_spin_unlock_irqrestore
:496 0% 1:494 0% :500 dmesg.EIP:console_emit_next_record
:496 0% :494 0% 1:500 dmesg.EIP:finish_task_switch
:496 0% 1:494 1% 4:500 dmesg.EIP:handle_softirqs
:496 1% 3:494 1% 4:500 dmesg.EIP:lock_acquire
:496 0% 2:494 0% 2:500 dmesg.EIP:lock_release
:496 0% :494 0% 1:500 dmesg.EIP:preempt_schedule_thunk
:496 0% 1:494 0% :500 dmesg.EIP:queue_delayed_work_on
:496 0% :494 0% 1:500 dmesg.EIP:rmqueue_pcplist
:496 9% 45:494 5% 25:500 dmesg.EIP:timekeeping_notify
:496 3% 14:494 2% 8:500 dmesg.INFO:rcu_preempt_detected_stalls_on_CPUs/tasks
:496 0% :494 0% 1:500 dmesg.INFO:rcu_preempt_self-detected_stall_on_CPU
:496 6% 32:494 9% 46:500 dmesg.INFO:task_blocked_for_more_than#seconds
:496 9% 45:494 5% 26:500 dmesg.Kernel_panic-not_syncing:softlockup:hung_tasks
if only enable X86_CMPXCHG64:
--- /pkg/linux/i386-randconfig-r071-20250410/gcc-12/f388f60ca9041a95c9b3f157d316ed7c8f297e44/.config 2025-04-15 15:41:17.009901645 +0800
+++ /pkg/linux/i386-randconfig-r071-20250410/gcc-12/dce28f73d4220df77c7fd6c41e854f1ef0af1d02/.config 2025-04-25 14:30:26.838037407 +0800
@@ -351,7 +351,8 @@ CONFIG_X86_F00F_BUG=y
CONFIG_X86_INVD_BUG=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_INTEL_USERCOPY=y
-CONFIG_X86_MINIMUM_CPU_FAMILY=4
+CONFIG_X86_CMPXCHG64=y
+CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_IA32_FEAT_CTL=y
CONFIG_X86_VMX_FEATURE_NAMES=y
CONFIG_CPU_SUP_INTEL=y
@@ -5745,6 +5746,7 @@ CONFIG_GENERIC_NET_UTILS=y
# CONFIG_PRIME_NUMBERS is not set
CONFIG_RATIONAL=y
CONFIG_GENERIC_IOMAP=y
+CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
CONFIG_ARCH_USE_SYM_ANNOTATIONS=y
various issues gone:
fc2d5cbe541032e7 f388f60ca9041a95c9b3f157d31 dce28f73d4220df77c7fd6c41e8
---------------- --------------------------- ---------------------------
fail:runs %reproduction fail:runs %reproduction fail:runs
| | | | |
:496 29% 145:494 0% :500 last_state.booting
:496 7% 35:494 0% :500 dmesg.BUG:kernel_hang_in_boot_stage
:496 9% 45:494 0% :500 dmesg.BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
:496 0% 1:494 0% :500 dmesg.EIP:__timer_delete_sync
:496 1% 5:494 0% :500 dmesg.EIP:_raw_spin_unlock_irq
:496 0% 2:494 0% :500 dmesg.EIP:_raw_spin_unlock_irqrestore
:496 0% 1:494 0% :500 dmesg.EIP:console_emit_next_record
:496 0% 1:494 0% :500 dmesg.EIP:handle_softirqs
:496 1% 3:494 0% :500 dmesg.EIP:lock_acquire
:496 0% 2:494 0% :500 dmesg.EIP:lock_release
:496 0% 1:494 0% :500 dmesg.EIP:queue_delayed_work_on
:496 9% 45:494 0% :500 dmesg.EIP:timekeeping_notify
:496 3% 14:494 0% :500 dmesg.INFO:rcu_preempt_detected_stalls_on_CPUs/tasks
:496 6% 32:494 0% :500 dmesg.INFO:task_blocked_for_more_than#seconds
:496 9% 45:494 0% :500 dmesg.Kernel_panic-not_syncing:softlockup:hung_tasks
> I tried reproducing the problem locally
> with your .config on a qemu/tcg emulation running on an
> arm64 host, but this seems to run fine, including the
> rcutorture tests.
>
> Comparing my results with your log file, I see that your
> crash happens while changing the clocksource:
>
> Your dmesg:
> [ 92.548514][ T1] hpet0: 3 comparators, 64-bit 100.000000 MHz counter
> [ 721.016745][ C0] watchdog: BUG: soft lockup - CPU#0 stuck for 626s! [swapper:1]
>
> My dmesg:
> [ 1.154511][ T1] hpet0: 3 comparators, 64-bit 100.000000 MHz counter
> [ 1.157896][ T1] clocksource: Switched to clocksource tsc-early
>
> There are also clearly some differences between TCG and KVM in
> the handling of TSC, e.g. I get this warning from qemu itself
> for the SandyBridge CPU:
>
> qemu-system-i386: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
>
> I tried a few other variations, including KVM on an x86 laptop
> (using kvmclock or tsc-early clocksource), but none of them failed
> the way yours did.
>
> Arnd
>
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
2025-04-27 5:48 ` Oliver Sang
@ 2025-04-27 12:07 ` Arnd Bergmann
2025-04-27 16:39 ` Linus Torvalds
1 sibling, 0 replies; 47+ messages in thread
From: Arnd Bergmann @ 2025-04-27 12:07 UTC (permalink / raw)
To: kernel test robot
Cc: oe-lkp, kernel test robot, linux-kernel, Ingo Molnar,
Linus Torvalds, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
On Sun, Apr 27, 2025, at 07:48, Oliver Sang wrote:
> On Thu, Apr 24, 2025 at 09:59:38AM +0200, Arnd Bergmann wrote:
>>
>> Thanks for confirming. So a 486-targeted kernel still passes
>> your tests on modern hardware if we force TSC and CX8 to
>> be enabled, but the boot fails if the options are turned
>> off in Kconfig (though available in emulated hardware).
>>
>> To be completely sure, you could re-run the same test with
>> just one of these enabled, but I'm rather sure that the TSC
>> is the root cause.
>
> just FYI. we rerun the tests. if only enable X86_TSC, the config diff is
...
> the various issues still exists:
>
> if only enable X86_CMPXCHG64:
...
> various issues gone:
Interesting, so cx8 was indeed a problem. I would still assume
that TSC caused the boot panic I cited, but it looks like CX8
caused all the other symptoms.
At the minimum this strengthens the case for the consensus of
dropping support for all pre-586 cores.
Thanks a lot for confirming!
Arnd
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
2025-04-27 5:48 ` Oliver Sang
2025-04-27 12:07 ` Arnd Bergmann
@ 2025-04-27 16:39 ` Linus Torvalds
2025-04-27 21:19 ` H. Peter Anvin
1 sibling, 1 reply; 47+ messages in thread
From: Linus Torvalds @ 2025-04-27 16:39 UTC (permalink / raw)
To: Oliver Sang
Cc: Arnd Bergmann, oe-lkp, kernel test robot, linux-kernel,
Ingo Molnar, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
On Sat, 26 Apr 2025 at 22:49, Oliver Sang <oliver.sang@intel.com> wrote:
>
> We reran the tests. if only enable X86_TSC, the various issues still
> exists. if only enable X86_CMPXCHG64, various issues gone.
Well, that's unexpected. I really didn't expect X86_CMPXCHG64 to make
any difference, since we should still use the cmpxchg64 instruction,
just with the alternative re-writing instead of directly.
Thanks for re-running the tests.
All the non-cmpxchg64 code sequences get replaced by the cmpxchg64
ones dynamically, so it all shouldn't matter one whit.
Except for during early boot. Because we do default to the old i386
sequences all the way *until* we do the alternatives replacement with
the good cmpxchg64 ones.
It does change code generation, in that we have to have that
alternative which now can be a call, so it's not a complete no-op, but
I'm still surprised.
And except for not using CMPXCHG_LOCKREF at all, but that should be
just a performance thing, and not noticeable during boot.
Hmm...
I'd love to understand why X86_CMPXCHG64 apparently matters, but I
can't convince myself that it's worth really pursuing.
Linus
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]
2025-04-27 16:39 ` Linus Torvalds
@ 2025-04-27 21:19 ` H. Peter Anvin
0 siblings, 0 replies; 47+ messages in thread
From: H. Peter Anvin @ 2025-04-27 21:19 UTC (permalink / raw)
To: Linus Torvalds, Oliver Sang
Cc: Arnd Bergmann, oe-lkp, kernel test robot, linux-kernel,
Ingo Molnar, John Stultz, Thomas Gleixner, Stephen Boyd,
Borislav Petkov, Dave Hansen, x86
On April 27, 2025 9:39:55 AM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Sat, 26 Apr 2025 at 22:49, Oliver Sang <oliver.sang@intel.com> wrote:
>>
>> We reran the tests. if only enable X86_TSC, the various issues still
>> exists. if only enable X86_CMPXCHG64, various issues gone.
>
>Well, that's unexpected. I really didn't expect X86_CMPXCHG64 to make
>any difference, since we should still use the cmpxchg64 instruction,
>just with the alternative re-writing instead of directly.
>
>Thanks for re-running the tests.
>
>All the non-cmpxchg64 code sequences get replaced by the cmpxchg64
>ones dynamically, so it all shouldn't matter one whit.
>
>Except for during early boot. Because we do default to the old i386
>sequences all the way *until* we do the alternatives replacement with
>the good cmpxchg64 ones.
>
>It does change code generation, in that we have to have that
>alternative which now can be a call, so it's not a complete no-op, but
>I'm still surprised.
>
>And except for not using CMPXCHG_LOCKREF at all, but that should be
>just a performance thing, and not noticeable during boot.
>
>Hmm...
>
>I'd love to understand why X86_CMPXCHG64 apparently matters, but I
>can't convince myself that it's worth really pursuing.
>
> Linus
Sounds like the fallback stubs are subtly broken.
Personally I would have thought cmpxchg64 to be the biggest win in raising the baseline to the i586 ISA.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
@ 2025-04-25 8:41 Ingo Molnar
2025-04-25 11:13 ` Arnd Bergmann
` (2 more replies)
0 siblings, 3 replies; 47+ messages in thread
From: Ingo Molnar @ 2025-04-25 8:41 UTC (permalink / raw)
To: linux-kernel
Cc: Ingo Molnar, Ahmed S . Darwish, Andrew Cooper, Ard Biesheuvel,
Arnd Bergmann, Borislav Petkov, Dave Hansen, H . Peter Anvin,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
In the x86 architecture we have various complicated hardware emulation
facilities on x86-32 to support ancient 32-bit CPUs that very very few
people are using with modern kernels. This compatibility glue is sometimes
even causing problems that people spend time to resolve, which time could
be spent on other things.
As Linus recently remarked:
> I really get the feeling that it's time to leave i486 support behind.
> There's zero real reason for anybody to waste one second of
> development effort on this kind of issue.
This series increases minimum kernel support features to include TSC and
CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
and early-586 (and derivatives) support.
Doing this allows the removal of a fair amount of code:
80 files changed, 38 insertions(+), 14104 deletions(-)
Much of which is the math-emu/ library - but even without math-emu,
the simplification is substantial:
33 files changed, 38 insertions(+), 1081 deletions(-)
This series has 5 main parts:
1) Removal of the main CPU options and their dependencies in the Kconfig space:
x86/cpu: Remove M486/M486SX/ELAN support
x86/cpu: Remove CONFIG_MWINCHIP3D/MWINCHIPC6
x86/cpu: Remove CPU_SUP_UMC_32 support
x86/cpu: Remove TSC-less CONFIG_M586 support
2) Remove platform support for chips that weren't carried forward
after these CPUs:
x86/cpu, x86/platform, watchdog: Remove CONFIG_X86_RDC321X support
x86/cpu: Remove the CONFIG_X86_INVD_BUG quirk
x86/cpu, cpufreq: Remove AMD ELAN support
3) Remove math-emu/ support:
x86/fpu: Remove MATH_EMULATION and related glue code
x86/fpu: Remove the 'no387' boot option
x86/fpu: Remove the math-emu/ FPU emulation library
4) Make CONFIG_X86_TSC unconditional and simplify the build-time TSC variances:
x86/cpu: Make CONFIG_X86_TSC unconditional
x86: Remove !CONFIG_X86_TSC code
Note that runtime TSC disabling is still kept in its various forms.
Also note that I kept CONFIG_X86_TSC itself, which is a proxy for
a few drivers for 'sane x86', and which might be used in changes
still in-flight. There's very little cost to keep this Kconfig option
going forward, even though it's always-enabled.
5) Make CONFIG_X86_CX8 unconditional and remove build-time complications:
x86/cpu: Make CONFIG_X86_CX8 unconditional
x86/percpu: Remove !CONFIG_X86_CX8 methods
x86/atomics: Remove !CONFIG_X86_CX8 methods
Note that CONFIG_X86_CX8 is still kept, but not used by anything
anymore. We can probably remove it entirely and there's no expectation
of pending/outside code having dependency on this.
Note that there's still some stray references to removed platforms in
the main x86 Kconfig and Kconfig.x86, and the entire vector of CPU
options is probably overly complicated and should probably be replaced
with a single option - I'll clean that all up once there's rough
agreement about the scope of this RFC series.
The tree can also be found in my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/tip.git WIP.x86/cpu
Lightly tested.
Thanks,
Ingo
================>
Ingo Molnar (15):
x86/cpu: Remove M486/M486SX/ELAN support
x86/cpu: Remove CONFIG_MWINCHIP3D/MWINCHIPC6
x86/cpu: Remove CPU_SUP_UMC_32 support
x86/cpu: Remove TSC-less CONFIG_M586 support
x86/cpu, x86/platform, watchdog: Remove CONFIG_X86_RDC321X support
x86/cpu: Remove the CONFIG_X86_INVD_BUG quirk
x86/cpu, cpufreq: Remove AMD ELAN support
x86/fpu: Remove MATH_EMULATION and related glue code
x86/fpu: Remove the 'no387' boot option
x86/fpu: Remove the math-emu/ FPU emulation library
x86/cpu: Make CONFIG_X86_TSC unconditional
x86: Remove !CONFIG_X86_TSC code
x86/cpu: Make CONFIG_X86_CX8 unconditional
x86/percpu: Remove !CONFIG_X86_CX8 methods
x86/atomics: Remove !CONFIG_X86_CX8 methods
Documentation/admin-guide/kernel-parameters.txt | 4 -
arch/x86/Kconfig | 71 +-
arch/x86/Kconfig.cpu | 95 +-
arch/x86/Kconfig.cpufeatures | 2 -
arch/x86/Makefile | 1 -
arch/x86/Makefile_32.cpu | 8 -
arch/x86/include/asm/asm-prototypes.h | 4 -
arch/x86/include/asm/atomic64_32.h | 17 +-
arch/x86/include/asm/cmpxchg_32.h | 86 +-
arch/x86/include/asm/fpu/api.h | 6 -
arch/x86/include/asm/percpu.h | 6 +-
arch/x86/include/asm/timex.h | 3 +-
arch/x86/include/asm/trace_clock.h | 8 -
arch/x86/include/asm/tsc.h | 13 +-
arch/x86/include/asm/vermagic.h | 12 -
arch/x86/kernel/Makefile | 4 +-
arch/x86/kernel/cpu/common.c | 7 -
arch/x86/kernel/cpu/umc.c | 26 -
arch/x86/kernel/fpu/core.c | 5 -
arch/x86/kernel/fpu/init.c | 9 +-
arch/x86/kernel/i8253.c | 2 +-
arch/x86/kernel/traps.c | 21 -
arch/x86/kernel/tsc.c | 13 -
arch/x86/lib/Makefile | 4 -
arch/x86/lib/atomic64_386_32.S | 195 ---
arch/x86/lib/cmpxchg8b_emu.S | 97 --
arch/x86/math-emu/Makefile | 30 -
arch/x86/math-emu/README | 427 ------
arch/x86/math-emu/control_w.h | 46 -
arch/x86/math-emu/div_Xsig.S | 367 -----
arch/x86/math-emu/div_small.S | 48 -
arch/x86/math-emu/errors.c | 686 ----------
arch/x86/math-emu/exception.h | 51 -
arch/x86/math-emu/fpu_arith.c | 153 ---
arch/x86/math-emu/fpu_asm.h | 32 -
arch/x86/math-emu/fpu_aux.c | 267 ----
arch/x86/math-emu/fpu_emu.h | 218 ---
arch/x86/math-emu/fpu_entry.c | 718 ----------
arch/x86/math-emu/fpu_etc.c | 136 --
arch/x86/math-emu/fpu_proto.h | 157 ---
arch/x86/math-emu/fpu_system.h | 130 --
arch/x86/math-emu/fpu_tags.c | 116 --
arch/x86/math-emu/fpu_trig.c | 1649 -----------------------
arch/x86/math-emu/get_address.c | 401 ------
arch/x86/math-emu/load_store.c | 322 -----
arch/x86/math-emu/mul_Xsig.S | 179 ---
arch/x86/math-emu/poly.h | 115 --
arch/x86/math-emu/poly_2xm1.c | 146 --
arch/x86/math-emu/poly_atan.c | 209 ---
arch/x86/math-emu/poly_l2.c | 245 ----
arch/x86/math-emu/poly_sin.c | 379 ------
arch/x86/math-emu/poly_tan.c | 213 ---
arch/x86/math-emu/polynom_Xsig.S | 137 --
arch/x86/math-emu/reg_add_sub.c | 334 -----
arch/x86/math-emu/reg_compare.c | 479 -------
arch/x86/math-emu/reg_constant.c | 123 --
arch/x86/math-emu/reg_constant.h | 26 -
arch/x86/math-emu/reg_convert.c | 47 -
arch/x86/math-emu/reg_divide.c | 183 ---
arch/x86/math-emu/reg_ld_str.c | 1220 -----------------
arch/x86/math-emu/reg_mul.c | 116 --
arch/x86/math-emu/reg_norm.S | 150 ---
arch/x86/math-emu/reg_round.S | 711 ----------
arch/x86/math-emu/reg_u_add.S | 169 ---
arch/x86/math-emu/reg_u_div.S | 474 -------
arch/x86/math-emu/reg_u_mul.S | 150 ---
arch/x86/math-emu/reg_u_sub.S | 274 ----
arch/x86/math-emu/round_Xsig.S | 142 --
arch/x86/math-emu/shr_Xsig.S | 89 --
arch/x86/math-emu/status_w.h | 68 -
arch/x86/math-emu/version.h | 12 -
arch/x86/math-emu/wm_shrx.S | 207 ---
arch/x86/math-emu/wm_sqrt.S | 472 -------
arch/x86/xen/Kconfig | 2 +-
drivers/cpufreq/Kconfig.x86 | 26 -
drivers/cpufreq/Makefile | 2 -
drivers/cpufreq/elanfreq.c | 227 ----
drivers/cpufreq/sc520_freq.c | 137 --
drivers/watchdog/Kconfig | 2 +-
lib/atomic64_test.c | 4 +-
80 files changed, 38 insertions(+), 14104 deletions(-)
delete mode 100644 arch/x86/kernel/cpu/umc.c
delete mode 100644 arch/x86/lib/atomic64_386_32.S
delete mode 100644 arch/x86/lib/cmpxchg8b_emu.S
delete mode 100644 arch/x86/math-emu/Makefile
delete mode 100644 arch/x86/math-emu/README
delete mode 100644 arch/x86/math-emu/control_w.h
delete mode 100644 arch/x86/math-emu/div_Xsig.S
delete mode 100644 arch/x86/math-emu/div_small.S
delete mode 100644 arch/x86/math-emu/errors.c
delete mode 100644 arch/x86/math-emu/exception.h
delete mode 100644 arch/x86/math-emu/fpu_arith.c
delete mode 100644 arch/x86/math-emu/fpu_asm.h
delete mode 100644 arch/x86/math-emu/fpu_aux.c
delete mode 100644 arch/x86/math-emu/fpu_emu.h
delete mode 100644 arch/x86/math-emu/fpu_entry.c
delete mode 100644 arch/x86/math-emu/fpu_etc.c
delete mode 100644 arch/x86/math-emu/fpu_proto.h
delete mode 100644 arch/x86/math-emu/fpu_system.h
delete mode 100644 arch/x86/math-emu/fpu_tags.c
delete mode 100644 arch/x86/math-emu/fpu_trig.c
delete mode 100644 arch/x86/math-emu/get_address.c
delete mode 100644 arch/x86/math-emu/load_store.c
delete mode 100644 arch/x86/math-emu/mul_Xsig.S
delete mode 100644 arch/x86/math-emu/poly.h
delete mode 100644 arch/x86/math-emu/poly_2xm1.c
delete mode 100644 arch/x86/math-emu/poly_atan.c
delete mode 100644 arch/x86/math-emu/poly_l2.c
delete mode 100644 arch/x86/math-emu/poly_sin.c
delete mode 100644 arch/x86/math-emu/poly_tan.c
delete mode 100644 arch/x86/math-emu/polynom_Xsig.S
delete mode 100644 arch/x86/math-emu/reg_add_sub.c
delete mode 100644 arch/x86/math-emu/reg_compare.c
delete mode 100644 arch/x86/math-emu/reg_constant.c
delete mode 100644 arch/x86/math-emu/reg_constant.h
delete mode 100644 arch/x86/math-emu/reg_convert.c
delete mode 100644 arch/x86/math-emu/reg_divide.c
delete mode 100644 arch/x86/math-emu/reg_ld_str.c
delete mode 100644 arch/x86/math-emu/reg_mul.c
delete mode 100644 arch/x86/math-emu/reg_norm.S
delete mode 100644 arch/x86/math-emu/reg_round.S
delete mode 100644 arch/x86/math-emu/reg_u_add.S
delete mode 100644 arch/x86/math-emu/reg_u_div.S
delete mode 100644 arch/x86/math-emu/reg_u_mul.S
delete mode 100644 arch/x86/math-emu/reg_u_sub.S
delete mode 100644 arch/x86/math-emu/round_Xsig.S
delete mode 100644 arch/x86/math-emu/shr_Xsig.S
delete mode 100644 arch/x86/math-emu/status_w.h
delete mode 100644 arch/x86/math-emu/version.h
delete mode 100644 arch/x86/math-emu/wm_shrx.S
delete mode 100644 arch/x86/math-emu/wm_sqrt.S
delete mode 100644 drivers/cpufreq/elanfreq.c
delete mode 100644 drivers/cpufreq/sc520_freq.c
--
2.45.2
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-04-25 8:41 [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs Ingo Molnar
@ 2025-04-25 11:13 ` Arnd Bergmann
2025-04-26 8:26 ` Pavel Machek
2025-05-05 8:53 ` Maciej W. Rozycki
2 siblings, 0 replies; 47+ messages in thread
From: Arnd Bergmann @ 2025-04-25 11:13 UTC (permalink / raw)
To: Ingo Molnar, linux-kernel
Cc: Ahmed S . Darwish, Andrew Cooper, Ard Biesheuvel, Borislav Petkov,
Dave Hansen, H. Peter Anvin, John Ogness, Linus Torvalds,
Peter Zijlstra, Thomas Gleixner
On Fri, Apr 25, 2025, at 10:41, Ingo Molnar wrote:
> In the x86 architecture we have various complicated hardware emulation
> facilities on x86-32 to support ancient 32-bit CPUs that very very few
> people are using with modern kernels. This compatibility glue is sometimes
> even causing problems that people spend time to resolve, which time could
> be spent on other things.
>
> As Linus recently remarked:
>
> > I really get the feeling that it's time to leave i486 support behind.
> > There's zero real reason for anybody to waste one second of
> > development effort on this kind of issue.
>
> This series increases minimum kernel support features to include TSC and
> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
> and early-586 (and derivatives) support.
Looks all good to me, thanks for including my earlier feedback.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-04-25 8:41 [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs Ingo Molnar
2025-04-25 11:13 ` Arnd Bergmann
@ 2025-04-26 8:26 ` Pavel Machek
2025-05-05 8:53 ` Maciej W. Rozycki
2 siblings, 0 replies; 47+ messages in thread
From: Pavel Machek @ 2025-04-26 8:26 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, Ahmed S . Darwish, Andrew Cooper, Ard Biesheuvel,
Arnd Bergmann, Borislav Petkov, Dave Hansen, H . Peter Anvin,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
Hi!
> In the x86 architecture we have various complicated hardware emulation
> facilities on x86-32 to support ancient 32-bit CPUs that very very few
> people are using with modern kernels. This compatibility glue is sometimes
> even causing problems that people spend time to resolve, which time could
> be spent on other things.
We have open-source 486 cores, such as
https://github.com/MiSTer-devel/ao486_MiSTer . I'm not aware of
open-source 586 cores... so this is a bit sad.
Best regards,
Pavel
--
I don't work for Nazis and criminals, and neither should you.
Boycott Putin, Trump, and Musk!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-04-25 8:41 [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs Ingo Molnar
2025-04-25 11:13 ` Arnd Bergmann
2025-04-26 8:26 ` Pavel Machek
@ 2025-05-05 8:53 ` Maciej W. Rozycki
2025-05-05 12:48 ` H. Peter Anvin
2025-05-05 15:59 ` Linus Torvalds
2 siblings, 2 replies; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-05 8:53 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, Ahmed S . Darwish, Andrew Cooper, Ard Biesheuvel,
Arnd Bergmann, Borislav Petkov, Dave Hansen, H . Peter Anvin,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Fri, 25 Apr 2025, Ingo Molnar wrote:
> > I really get the feeling that it's time to leave i486 support behind.
> > There's zero real reason for anybody to waste one second of
> > development effort on this kind of issue.
>
> This series increases minimum kernel support features to include TSC and
> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
> and early-586 (and derivatives) support.
FWIW I'm not happy about that at the very least because this will prevent
me from using my 486 box for EISA defxx driver maintenance. What exactly
is the problem with 486?
I know the lack of TSC has security implications, but don't use the
machine in a way for which it would be an issue and I don't expect anyone
doing otherwise. We have non-x86 platforms that lack a high-resolution
timer and nobody's going to drop them.
We also have platforms that lack atomics, let alone double-precision ones
and they're fine too, so why is x86 different?
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-05 8:53 ` Maciej W. Rozycki
@ 2025-05-05 12:48 ` H. Peter Anvin
2025-05-05 13:04 ` Maciej W. Rozycki
2025-05-05 15:59 ` Linus Torvalds
1 sibling, 1 reply; 47+ messages in thread
From: H. Peter Anvin @ 2025-05-05 12:48 UTC (permalink / raw)
To: Maciej W. Rozycki, Ingo Molnar
Cc: linux-kernel, Ahmed S . Darwish, Andrew Cooper, Ard Biesheuvel,
Arnd Bergmann, Borislav Petkov, Dave Hansen, John Ogness,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On May 5, 2025 1:53:04 AM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Fri, 25 Apr 2025, Ingo Molnar wrote:
>
>> > I really get the feeling that it's time to leave i486 support behind.
>> > There's zero real reason for anybody to waste one second of
>> > development effort on this kind of issue.
>>
>> This series increases minimum kernel support features to include TSC and
>> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
>> and early-586 (and derivatives) support.
>
> FWIW I'm not happy about that at the very least because this will prevent
>me from using my 486 box for EISA defxx driver maintenance. What exactly
>is the problem with 486?
>
> I know the lack of TSC has security implications, but don't use the
>machine in a way for which it would be an issue and I don't expect anyone
>doing otherwise. We have non-x86 platforms that lack a high-resolution
>timer and nobody's going to drop them.
>
> We also have platforms that lack atomics, let alone double-precision ones
>and they're fine too, so why is x86 different?
>
> Maciej
Why is x86 different? Because it is a tightly integrated platform with code shared across a very large number of generations, without "silly embedded nonsense hacks."
I think if you have a use case, you need to speak up about it, rather than for people to guess.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-05 12:48 ` H. Peter Anvin
@ 2025-05-05 13:04 ` Maciej W. Rozycki
2025-05-05 19:57 ` H. Peter Anvin
0 siblings, 1 reply; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-05 13:04 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, linux-kernel, Ahmed S . Darwish, Andrew Cooper,
Ard Biesheuvel, Arnd Bergmann, Borislav Petkov, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Mon, 5 May 2025, H. Peter Anvin wrote:
> >> > I really get the feeling that it's time to leave i486 support behind.
> >> > There's zero real reason for anybody to waste one second of
> >> > development effort on this kind of issue.
> >>
> >> This series increases minimum kernel support features to include TSC and
> >> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
> >> and early-586 (and derivatives) support.
> >
> > FWIW I'm not happy about that at the very least because this will prevent
> >me from using my 486 box for EISA defxx driver maintenance. What exactly
> >is the problem with 486?
> >
> > I know the lack of TSC has security implications, but don't use the
> >machine in a way for which it would be an issue and I don't expect anyone
> >doing otherwise. We have non-x86 platforms that lack a high-resolution
> >timer and nobody's going to drop them.
> >
> > We also have platforms that lack atomics, let alone double-precision ones
> >and they're fine too, so why is x86 different?
>
> Why is x86 different? Because it is a tightly integrated platform with
> code shared across a very large number of generations, without "silly
> embedded nonsense hacks."
Thank you for the clarification. By "silly embedded nonsense hacks" I
suppose you refer to missing instruction emulation, which some platforms
do so as to contain legacy support in a single place and let the rest of
the code base assume the required feature is there, relieving maintainers
from extra burden, correct?
> I think if you have a use case, you need to speak up about it, rather
> than for people to guess.
Which I just did; I think that's exactly what an RFC is about, isn't it?
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-05 13:04 ` Maciej W. Rozycki
@ 2025-05-05 19:57 ` H. Peter Anvin
2025-05-05 20:54 ` Borislav Petkov
2025-05-06 13:48 ` Maciej W. Rozycki
0 siblings, 2 replies; 47+ messages in thread
From: H. Peter Anvin @ 2025-05-05 19:57 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Ingo Molnar, linux-kernel, Ahmed S . Darwish, Andrew Cooper,
Ard Biesheuvel, Arnd Bergmann, Borislav Petkov, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On May 5, 2025 6:04:12 AM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Mon, 5 May 2025, H. Peter Anvin wrote:
>
>> >> > I really get the feeling that it's time to leave i486 support behind.
>> >> > There's zero real reason for anybody to waste one second of
>> >> > development effort on this kind of issue.
>> >>
>> >> This series increases minimum kernel support features to include TSC and
>> >> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
>> >> and early-586 (and derivatives) support.
>> >
>> > FWIW I'm not happy about that at the very least because this will prevent
>> >me from using my 486 box for EISA defxx driver maintenance. What exactly
>> >is the problem with 486?
>> >
>> > I know the lack of TSC has security implications, but don't use the
>> >machine in a way for which it would be an issue and I don't expect anyone
>> >doing otherwise. We have non-x86 platforms that lack a high-resolution
>> >timer and nobody's going to drop them.
>> >
>> > We also have platforms that lack atomics, let alone double-precision ones
>> >and they're fine too, so why is x86 different?
>>
>> Why is x86 different? Because it is a tightly integrated platform with
>> code shared across a very large number of generations, without "silly
>> embedded nonsense hacks."
>
> Thank you for the clarification. By "silly embedded nonsense hacks" I
>suppose you refer to missing instruction emulation, which some platforms
>do so as to contain legacy support in a single place and let the rest of
>the code base assume the required feature is there, relieving maintainers
>from extra burden, correct?
>
>> I think if you have a use case, you need to speak up about it, rather
>> than for people to guess.
>
> Which I just did; I think that's exactly what an RFC is about, isn't it?
>
> Maciej
No, with "silly embedded nonsense hacks" (Google for it) I mean ad hoc hacks breaking the notion of a common platform.
As far as EISA is concerned, could you go into more detail? What are the remaining users of EISA? One thing that happened with i386 was that we found out that the only remaining "users" were people dragging out an old machine to test if the kernel still booted. With bigsmp we had similar experiences – in at least one case we ended up maintaining support for a system of which there were no machines left in existence...
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-05 19:57 ` H. Peter Anvin
@ 2025-05-05 20:54 ` Borislav Petkov
2025-05-06 13:51 ` Maciej W. Rozycki
2025-05-06 13:48 ` Maciej W. Rozycki
1 sibling, 1 reply; 47+ messages in thread
From: Borislav Petkov @ 2025-05-05 20:54 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Maciej W. Rozycki, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Mon, May 05, 2025 at 12:57:40PM -0700, H. Peter Anvin wrote:
> One thing that happened with i386 was that we found out that the only
> remaining "users" were people dragging out an old machine to test if the
> kernel still booted.
Follow this thread:
https://lore.kernel.org/r/CANpbe9Wm3z8fy9HbgS8cuhoj0TREYEEkBipDuhgkWFvqX0UoVQ@mail.gmail.com
People booting latest kernel on 486 without CPUID support.
I can't find it in me to care for that old rust and yet I did it again. :-\
So yeah, +1 for removing old code which ain't worth maintaining.
There's stable and older kernels, those folks can use those and that's it.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-05 20:54 ` Borislav Petkov
@ 2025-05-06 13:51 ` Maciej W. Rozycki
2025-05-06 14:16 ` Borislav Petkov
0 siblings, 1 reply; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-06 13:51 UTC (permalink / raw)
To: Borislav Petkov
Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Mon, 5 May 2025, Borislav Petkov wrote:
> > One thing that happened with i386 was that we found out that the only
> > remaining "users" were people dragging out an old machine to test if the
> > kernel still booted.
>
> Follow this thread:
>
> https://lore.kernel.org/r/CANpbe9Wm3z8fy9HbgS8cuhoj0TREYEEkBipDuhgkWFvqX0UoVQ@mail.gmail.com
>
> People booting latest kernel on 486 without CPUID support.
No such hardware here:
processor : 0
vendor_id : GenuineIntel
cpu family : 4
model : 3
model name : 486 DX/2
stepping : 5
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme cpuid
bugs : itlb_multihit
bogomips : 32.56
clflush size : 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:
Sadly it's not one with 4MiB page support (that would be stepping 6).
> There's stable and older kernels, those folks can use those and that's it.
Doesn't work for ongoing driver maintenance (and yes, distractions such
as this only keep me from taking care of outstanding stuff, like figuring
out why the defxx driver reproducibly crashes with my POWER9 box running
glibc verification remotely for my RISC-V box; it's all intertwined and an
issue in one place affects other ones, sigh).
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-06 13:51 ` Maciej W. Rozycki
@ 2025-05-06 14:16 ` Borislav Petkov
2025-05-08 14:51 ` Maciej W. Rozycki
0 siblings, 1 reply; 47+ messages in thread
From: Borislav Petkov @ 2025-05-06 14:16 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Tue, May 06, 2025 at 02:51:51PM +0100, Maciej W. Rozycki wrote:
> Doesn't work for ongoing driver maintenance
Dunno, I'd concentrate my efforts on something, a *little* *bit* more modern.
At some point this is old rusty hw no matter from which way you look at it and
it might as well be left to rest in its sunset days.
But I certainly am not trying to tell you what to do with your time.
What I have problem with is wasting my time maintaining old, ancient hw which
is not worth the electricity it needs to run. Especially if you can get
something orders of magnitudes better in *any* aspect you can think of, and
actually get some real work done.
:-P
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-06 14:16 ` Borislav Petkov
@ 2025-05-08 14:51 ` Maciej W. Rozycki
2025-05-08 20:11 ` Borislav Petkov
0 siblings, 1 reply; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-08 14:51 UTC (permalink / raw)
To: Borislav Petkov
Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Tue, 6 May 2025, Borislav Petkov wrote:
> > Doesn't work for ongoing driver maintenance
>
> Dunno, I'd concentrate my efforts on something, a *little* *bit* more modern.
> At some point this is old rusty hw no matter from which way you look at it and
> it might as well be left to rest in its sunset days.
One doesn't exclude the other. I do POWER9 or RISC-V stuff too. Isn't
it modern enough?
> What I have problem with is wasting my time maintaining old, ancient hw which
> is not worth the electricity it needs to run. Especially if you can get
> something orders of magnitudes better in *any* aspect you can think of, and
> actually get some real work done.
I don't want you let alone expect to waste time on anything you're not
interested in. I'm trying to find a solution that saves you from that
while preferably keeping everyone happy enough, including myself.
Real work? I find engineering challenges enjoyable regardless of the age
of hardware involved and I don't want to take away anyone's daily bread
(including mine) by spending my free time on a project someone might have
commercial interest in and should pay for. An obsolete platform is ideal
for this purpose.
And what's better and what's not is subjective. I don't find all the new
stuff better, just as I don't all the old stuff. At least the old gear
tends to be sturdy (once you've contained issues with the PSU) and likely
won't suffer from electromigration in a few years' time. It can be easier
to repair too if a component does fail.
NB people also fancy old cars, or boats, or trains even, not because
they're faster, more comfortable, or have any real advantage over modern
alternatives.
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-08 14:51 ` Maciej W. Rozycki
@ 2025-05-08 20:11 ` Borislav Petkov
2025-05-12 12:55 ` Maciej W. Rozycki
0 siblings, 1 reply; 47+ messages in thread
From: Borislav Petkov @ 2025-05-08 20:11 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On May 8, 2025 4:51:27 PM GMT+02:00, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Tue, 6 May 2025, Borislav Petkov wrote:
>
>> > Doesn't work for ongoing driver maintenance
>>
>> Dunno, I'd concentrate my efforts on something, a *little* *bit* more modern.
>> At some point this is old rusty hw no matter from which way you look at it and
>> it might as well be left to rest in its sunset days.
>
> One doesn't exclude the other. I do POWER9 or RISC-V stuff too. Isn't
>it modern enough?
>
>> What I have problem with is wasting my time maintaining old, ancient hw which
>> is not worth the electricity it needs to run. Especially if you can get
>> something orders of magnitudes better in *any* aspect you can think of, and
>> actually get some real work done.
>
> I don't want you let alone expect to waste time on anything you're not
>interested in. I'm trying to find a solution that saves you from that
>while preferably keeping everyone happy enough, including myself.
>
> Real work? I find engineering challenges enjoyable regardless of the age
>of hardware involved and I don't want to take away anyone's daily bread
>(including mine) by spending my free time on a project someone might have
>commercial interest in and should pay for. An obsolete platform is ideal
>for this purpose.
>
> And what's better and what's not is subjective. I don't find all the new
>stuff better, just as I don't all the old stuff. At least the old gear
>tends to be sturdy (once you've contained issues with the PSU) and likely
>won't suffer from electromigration in a few years' time. It can be easier
>to repair too if a component does fail.
>
> NB people also fancy old cars, or boats, or trains even, not because
>they're faster, more comfortable, or have any real advantage over modern
>alternatives.
This fits very well, IMO, with Linus' suggestion to support this stuff out of tree. I think this solution is the optimal one for all parties involved...
--
Sent from a small device: formatting sucks and brevity is inevitable.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-08 20:11 ` Borislav Petkov
@ 2025-05-12 12:55 ` Maciej W. Rozycki
2025-05-12 13:48 ` Borislav Petkov
0 siblings, 1 reply; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-12 12:55 UTC (permalink / raw)
To: Borislav Petkov
Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Thu, 8 May 2025, Borislav Petkov wrote:
> > NB people also fancy old cars, or boats, or trains even, not because
> >they're faster, more comfortable, or have any real advantage over modern
> >alternatives.
>
>
> This fits very well, IMO, with Linus' suggestion to support this stuff
> out of tree. I think this solution is the optimal one for all parties
> involved...
Would kernel.org git infrastructure be available for such a project?
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-12 12:55 ` Maciej W. Rozycki
@ 2025-05-12 13:48 ` Borislav Petkov
2025-05-12 17:29 ` Maciej W. Rozycki
0 siblings, 1 reply; 47+ messages in thread
From: Borislav Petkov @ 2025-05-12 13:48 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Mon, May 12, 2025 at 01:55:35PM +0100, Maciej W. Rozycki wrote:
> On Thu, 8 May 2025, Borislav Petkov wrote:
>
> > > NB people also fancy old cars, or boats, or trains even, not because
> > >they're faster, more comfortable, or have any real advantage over modern
> > >alternatives.
> >
> >
> > This fits very well, IMO, with Linus' suggestion to support this stuff
> > out of tree. I think this solution is the optimal one for all parties
> > involved...
>
> Would kernel.org git infrastructure be available for such a project?
as in hosting your repo there?
I don't see why not:
https://korg.docs.kernel.org/accounts.html
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-12 13:48 ` Borislav Petkov
@ 2025-05-12 17:29 ` Maciej W. Rozycki
2025-05-13 2:00 ` Linus Torvalds
0 siblings, 1 reply; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-12 17:29 UTC (permalink / raw)
To: Borislav Petkov
Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Mon, 12 May 2025, Borislav Petkov wrote:
> > Would kernel.org git infrastructure be available for such a project?
>
> as in hosting your repo there?
>
> I don't see why not:
>
> https://korg.docs.kernel.org/accounts.html
Thank you. It seems it'll be tough for me though to fulfil the GPG key
trustability requirement. While I've used PGP/GPG since 1995, I haven't
been active collecting signatures with my more recent keys/IDs and neither
I have appeared in public among Linux kernel developers often enough for
me to be identified by face over a video call. Oh well...
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-12 17:29 ` Maciej W. Rozycki
@ 2025-05-13 2:00 ` Linus Torvalds
2025-05-13 3:48 ` H. Peter Anvin
2025-05-13 5:43 ` John Paul Adrian Glaubitz
0 siblings, 2 replies; 47+ messages in thread
From: Linus Torvalds @ 2025-05-13 2:00 UTC (permalink / raw)
To: Maciej W. Rozycki, Konstantin Ryabitsev
Cc: Borislav Petkov, H. Peter Anvin, Ingo Molnar, linux-kernel,
Ahmed S . Darwish, Andrew Cooper, Ard Biesheuvel, Arnd Bergmann,
Dave Hansen, John Ogness, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Mon, May 12, 2025 at 10:29 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> Thank you. It seems it'll be tough for me though to fulfil the GPG key
> trustability requirement. While I've used PGP/GPG since 1995, I haven't
> been active collecting signatures with my more recent keys/IDs and neither
> I have appeared in public among Linux kernel developers often enough for
> me to be identified by face over a video call. Oh well...
I don't think this has been insurmountable before, particularly for
anybody who has been around for as long as you have. Even your
current email goes back to at least the beginnings of git.
If "two decades+ of active kernel development involvement using the
same email address" doesn't make you eligible for a kernel.org
account, we're doing something wrong.
Linus
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-13 2:00 ` Linus Torvalds
@ 2025-05-13 3:48 ` H. Peter Anvin
2025-05-13 5:43 ` John Paul Adrian Glaubitz
1 sibling, 0 replies; 47+ messages in thread
From: H. Peter Anvin @ 2025-05-13 3:48 UTC (permalink / raw)
To: Linus Torvalds, Maciej W. Rozycki, Konstantin Ryabitsev
Cc: Borislav Petkov, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On May 12, 2025 7:00:55 PM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Mon, May 12, 2025 at 10:29 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>>
>> Thank you. It seems it'll be tough for me though to fulfil the GPG key
>> trustability requirement. While I've used PGP/GPG since 1995, I haven't
>> been active collecting signatures with my more recent keys/IDs and neither
>> I have appeared in public among Linux kernel developers often enough for
>> me to be identified by face over a video call. Oh well...
>
>I don't think this has been insurmountable before, particularly for
>anybody who has been around for as long as you have. Even your
>current email goes back to at least the beginnings of git.
>
>If "two decades+ of active kernel development involvement using the
>same email address" doesn't make you eligible for a kernel.org
>account, we're doing something wrong.
>
> Linus
>
Yeah, we have dealt with this before :)
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-13 2:00 ` Linus Torvalds
2025-05-13 3:48 ` H. Peter Anvin
@ 2025-05-13 5:43 ` John Paul Adrian Glaubitz
2025-05-13 21:55 ` Maciej W. Rozycki
1 sibling, 1 reply; 47+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-05-13 5:43 UTC (permalink / raw)
To: Linus Torvalds, Maciej W. Rozycki, Konstantin Ryabitsev
Cc: Borislav Petkov, H. Peter Anvin, Ingo Molnar, linux-kernel,
Ahmed S . Darwish, Andrew Cooper, Ard Biesheuvel, Arnd Bergmann,
Dave Hansen, John Ogness, Peter Zijlstra, Thomas Gleixner
Hi,
On Mon, 2025-05-12 at 19:00 -0700, Linus Torvalds wrote:
> On Mon, May 12, 2025 at 10:29 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> >
> > Thank you. It seems it'll be tough for me though to fulfil the GPG key
> > trustability requirement. While I've used PGP/GPG since 1995, I haven't
> > been active collecting signatures with my more recent keys/IDs and neither
> > I have appeared in public among Linux kernel developers often enough for
> > me to be identified by face over a video call. Oh well...
>
> I don't think this has been insurmountable before, particularly for
> anybody who has been around for as long as you have. Even your
> current email goes back to at least the beginnings of git.
>
> If "two decades+ of active kernel development involvement using the
> same email address" doesn't make you eligible for a kernel.org
> account, we're doing something wrong.
I agree. Maciej does a fantastic job saving old junk^W^Wretro hardware ;-).
I'm sure there should be anyone in Maciej's area that could sign his keys.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-13 5:43 ` John Paul Adrian Glaubitz
@ 2025-05-13 21:55 ` Maciej W. Rozycki
2025-05-13 22:02 ` Linus Torvalds
0 siblings, 1 reply; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-13 21:55 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Linus Torvalds, Konstantin Ryabitsev, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Peter Zijlstra, Thomas Gleixner
On Tue, 13 May 2025, John Paul Adrian Glaubitz wrote:
> > > Thank you. It seems it'll be tough for me though to fulfil the GPG key
> > > trustability requirement. While I've used PGP/GPG since 1995, I haven't
> > > been active collecting signatures with my more recent keys/IDs and neither
> > > I have appeared in public among Linux kernel developers often enough for
> > > me to be identified by face over a video call. Oh well...
> >
> > I don't think this has been insurmountable before, particularly for
> > anybody who has been around for as long as you have. Even your
> > current email goes back to at least the beginnings of git.
Hmm, a .mailmap artifact perhaps; I actually only switched to my current
e-mail address back in 2021 once linux-mips.org has lost all the remaining
credibility in my eyes. There's exactly one "Patch-dusted-off-by:" commit
using my yet earlier personal address, plus a bunch using my various old
work addresses too.
All the earlier work has been buried either in the linux-mips.org git
repo, going back via conversion from CVS to:
commit 1513ff9b7899ab588401c89db0e99903dbf5f886
Author: Ralf Baechle <ralf@linux-mips.org>
Date: Mon Nov 28 11:59:19 1994 +0000
Import of Linus's Linux 1.1.68
(which I still do hope to fully recover and for which kernel.org seems to
be the right ultimate haven), or in LKML and other mailing list archives.
None of this however proves any GPG key offered is actually mine.
> > If "two decades+ of active kernel development involvement using the
> > same email address" doesn't make you eligible for a kernel.org
> > account, we're doing something wrong.
>
> I agree. Maciej does a fantastic job saving old junk^W^Wretro hardware ;-).
Thank you. That makes two of us; the rest has switched to NetBSD.
> I'm sure there should be anyone in Maciej's area that could sign his keys.
Undoubtedly, but finding someone local who has a kernel.org account and
can actually tell I am who I claim I am will be rather tough, and trusting
a government-issued ID alone may be questionable nowadays, as correctly
observed in <https://korg.docs.kernel.org/accounts.html#pgp-web-of-trust>.
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-13 21:55 ` Maciej W. Rozycki
@ 2025-05-13 22:02 ` Linus Torvalds
2025-05-13 22:06 ` H. Peter Anvin
2025-05-15 16:32 ` Maciej W. Rozycki
0 siblings, 2 replies; 47+ messages in thread
From: Linus Torvalds @ 2025-05-13 22:02 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: John Paul Adrian Glaubitz, Konstantin Ryabitsev, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Peter Zijlstra, Thomas Gleixner
On Tue, 13 May 2025 at 14:55, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> Hmm, a .mailmap artifact perhaps
Ahh, indeed. I was looking at commit feea1db26e5b ("[PATCH] defxx: Use
irqreturn_t for the interrupt handler") from 2005, but yes, the raw
commit information has your linux-mips address, and it's just that
"git log" will translate it to something much newer...
But I really don't think we've ever been *so* strict about pgp keys
having all the proper pgp key signature chains. Yes, it's the normal
rule and the regular way people identify themselves, but nothing
should ever be mindlessly black-and-white.
Linus
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-13 22:02 ` Linus Torvalds
@ 2025-05-13 22:06 ` H. Peter Anvin
2025-05-15 16:32 ` Maciej W. Rozycki
1 sibling, 0 replies; 47+ messages in thread
From: H. Peter Anvin @ 2025-05-13 22:06 UTC (permalink / raw)
To: Linus Torvalds, Maciej W. Rozycki
Cc: John Paul Adrian Glaubitz, Konstantin Ryabitsev, Borislav Petkov,
Ingo Molnar, linux-kernel, Ahmed S . Darwish, Andrew Cooper,
Ard Biesheuvel, Arnd Bergmann, Dave Hansen, John Ogness,
Peter Zijlstra, Thomas Gleixner
On 5/13/25 15:02, Linus Torvalds wrote:
> On Tue, 13 May 2025 at 14:55, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>>
>> Hmm, a .mailmap artifact perhaps
>
> Ahh, indeed. I was looking at commit feea1db26e5b ("[PATCH] defxx: Use
> irqreturn_t for the interrupt handler") from 2005, but yes, the raw
> commit information has your linux-mips address, and it's just that
> "git log" will translate it to something much newer...
>
> But I really don't think we've ever been *so* strict about pgp keys
> having all the proper pgp key signature chains. Yes, it's the normal
> rule and the regular way people identify themselves, but nothing
> should ever be mindlessly black-and-white.
Having the discussion with Maciej offlist.
The issue here is obviously not that Maciej is qualified to have a
kernel.org account (I consider that to be a given), but that we need to
avoid a "Jia Tan" incident.
-hpa
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-13 22:02 ` Linus Torvalds
2025-05-13 22:06 ` H. Peter Anvin
@ 2025-05-15 16:32 ` Maciej W. Rozycki
1 sibling, 0 replies; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-15 16:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: John Paul Adrian Glaubitz, Konstantin Ryabitsev, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Dave Hansen,
John Ogness, Peter Zijlstra, Thomas Gleixner
On Tue, 13 May 2025, Linus Torvalds wrote:
> But I really don't think we've ever been *so* strict about pgp keys
> having all the proper pgp key signature chains. Yes, it's the normal
> rule and the regular way people identify themselves, but nothing
> should ever be mindlessly black-and-white.
I agree about being reasonable. However times are such that we need to
be extremely vigilant. I wish we were back in the 1990s when the worst
threat online seemed to be unsolicited offers received via e-mail for
various enlargement treatments; sadly not for the brain.
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-05 19:57 ` H. Peter Anvin
2025-05-05 20:54 ` Borislav Petkov
@ 2025-05-06 13:48 ` Maciej W. Rozycki
2025-05-06 13:54 ` John Paul Adrian Glaubitz
1 sibling, 1 reply; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-06 13:48 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, linux-kernel, Ahmed S . Darwish, Andrew Cooper,
Ard Biesheuvel, Arnd Bergmann, Borislav Petkov, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Mon, 5 May 2025, H. Peter Anvin wrote:
> >> I think if you have a use case, you need to speak up about it, rather
> >> than for people to guess.
> >
> > Which I just did; I think that's exactly what an RFC is about, isn't it?
>
> No, with "silly embedded nonsense hacks" (Google for it) I mean ad hoc
> hacks breaking the notion of a common platform.
I don't feel like I'm the right person to talk about such stuff. I've
always cared about portability and standardisation.
In fact running old hardware is one aspect of portability verification,
for example I run PCIe stuff off my Pentium MMX and Alpha hardware, and
conversely I run conventional PCI stuff off my POWER9 (no port I/O!) and
RISC-V hardware. That has triggered numerous bugs, fixed over the years.
> As far as EISA is concerned, could you go into more detail? What are the
> remaining users of EISA? One thing that happened with i386 was that we
> found out that the only remaining "users" were people dragging out an
> old machine to test if the kernel still booted. With bigsmp we had
> similar experiences – in at least one case we ended up maintaining
> support for a system of which there were no machines left in
> existence...
Well, my i486 box is plain EISA, so naturally I need EISA support to run
it:
platform eisa.0: Probing EISA bus 0
eisa 00:00: EISA: Mainboard AEI0401 detected
eisa 00:05: EISA: slot 5: DEC3002 detected
defxx: v1.12 2021/03/10 Lawrence V. Stefani and others
00:05: DEFEA at I/O addr = 0x5000, IRQ = 10, Hardware addr = 00-00-f8-xx-yy-zz
00:05: registered as fddi0
eisa 00:06: EISA: slot 6: NPI0303 detected
eisa 00:08: EISA: slot 8: TCM5094 detected
eth0: 3c5x9 found at 0x8000, 10baseT port, address 00:a0:24:xx:yy:zz, IRQ 12.
platform eisa.0: EISA: Detected 3 cards
(fddi0 is the fast intranet interface, eth0 is the slow external one).
It's a luggable integrated computer BTW, a Dolch PAC 60, very nice and
compact, previously used by a field engineer for network fault isolation.
I've already mentioned the maintenance of the defxx driver (it is also an
exercise in portability, with defxx supporting 3 host bus attachments).
This is also my backup box for GNU toolchain (GCC/glibc/GDB) verification
for the i386 target. It has actually proved recently to still have some
commercial relevance (again, for portability verification), but who says
the use of Linux is supposed to be solely commercial even nowadays?
The origin of Linux is obvious and I wouldn't be around at all let alone
for so many years if not for my enthusiasm solely for the technical merit
of Linux (following my earlier passion for processors and systems)
accompanied by the fairness of the GNU GPL, with any commercial aspect
being at most distantly relevant and a late comer into the game.
So yes, count me in as a passionate systems software engineer with a
fondness for running odd configurations for the sake of experimentation
(and consequently a portability exercise) and please do not deprive me of
my enthusiasm.
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-06 13:48 ` Maciej W. Rozycki
@ 2025-05-06 13:54 ` John Paul Adrian Glaubitz
0 siblings, 0 replies; 47+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-05-06 13:54 UTC (permalink / raw)
To: Maciej W. Rozycki, H. Peter Anvin
Cc: Ingo Molnar, linux-kernel, Ahmed S . Darwish, Andrew Cooper,
Ard Biesheuvel, Arnd Bergmann, Borislav Petkov, Dave Hansen,
John Ogness, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
On Tue, 2025-05-06 at 14:48 +0100, Maciej W. Rozycki wrote:
> In fact running old hardware is one aspect of portability verification,
> for example I run PCIe stuff off my Pentium MMX and Alpha hardware, and
> conversely I run conventional PCI stuff off my POWER9 (no port I/O!) and
> RISC-V hardware. That has triggered numerous bugs, fixed over the years.
I agree with that stance. Building and running Debian on various architectures
has enabled use to find obscure bugs that did not trigger easily on x86_64
or arm64.
I remember one nasty bug in the DMA code that initially showed on ia64 only
and it was only when someone finally ran into the same problem on x86_64 that
it was actually fixed.
>
> (fddi0 is the fast intranet interface, eth0 is the slow external one).
> It's a luggable integrated computer BTW, a Dolch PAC 60, very nice and
> compact, previously used by a field engineer for network fault isolation.
>
> I've already mentioned the maintenance of the defxx driver (it is also an
> exercise in portability, with defxx supporting 3 host bus attachments).
>
> This is also my backup box for GNU toolchain (GCC/glibc/GDB) verification
> for the i386 target. It has actually proved recently to still have some
> commercial relevance (again, for portability verification), but who says
> the use of Linux is supposed to be solely commercial even nowadays?
I fully agree with this. Cross-architecture testing really helps finding hidden
bugs and it's also fun ;-).
> The origin of Linux is obvious and I wouldn't be around at all let alone
> for so many years if not for my enthusiasm solely for the technical merit
> of Linux (following my earlier passion for processors and systems)
> accompanied by the fairness of the GNU GPL, with any commercial aspect
> being at most distantly relevant and a late comer into the game.
>
> So yes, count me in as a passionate systems software engineer with a
> fondness for running odd configurations for the sake of experimentation
> (and consequently a portability exercise) and please do not deprive me of
> my enthusiasm.
Count me in as well.
PS: No, we don't have to bring back ia64 for that matter ;-).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-05 8:53 ` Maciej W. Rozycki
2025-05-05 12:48 ` H. Peter Anvin
@ 2025-05-05 15:59 ` Linus Torvalds
2025-05-06 13:53 ` Maciej W. Rozycki
1 sibling, 1 reply; 47+ messages in thread
From: Linus Torvalds @ 2025-05-05 15:59 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Ingo Molnar, linux-kernel, Ahmed S . Darwish, Andrew Cooper,
Ard Biesheuvel, Arnd Bergmann, Borislav Petkov, Dave Hansen,
H . Peter Anvin, John Ogness, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Mon, 5 May 2025 at 01:53, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> We also have platforms that lack atomics, let alone double-precision ones
> and they're fine too, so why is x86 different?
So I don't know if you saw this thread:
https://lore.kernel.org/all/202504211553.3ba9400-lkp@intel.com/
where I initially thought that it was the lack of TSC, but it looks
like it's the CMPXCHG8B code that ends up causing problems.
And the core issue boils down to "there's no point in wasting time on
even debugging this".
So basically, the support for i486 costs us more than it is worth.
Linus
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-05 15:59 ` Linus Torvalds
@ 2025-05-06 13:53 ` Maciej W. Rozycki
2025-05-06 16:44 ` H. Peter Anvin
0 siblings, 1 reply; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-06 13:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, linux-kernel, Ahmed S . Darwish, Andrew Cooper,
Ard Biesheuvel, Arnd Bergmann, Borislav Petkov, Dave Hansen,
H . Peter Anvin, John Ogness, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Mon, 5 May 2025, Linus Torvalds wrote:
> > We also have platforms that lack atomics, let alone double-precision ones
> > and they're fine too, so why is x86 different?
>
> So I don't know if you saw this thread:
>
> https://lore.kernel.org/all/202504211553.3ba9400-lkp@intel.com/
>
> where I initially thought that it was the lack of TSC, but it looks
> like it's the CMPXCHG8B code that ends up causing problems.
I did glance over (in my effort to process outstanding 40k mailing list
messages in two days), but haven't spotted CMPXCHG8B being the culprit;
thanks for the pointer.
> And the core issue boils down to "there's no point in wasting time on
> even debugging this".
Sadly I tend to agree, being unable, owing to time constraints, to commit
myself to doing such debugging (NB glibc verification crashes i386 Linux
reliably on Pentium MMX, apparently due to FP context corruption, and I
need to prioritise debugging that, once I've figured out which actual test
case triggers it, as due to the oddity of the glibc test system it's quite
tough getting the logs matched between the host and the target system).
> So basically, the support for i486 costs us more than it is worth.
So the cost has to be reduced and just as I proposed on the previous
iteration last year this can be solved quite easily without sacrificing
i486 support by adding #UD handler for CMPXCHG8B, just as we did for
analogous stuff with some RISC platforms years if not decades ago.
I was told in said discussion that decoding x86 address modes was not as
easy as with RISC modes (thank you, Captain Obvious!), but still that
boils down to indexing into registers by ModR/M and SIB bit-fields, with a
couple of corner cases, which ought to be less than a screenful of code.
If objdump(1) can do it, so can we.
No i486 has ever run Linux SMP. Back in the day I tried hard to chase by
the spec a single i486 system built around the APIC and Intel MP Spec and
could not find any. Compaq had some proprietary stuff (Corollary bus?) we
never had support for. And we discarded support for the discrete i82489DX
APIC years ago anyway that some Pentium systems used too for the original
P5 microarchitecture or to go beyond dual. So said emulation would have
to handle the UP case only, which ought to be straightforward and well
contained.
Thoughts?
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-06 13:53 ` Maciej W. Rozycki
@ 2025-05-06 16:44 ` H. Peter Anvin
2025-05-06 17:11 ` Linus Torvalds
2025-05-08 14:51 ` Maciej W. Rozycki
0 siblings, 2 replies; 47+ messages in thread
From: H. Peter Anvin @ 2025-05-06 16:44 UTC (permalink / raw)
To: Maciej W. Rozycki, Linus Torvalds
Cc: Ingo Molnar, linux-kernel, Ahmed S . Darwish, Andrew Cooper,
Ard Biesheuvel, Arnd Bergmann, Borislav Petkov, Dave Hansen,
John Ogness, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On May 6, 2025 6:53:34 AM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Mon, 5 May 2025, Linus Torvalds wrote:
>
>> > We also have platforms that lack atomics, let alone double-precision ones
>> > and they're fine too, so why is x86 different?
>>
>> So I don't know if you saw this thread:
>>
>> https://lore.kernel.org/all/202504211553.3ba9400-lkp@intel.com/
>>
>> where I initially thought that it was the lack of TSC, but it looks
>> like it's the CMPXCHG8B code that ends up causing problems.
>
> I did glance over (in my effort to process outstanding 40k mailing list
>messages in two days), but haven't spotted CMPXCHG8B being the culprit;
>thanks for the pointer.
>
>> And the core issue boils down to "there's no point in wasting time on
>> even debugging this".
>
> Sadly I tend to agree, being unable, owing to time constraints, to commit
>myself to doing such debugging (NB glibc verification crashes i386 Linux
>reliably on Pentium MMX, apparently due to FP context corruption, and I
>need to prioritise debugging that, once I've figured out which actual test
>case triggers it, as due to the oddity of the glibc test system it's quite
>tough getting the logs matched between the host and the target system).
>
>> So basically, the support for i486 costs us more than it is worth.
>
> So the cost has to be reduced and just as I proposed on the previous
>iteration last year this can be solved quite easily without sacrificing
>i486 support by adding #UD handler for CMPXCHG8B, just as we did for
>analogous stuff with some RISC platforms years if not decades ago.
>
> I was told in said discussion that decoding x86 address modes was not as
>easy as with RISC modes (thank you, Captain Obvious!), but still that
>boils down to indexing into registers by ModR/M and SIB bit-fields, with a
>couple of corner cases, which ought to be less than a screenful of code.
>If objdump(1) can do it, so can we.
>
> No i486 has ever run Linux SMP. Back in the day I tried hard to chase by
>the spec a single i486 system built around the APIC and Intel MP Spec and
>could not find any. Compaq had some proprietary stuff (Corollary bus?) we
>never had support for. And we discarded support for the discrete i82489DX
>APIC years ago anyway that some Pentium systems used too for the original
>P5 microarchitecture or to go beyond dual. So said emulation would have
>to handle the UP case only, which ought to be straightforward and well
>contained.
>
> Thoughts?
>
> Maciej
However, building a #UD instruction emulator is a project in itself that someone would have to take on. It isn't inherently simpler – quite the opposite – than the alternatives calling to a stub function than we have now.
We have the tools to do it; there is now a full x86 instruction decoder in the kernel that one could use to do this, but...
a. Someone would have to take it on;
b. It will need continuous testing;
c. That someone would *also* have to go through the additional effort of keeping the mainline code clean for the maintainers of the modern hardware.
And at some point we will be at a point where we were with i386 that the only users are occasional testers.
With regards to EISA, you still haven't clarified if there is a true use case or if this is a museum/nostalgia project. There isn't anything *wrong* with museum projects, not at all (I recently got to play SPACEWAR! on a real PDP-1; it was amazing) but imposing a maintenance burden on the mainline developers of one of the most heavily used architecture on the planet is not practical.
If someone really wanted to, they could maybe fork off, say, arch/i486 and maintain the a version of the kernel limited to these old machines, but it would require someone being willing to do the work.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-06 16:44 ` H. Peter Anvin
@ 2025-05-06 17:11 ` Linus Torvalds
2025-05-06 17:51 ` H. Peter Anvin
2025-05-08 14:53 ` Maciej W. Rozycki
2025-05-08 14:51 ` Maciej W. Rozycki
1 sibling, 2 replies; 47+ messages in thread
From: Linus Torvalds @ 2025-05-06 17:11 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Maciej W. Rozycki, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Borislav Petkov,
Dave Hansen, John Ogness, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Tue, 6 May 2025 at 09:44, H. Peter Anvin <hpa@zytor.com> wrote:
>
> a. Someone would have to take it on;
> b. It will need continuous testing;
> c. That someone would *also* have to go through the additional effort of keeping the mainline code clean for the maintainers of the modern hardware.
I think the main issue is "when problems happen, people who
*shouldn't* have to care get reports".
I really think that the way forward is basically what we did for ia64:
get rid of i486 support in mainline, and people who care about i486
can maintain a smallish patch that basically keeps it alive for them.
Because I suspect that the "patch to keep it working in practice" is
likely going to remain pretty small: it's the silly cmpxchg helper
wrappers, it's disabling ARCH_USE_CMPXCHG_LOCKREF, and probably a few
X86_FEATURE_CX8 tests.
And it probably (a) works fine and (b) won't be code that changs very
much upstream, so maintaining it outside the main tree is likely not a
lot of work.
But because it's outside of the main tree, it won't cause pointless
noise from 0day bots etc, and won't affect people who care about
modern machines. And it can do various hacky things because the patch
would *only* be used by people who actually run on an i486-class
machine.
(Ok, if you actually care about the i486SX, the patch will be much
bigger, because it will have that whole FPU emulation code in it)
Linus
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-06 17:11 ` Linus Torvalds
@ 2025-05-06 17:51 ` H. Peter Anvin
2025-05-08 14:54 ` Maciej W. Rozycki
2025-05-08 14:53 ` Maciej W. Rozycki
1 sibling, 1 reply; 47+ messages in thread
From: H. Peter Anvin @ 2025-05-06 17:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Maciej W. Rozycki, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Borislav Petkov,
Dave Hansen, John Ogness, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On May 6, 2025 10:11:04 AM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Tue, 6 May 2025 at 09:44, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> a. Someone would have to take it on;
>> b. It will need continuous testing;
>> c. That someone would *also* have to go through the additional effort of keeping the mainline code clean for the maintainers of the modern hardware.
>
>I think the main issue is "when problems happen, people who
>*shouldn't* have to care get reports".
>
>I really think that the way forward is basically what we did for ia64:
>get rid of i486 support in mainline, and people who care about i486
>can maintain a smallish patch that basically keeps it alive for them.
>
>Because I suspect that the "patch to keep it working in practice" is
>likely going to remain pretty small: it's the silly cmpxchg helper
>wrappers, it's disabling ARCH_USE_CMPXCHG_LOCKREF, and probably a few
>X86_FEATURE_CX8 tests.
>
>And it probably (a) works fine and (b) won't be code that changs very
>much upstream, so maintaining it outside the main tree is likely not a
>lot of work.
>
>But because it's outside of the main tree, it won't cause pointless
>noise from 0day bots etc, and won't affect people who care about
>modern machines. And it can do various hacky things because the patch
>would *only* be used by people who actually run on an i486-class
>machine.
>
>(Ok, if you actually care about the i486SX, the patch will be much
>bigger, because it will have that whole FPU emulation code in it)
>
> Linus
Yes, the patch will be bigger, but it's just a bunch of highly static code copied straight out of the current kernel with very few touch points to the rest of the kernel (which is why we didn't axe it together with i386 support. Now that one was ugly, with touch points all over the place.)
It is basically the same idea as the arch/i486 I suggested, just in a separate git tree (although I guess I don't really see how this is fundamentally different than, say, arch/m68k.)
An i486/i586 retroport can presumably also axe a bunch of things like side channel mitigations; most of them aren't applicable to the in-order i486/586 pipelines and the rest ... well, on a machine that slow, you are unlikely to be running the kind of workloads that care.
Similarly, you should be able to simply unsupport the things that make the entry/exit code a nightmare, like SYSENTER and fancy NMI hacks (the latter requires an APIC.)
As far as I know, Transmeta Crusoe was the only i586-class CPU which supported SYSENTER (if that version of the firmware even shipped, I'm not sure), and Crusoe was "almost" i686 class in terms of ISA (mainly lacking PAE and NOPL, and having P5-like flags behavior.)
There is a huge gap then to the i686, with the i686 being the direct ancestor of the x86-64 systems in terms of systems architecture (APIC, PAE*, etc; SYSENTER in the second iteration; a general tightening of the ISA definition; PCI universal by then...)
But again, this is all academic unless someone steps up and wants to take on such a project.
-hpa
* – I believe there was one version of the Pentium M which didn't have PAE, at least officially, although I understand that if you flipped the CR4 bit it actually worked. I am guessing, without any concrete evidence, that there was a timing path and that it would fail at the highest operating temperatures on some subset of chips.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-06 17:51 ` H. Peter Anvin
@ 2025-05-08 14:54 ` Maciej W. Rozycki
0 siblings, 0 replies; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-08 14:54 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Borislav Petkov,
Dave Hansen, John Ogness, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Tue, 6 May 2025, H. Peter Anvin wrote:
> An i486/i586 retroport can presumably also axe a bunch of things like
> side channel mitigations; most of them aren't applicable to the in-order
> i486/586 pipelines and the rest ... well, on a machine that slow, you
> are unlikely to be running the kind of workloads that care.
>
> Similarly, you should be able to simply unsupport the things that make
> the entry/exit code a nightmare, like SYSENTER and fancy NMI hacks (the
> latter requires an APIC.)
I do have a dual i586 with an APIC; used it to work on some NMI watchdog
stuff that landed in mainline 25+ years ago. Back in the day such systems
were pretty common, built around the NX or later the HX chipset, so it's
not that APIC support is irrelevent could be dropped. If we were to go
for a separate port, than stuff could potentially be resurrected too that
was previously removed, such as discrete i82489DX APIC support.
NB that box actually still runs some server software I need for my lab
(MOP daemon, needed to netboot various DEC equipment) that I haven't
ported to POWER9 owing to higher priority items.
> There is a huge gap then to the i686, with the i686 being the direct
> ancestor of the x86-64 systems in terms of systems architecture (APIC,
> PAE*, etc; SYSENTER in the second iteration; a general tightening of the
> ISA definition; PCI universal by then...)
I suspect eventually we'll want to drop all IA-32 support from mainline;
isn't it of no commercial relevance already? Hasn't even the embedded x86
ecosystem switched to 64-bit Atom and the like?
Actually I think a project to maintain the whole IA-32 platform alive
rather than just the i486 subtarget might attract more attention and
people beyond just myself and Adrian. So far I've committed to support
across the board (Linux where applicable and the GNU toolchain) for DEC
Alpha, MIPS and VAX platforms plus a couple of small pieces such as the
defxx driver and I can hardly cope already, so taking on another large
project just won't work if I were alone with it.
> But again, this is all academic unless someone steps up and wants to
> take on such a project.
Correct, I just want to keep support to the minimum at the moment.
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-06 17:11 ` Linus Torvalds
2025-05-06 17:51 ` H. Peter Anvin
@ 2025-05-08 14:53 ` Maciej W. Rozycki
1 sibling, 0 replies; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-08 14:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Borislav Petkov,
Dave Hansen, John Ogness, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Tue, 6 May 2025, Linus Torvalds wrote:
> > a. Someone would have to take it on;
> > b. It will need continuous testing;
> > c. That someone would *also* have to go through the additional effort of keeping the mainline code clean for the maintainers of the modern hardware.
>
> I think the main issue is "when problems happen, people who
> *shouldn't* have to care get reports".
FWIW I can't agree more here.
> I really think that the way forward is basically what we did for ia64:
> get rid of i486 support in mainline, and people who care about i486
> can maintain a smallish patch that basically keeps it alive for them.
>
> Because I suspect that the "patch to keep it working in practice" is
> likely going to remain pretty small: it's the silly cmpxchg helper
> wrappers, it's disabling ARCH_USE_CMPXCHG_LOCKREF, and probably a few
> X86_FEATURE_CX8 tests.
Why would these have to be disabled if we have CMPXCHG8B emulation? Yes,
performance won't be stellar, but we talked it through already in the
context of my recent EV4 Alpha effort. People ran FPU emulation back in
the day too rather than using soft-float, which would have surely reduced
the handling overhead.
> And it probably (a) works fine and (b) won't be code that changs very
> much upstream, so maintaining it outside the main tree is likely not a
> lot of work.
Conversely dropping support for a subtarget in the kernel will likely
prompt the removal on the userland side, namely glibc, which will only
complicate things.
> But because it's outside of the main tree, it won't cause pointless
> noise from 0day bots etc, and won't affect people who care about
> modern machines. And it can do various hacky things because the patch
> would *only* be used by people who actually run on an i486-class
> machine.
This is a fair point, although I'm not sure why the bots are expected to
complain about a piece of code once it's settled and does not change. I
can't recall any mailing list traffic about MIPS instruction emulation for
legacy systems (and we made it a part of the uABI even) in what? -- 20
years or so.
And I'd prefer to stay away from hacks even at the cost of performance.
I don't find the emulation of CMPXCHG8B and maybe RDTSC if really needed
(possibly in a trivial way, such as returning an incrementing software
counter) a hack, but evolution. It has happened before.
> (Ok, if you actually care about the i486SX, the patch will be much
> bigger, because it will have that whole FPU emulation code in it)
FWIW I'm fine to see FPU emulation code go, especially as it's something
that can be sorted in the userland for the so inclined. Or you can run a
soft-float userland, for example in the form of a GCC multilib just as
done with numerous targets.
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs
2025-05-06 16:44 ` H. Peter Anvin
2025-05-06 17:11 ` Linus Torvalds
@ 2025-05-08 14:51 ` Maciej W. Rozycki
1 sibling, 0 replies; 47+ messages in thread
From: Maciej W. Rozycki @ 2025-05-08 14:51 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Ingo Molnar, linux-kernel, Ahmed S . Darwish,
Andrew Cooper, Ard Biesheuvel, Arnd Bergmann, Borislav Petkov,
Dave Hansen, John Ogness, Peter Zijlstra, Thomas Gleixner,
John Paul Adrian Glaubitz
On Tue, 6 May 2025, H. Peter Anvin wrote:
> > No i486 has ever run Linux SMP. Back in the day I tried hard to chase by
> >the spec a single i486 system built around the APIC and Intel MP Spec and
> >could not find any. Compaq had some proprietary stuff (Corollary bus?) we
> >never had support for. And we discarded support for the discrete i82489DX
> >APIC years ago anyway that some Pentium systems used too for the original
> >P5 microarchitecture or to go beyond dual. So said emulation would have
> >to handle the UP case only, which ought to be straightforward and well
> >contained.
>
> However, building a #UD instruction emulator is a project in itself that
> someone would have to take on. It isn't inherently simpler – quite the
> opposite – than the alternatives calling to a stub function than we have
> now.
Perhaps my RISC background makes me view instruction emulation as simpler
than patching code. It has been common throughout computing history too.
In any case it would contain all the handling in a single function called
from the generic #UD exception handler, something that could be `if
(IS_ENABLED(CONFIG_M486))' and therefore completely ignored for all the
newer platforms, and leaving the rest of the kernel code exactly the same
as we now have for CMPXCHG8B platforms.
My x86-fu is a bit rusty and surely I'm not familiar with all the recent
features, however I retain my 20+ years of past experience, most recently
with interfacing Atom systems via a JTAG probe to GDB over the remote
serial protocol (which did include writing instruction emulation in the
debug stub, specifically for MOV to/from debug registers or you wouldn't
be able to run e.g. BIOS initialisation with the debugger attached due to
the general-detect fault), and the i486/Pentium stuff is contemporary to
my experience, so writing such an emulation handler shouldn't be a big
deal to me.
Note that we'll only have to emulate it for the kernel itself, so the
emulation won't have to handle all the obscure corner cases, such as
16-bit address modes, odd segment prefixes, or VM86 mode.
> We have the tools to do it; there is now a full x86 instruction decoder
> in the kernel that one could use to do this, but...
>
> a. Someone would have to take it on;
> b. It will need continuous testing;
> c. That someone would *also* have to go through the additional effort of
> keeping the mainline code clean for the maintainers of the modern
> hardware.
I'd expect instruction emulation code to be zero-maintenance effort. We
have had such bits in the MIPS platform and they haven't been touched in
decades. It's not like machine instruction interpretation is ever going
to change. And none of the x86 maintainters will have to care whether it
actually works, as nobody will see any adverse effect *unless* they build
an i486 kernel *and* actually run it on an i486 both at a time. Anything
newer just won't ever trigger it.
> And at some point we will be at a point where we were with i386 that the
> only users are occasional testers.
I agree that the lack of the WP bit with the original i386 CPU was a real
showstopper and a maintenance nightmare, and still having code to handle
that misfeature would surely be a security hell nowadays too, so it had to
go as soon as feasible. As a nice side effect it let us get rid of the
287/387 PC/AT-specific handling mess.
> With regards to EISA, you still haven't clarified if there is a true use
> case or if this is a museum/nostalgia project. There isn't anything
> *wrong* with museum projects, not at all (I recently got to play
> SPACEWAR! on a real PDP-1; it was amazing) but imposing a maintenance
> burden on the mainline developers of one of the most heavily used
> architecture on the planet is not practical.
There is no commercial value and no use case beyond making sure all the
pieces involved continue to run. You can call it a museum/nostalgia
project if you prefer; for me it's the usual engineering challenge as
with everything I do around Linux.
As already stated in my reply to Borislav I don't want to put any burden
on any maintainers and I'm trying to reduce it to zero while not losing
the features. The lone presence of a piece of code isn't a burden unless
you actually have to do anything about it.
I realise it's easier done with a niche kernel architecture than with one
of the mainstream ones.
> If someone really wanted to, they could maybe fork off, say, arch/i486
> and maintain the a version of the kernel limited to these old machines,
> but it would require someone being willing to do the work.
There's willingness and there's the availability of resources. If it's
say 2KiB worth of source code difference that you don't have to look at
unless you run the platform that needs it, I'd argue I could maintain it,
but question whether it's worth forking in the first place rather than
keeping it in the main repo.
Maciej
^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2025-05-15 16:32 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-21 8:12 [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#] kernel test robot
2025-04-22 10:16 ` Arnd Bergmann
2025-04-24 2:12 ` Oliver Sang
2025-04-24 7:59 ` Arnd Bergmann
2025-04-24 16:07 ` Linus Torvalds
2025-04-24 17:54 ` [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs Ingo Molnar
2025-04-24 18:01 ` Ingo Molnar
2025-04-24 21:27 ` Arnd Bergmann
2025-04-25 7:40 ` Ingo Molnar
2025-04-25 9:30 ` Arnd Bergmann
2025-04-26 4:06 ` [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#] H. Peter Anvin
2025-04-27 5:48 ` Oliver Sang
2025-04-27 12:07 ` Arnd Bergmann
2025-04-27 16:39 ` Linus Torvalds
2025-04-27 21:19 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2025-04-25 8:41 [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs Ingo Molnar
2025-04-25 11:13 ` Arnd Bergmann
2025-04-26 8:26 ` Pavel Machek
2025-05-05 8:53 ` Maciej W. Rozycki
2025-05-05 12:48 ` H. Peter Anvin
2025-05-05 13:04 ` Maciej W. Rozycki
2025-05-05 19:57 ` H. Peter Anvin
2025-05-05 20:54 ` Borislav Petkov
2025-05-06 13:51 ` Maciej W. Rozycki
2025-05-06 14:16 ` Borislav Petkov
2025-05-08 14:51 ` Maciej W. Rozycki
2025-05-08 20:11 ` Borislav Petkov
2025-05-12 12:55 ` Maciej W. Rozycki
2025-05-12 13:48 ` Borislav Petkov
2025-05-12 17:29 ` Maciej W. Rozycki
2025-05-13 2:00 ` Linus Torvalds
2025-05-13 3:48 ` H. Peter Anvin
2025-05-13 5:43 ` John Paul Adrian Glaubitz
2025-05-13 21:55 ` Maciej W. Rozycki
2025-05-13 22:02 ` Linus Torvalds
2025-05-13 22:06 ` H. Peter Anvin
2025-05-15 16:32 ` Maciej W. Rozycki
2025-05-06 13:48 ` Maciej W. Rozycki
2025-05-06 13:54 ` John Paul Adrian Glaubitz
2025-05-05 15:59 ` Linus Torvalds
2025-05-06 13:53 ` Maciej W. Rozycki
2025-05-06 16:44 ` H. Peter Anvin
2025-05-06 17:11 ` Linus Torvalds
2025-05-06 17:51 ` H. Peter Anvin
2025-05-08 14:54 ` Maciej W. Rozycki
2025-05-08 14:53 ` Maciej W. Rozycki
2025-05-08 14:51 ` Maciej W. Rozycki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).