intel / intel/linux-intel-lts

system lag after resuming from deep s2idle (Intel Lunar Lake)

Open
#84 0 comments 2 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
250
Forks
142
PR merge metrics
No merged PRs in 30d

Description

## Hardware & Software:
1)Laptop: Lenovo ThinkPad X9-15 Gen 1
2)CPU: Intel Core Ultra 7 258 V
3)GPU: Intel Arc Graphics (using the xe driver)
4)Kernel: 7.1.3-arch1-3
5)Environment: Wayland (Hyprland also tried niri)
6)I have no thermald
## Issue
After waking up from s2idle (PC10), the Wayland interface lags critically. The freezes last from 20 to 30 seconds, after which the system fully recovers and operates normally. During the lag period, the turbostat records a hard lock of all cores at the Lowest Frequency Mode (LFM) - 400 MHz, (even if write stresss -c 8).

```
sudo turbostat --show PkgWatt,CorWatt,Bzy_MHz,Avg_MHz,PkgTmp
...
Avg_MHz Bzy_MHz PkgTmp PkgWatt CorWatt
399 400 30 3.20 1.58
399 400 30 3.20 1.58
399 400
399 400
399 400
399 400
399 400
399 400
```
## Power Limitation
Before suspend
```
sudo rdmsr -x 0x19C
88310000
```
During the lag
```
sudo rdmsr -x 0x19C
88463c00
```
After the lag
```
sudo rdmsr -x 0x19C
88352800
```

The 10-th bit is Power Limitation Status
The 11-th bit is Power Limitation log
Before sleep they were 00
During the lag were 11
After the lag became 10
## changing BD_PROCHOT
I can't ignore this signal Power Limitation by changing BD_PROCHOT, because I can't change it.
```
cat /sys/kernel/security/lockdown -pP
[none] integrity confidentiality
```
```
sudo cat /sys/module/msr/parameters/allow_writes
on
```
Add to grub `msr.allow_writes=on`, but
```
sudo rdmsr 0x1FC
ec005b
sudo wrmsr -a 0x1FC 0xec005a
sudo rdmsr 0x1FC
ec005b
```
First bit (BD PROCHOT) didn't change, it still active

Contributor guide

Open the contributing guide

Research direction

No source file or test is named. Start by reproducing the s2idle resume lag while running turbostat and checking the reported MSR power-limitation and BD_PROCHOT values before, during, and after recovery; done should include a confirmed reproduction and a narrowed kernel component or cause.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux
Domain
operating-systems, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.