I recently bought a 2024 MSI Prestige 13 AI+ Evo A2VM w/ a Intel Core Ultra 7 258V since I was looking for something lightweight (0.99kg!) which might have decent battery life (75Wh battery!) and figure I’d roll the dice on Linux compatibility.
For those interested, I’m keeping notes here: 2024 MSI Prestige 13 AI Evo A2VM · lhl/linuxlaptops Wiki · GitHub
And here’s my HW probe: HW probe of MSI Prestige 13 AI+ Evo ... #9be89b2454
I’m giving CachyOS a spin (basically Arch btw, w/ some optimized repos available). The GUI installer on their latest install ISO doesn’t work (probably due to display driver issues?) so I just did a straight manual install.
A number of things are spotty (GPU drivers, wifi) w/ the current default Arch kernel (6.11) but are cleared up if you use linux-mainline (currently 6.12rc1). I am also running linux-firmware-git for the latest firmware (and sof-firmware, required for the sound system to work).
So, the good news:
- Performance is pretty decent. Also on Geekbench, Linux outperforms Windows 11 by a few percent: MSI Prestige 13 AI+ Evo A2VMG vs MSI Prestige 13 AI+ Evo A2VMG - Geekbench
- While the 32GB of LPDDR5X-8533 is on-package/soldered, I was able to swap to a 4TB SSD w/o much problem. I went with an Acer Predator GM7, a Maxio/YMTC TLC drive that was very cheap, relatively performant, and like the almost identical Lexar NM790, has extremely low power draws
- Basically everything works w/ 6.12 - the only thing that doesn’t seem to have drivers is the Goodix fingerprint reader (expected). There is an IR camera so at some point I might try to setup
howdylogins - The hardware is great to me, from the 500 nit 2880x1800 OLED (I run it at at 200% and it looks great), the incredibly light weight, decent if not amazing ports, etc.
- Running
powertopandpowerstat, I’m measuring ~2.3W idle on TTY w/ 50% display brightness, and in GNOME tooling around, it’s usually hangs around at 5-8W, so while more testing is needed, it looks like all-day battery life under light use looks very possible
Now, the not so good news:
I have been getting some intermittent suspend lockups. Not all the time, but enough. There seems to be core dumps on wakeup due to RCU timeouts (starts with an rcu_preempt detected stalls on CPUs/tasks). Stack traces look like this:
Oct 02 17:58:29 p13 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Oct 02 17:58:29 p13 kernel: rcu: 2-...!: (0 ticks this GP) idle=6708/0/0x0 softirq=15740/15740 fqs=1 (false positive?)
Oct 02 17:58:29 p13 kernel: rcu: (detected by 6, t=18005 jiffies, g=28877, q=45 ncpus=8)
Oct 02 17:58:29 p13 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Oct 02 17:58:29 p13 kernel: rcu: 2-...!: (1 GPs behind) idle=6730/0/0x0 softirq=15740/15741 fqs=0 (false positive?)
Oct 02 17:58:29 p13 kernel: rcu: (detected by 4, t=18006 jiffies, g=28881, q=207 ncpus=8)
Oct 02 17:58:29 p13 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Oct 02 17:58:29 p13 kernel: rcu: 0-...!: (1 GPs behind) idle=7f88/0/0x0 softirq=16649/16650 fqs=0 (false positive?)
Oct 02 17:58:29 p13 kernel: rcu: 2-...!: (0 ticks this GP) idle=6758/0/0x0 softirq=15743/15744 fqs=0 (false positive?)
Oct 02 17:58:29 p13 kernel: rcu: 3-...!: (0 ticks this GP) idle=a370/0/0x0 softirq=13150/13150 fqs=0 (false positive?)
Oct 02 17:58:29 p13 kernel: rcu: (detected by 4, t=18005 jiffies, g=28889, q=204 ncpus=8)
Oct 02 17:58:29 p13 kernel: rcu: rcu_preempt kthread starved for 18005 jiffies! g28889 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=3
Oct 02 17:58:29 p13 kernel: rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
Oct 02 17:58:29 p13 kernel: rcu: RCU grace-period kthread stack dump:
A bunch of the times it’s been boltd.service dumping, but when I added shutting down boltd.service and unloading the thunderbolt module on suspend, it just sort of goes to the next thing, so there’s something more to it.
One interesting thing about these core-dumps is that the keyboard lights up, but the display doesn’t, but it also doesn’t hard-lock. While I can’t SSH in, when I review the logs after a hard reboot (journalctl -b -1), it appears that the system actually keeps logging, and just goes right back into suspend after being unable to successfully resume.
I’m doing a little bit of debugging but honestly out of my depth, so if anyone has experience or advice, that’d be great, as besides this suspend issue, there’s no other “dealbreakers” I can spot in terms of having a relatively pleasant user experience.
That’s not to say that suspend is 100% perfect otherwise, though. Currently, my suspend battery drain is not very good. Using my batterylog tool, here’s what 8h of suspend looks like atm:
Slept for 8.01 hours
Used 7.17 Wh, an average rate of 0.89 W
At 0.89/Wh drain you battery would be empty in 45.24 hours
For your 75.99 Wh battery this is 1.18%/hr or 28.25%/day
I’ve run S0ixSelftestTool and there are a couple things. When checking for PC10 residency, it looks like it simply doesn’t go there:
The CPU runtime PC10 residency when screen ON: %
The CPU runtime PC8 residency when screen ON: 78.26%
And when checking suspend:
---Check S2idle path S0ix Residency---:
The system OS Kernel version is:
Linux p13 6.12.0-rc1-1-mainline #1 SMP PREEMPT_DYNAMIC Tue, 01 Oct 2024 19:05:54 +0000 x86_64 GNU/Linux
---Check whether your system supports S0ix or not---:
Low Power S0 Idle is:1
Your system supports low power S0 idle capability.
...
---Judge PC10, S0ix residency available status---:
Test system supports S0ix.y substate
S0ix substate before S2idle:
S0i2.0 S0i2.1 S0i2.2
S0ix substate residency before S2idle:
0 0 0
CPU Core C7 residency after S2idle is: 48.00
CPU Package C-state 2 residency after S2idle is: 0.00
CPU Package C-state 3 residency after S2idle is: 0.00
CPU Package C-state 8 residency after S2idle is: 0.06
CPU Package C-state 10 residency after S2idle is: 0.05
S0ix residency after S2idle is:
Your system supports S0ix substates, but did not achieve the shallowest s0i2.0
Here is the S0ix substates status:
Substate Residency
S0i2.0 0
S0i2.1 7350
S0i2.2 0
...
Did not detect the potential blockers from substate_requirements,
need to check substate_status_registers file for the advanced debug.
...
Your system south port controller power gating state is OK after 30 seconds runtime check.
It looks like there isn’t anything obviously wrong, but again, I’m not an expert on S0ix suspend so who knows.
I’ll probably try setting up suspend-then-hibernate, as I’m not worried about a few percent here or there, it’d just be nice to close the lid overnight and not wake up to a dead system.
There don’t seem to be a lot of active Linux laptop forums for digging into this stuff, but if anyone has any pointers on where to possibly get the best help in getting to the bottom of things on the suspend lockups (before collecting all my logs and filing a bug with on the kernel mailing list) I’m all ears!
