linux-kernel - [PATCH] cpuidle: Keep non-boot CPUs online during deep sleep to handle boot CPU deadlocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID:
 <TYRPR01MB1641253A8C639D7C76E37DEE9F5CAA@TYRPR01MB16412.jpnprd01.prod.outlook.com>
Date: Fri, 14 Nov 2025 03:34:25 +0000
From: fengtian guo <fengtian_guo@...mail.com>
To: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot
	<vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel
 Gorman <mgorman@...e.de>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: [PATCH] cpuidle: Keep non-boot CPUs online during deep sleep to
 handle boot CPU deadlocks

Hi , All experts

Attachment is patch and source file base on 5.10 linux kernel

Based on the provided log analysis and system behavior description, here's a professional summary for Linux kernel community experts:

---

## Subject: System Hang During Deep Sleep on Spreadtrum TH2105 - Suspected CPU0 Deadlock

### Problem Description
Our Spreadtrum TH2105-based device experiences complete system hangs during deep sleep states, requiring forced hardware resets. The system becomes unresponsive for approximately 40 minutes before manual intervention.

### Key Log Evidence

#### From `hilog_kmsg.022.20251103-160607`:
```
Line 8105: 11-03 16:27:58.707 <6> [24285.271346] ;-Disabling non-boot CPUs ...
Line 8208: 11-03 16:27:58.711 <6> [24285.291750] ;-Enabling non-boot CPUs ...
Line 8546: 11-03 16:27:59.765 <6> [24285.851102] ;-Disabling non-boot CPUs ...
...
Line 13573: 11-03 16:28:43.678 <6> [24292.094583] ;-Disabling non-boot CPUs ...
Line 13675: 11-03 16:28:43.679 <6> [24292.115024] ;-Enabling non-boot CPUs ...
```

#### From `hilog_kmsg.023.20251103-171330`:
**Last normal log entry:**
```
11-03 16:28:43.680 <6> [24292.437838] -sprd-vpu-pd: vpu_pd_dec:vpu_pw_off OK
11-03 16:28:43.680 <6> [24292.437887] -sprd-vpu-pd: vpu_pd_enc1:vpu_pw_off OK
```

**System reboot after 45 minutes of silence:**
```
11-03 17:13:29.991 <6> [0.000000] -Booting Linux on physical CPU 0x0000000000 [0x412fd050]
```

### Analysis

1. **Deep Sleep Pattern**: The system enters deep sleep approximately every second, disabling all non-boot CPUs (CPUs 1-7), leaving only the boot CPU (CPU0) active.

2. **Watchdog Vulnerability**: During deep sleep:
   - Only CPU0 remains powered
   - Other CPUs cannot handle interrupts or run watchdog callback handlers
   - If CPU0 encounters a deadlock, the entire system freezes
   - Watchdog cannot detect the hang since no CPUs are available to schedule watchdog processes

3. **Timeline**:
   - **16:05:37**: Deep sleep cycles begin
   - **16:28:43**: Last successful log entry before hang
   - **17:13:30**: System forcibly rebooted after ~45 minutes of unresponsiveness

4. **Additional Context**: We observe frequent GPU and WLAN sleep/wake cycles, but the primary issue appears related to CPU power management during deep sleep.

### Proposed Solution

We recommend modifying the deep sleep implementation to keep additional CPUs (e.g., CPU1 and CPU2) powered during deep sleep states. This would ensure:

- Watchdog processes have available CPUs for scheduling
- System can detect and recover from CPU0 deadlocks
- Maintain proper crash dump collection and system logging during hangs

### Technical Background

Our current watchdog design:
- Watchdog kick interval: 20 seconds
- Timeout threshold: 30 seconds
- Maximum tolerable hang duration: 10 seconds
- Multi-CPU coordination ensures at least one CPU feeds the watchdog within any 30-second window

However, this fails when only CPU0 remains active and encounters a deadlock during deep sleep.

We would appreciate community feedback on this approach and any alternative solutions for handling deep sleep deadlocks in multi-core systems.

---

This summary maintains the original log evidence while providing clear technical analysis in English suitable for kernel community discussion.

Content of type "text/html" skipped

Download attachment "fengtian_cpu0_fix_patch_and_source.zip" of type "application/zip" (23431 bytes)