I purchased a Xiaomi Notebook Pro 120G (i5-12450H, Nvidia MX550) last week and everything seems to work fine, except waking from suspend.
Every time I try to wake up from suspend (by closing the lid, the power button or systemctl suspend) the display doesn’t turn on. No cursor, no backlight, nothing. I can hear the beeping when I press the volume keys and the caps lock key briefly flashes when I toggle it, so I presume that most of the system is awake (journalctl confirms this, but I don’t seen any errors around the wakeup line)
I’ve been at this for 3 days with no luck. Here’s what I’ve tried so far
Some posts online said to try the LTS kernel. This didn’t work, and for some reason gnome starts in X11 instead of wayland on the LTS kernel.
Others said they got it working using the nvidia drivers & the zen-kernel. This didn’t work for me, and the nvidia drivers made the normal 6.10 kernel boot to a blinking cursor so I uninstalled it. I had to re-install the 6.10 kernel because stop jobs made the boot time very slow
Since this a 12th gen CPU, I thought this might be the issue - an incorrect VBT from the manufacturer that claimed there were 2 eDPs. According to the gitlab discussion, the patches have been approved and will probably come in 6.3. I compiled a kernel with the naive patch mentioned in the wiki (disabling initialisation of the second display). This initially didn’t work. But after a BIOS update, it occasionally works when suspended by closing the lid. Suspending with the power-button or command line still results in a black screen.
Here’s the journal from the previous boot - where suspending by closing the lid worked the first time but required a hard reboot the second https://pastebin.com/vLv4E5Cz
Any suggestions on how I should debug this further?
EDIT: I’m dual booting with windows 11. Fast startup has been disabled.
I notice it has nvidia but it looks like it is running on nouveau open source drivers ? Did you not use the nvidia option on the install? The MX550 is supported by the latest Nvidia drivers. I see you tried Nvidia but you need the following kernel parameter ibt=off in the command line and then update grub if using grub boot.
Edit: If using systemd boot it is set differently.
Edit: I assume your notebook is running on Intel graphics? Post the output for
inxi -Ga
Did you check the power management settings.
Edit: If using Nvidia there is a sleep service. I’m not sure how hybrid would work though if not switched to Nvidia as it would be running on the Intel internal graphics.
I installed the nvidia drivers via nvidia-inst, and enabled nvidia-resume.service.
The system boots now with ibt=off, I’m a little ashamed that didn’t cross my mind before.
However, resume from suspend still doesn’t turn on the screen. But it did briefly show the login screen once, before turning the screen off again. Here’s the journal for that boot - boot-user-nvidia.log
Have you tried switching TTY when the issue happens? In similar cases, switching to another TTY and back was bringing Xorg back.
If another TTY is working, you might do some troubleshooting, check relevant services, running tasks, or other things .
I tried KDE. Suspend doesn’t work in X11 nor Wayland. I’m hoping it’s something I can fix on my end. Or at worst the VBT issue, that will at least fixed at some point in the future.
IIRC, and from other topics, similar issues have been reported (with nvidia, but can’t remember all cases), but it is weird that it breaks on both nouveau and nvidia.
If you are comfortable with it , I would try disabling nvidia card, since you also have iGPU.
I would not expect any miracles, so it is not a priority/necessary test.
This is an odd one… After switching to the nvidia drivers and X11, it actually took a while to replicate the issue. The screen wakes up more reliably now but not always. In the logs below, I tested twice by suspending via lid, and twice via the power menu. It failed the 5th time when I plugged the charger in.
It’s a USB C charger that, according to the specs, can also output to an external monitor. I’m not sure if its the cause, since I also ran into the issue with the charger unplugged.
This is an old log (Feb 09 21:16:42), although I was expecting a date issue from the Xorg log (you need to check the date), not journal log, where you are getting what you request .
Anyway, both logs look like a dual GPU (PRIME) setup, but I suppose eDP-1 is internally connected to Intel, so it is a fake(?) single GPU setup.
Please, post a full inxi, just for the record (inxi -Faz) and for keeping this model in my blacklist .
What options do you have in BIOS for GPUs?
Have you checked BIOS, or the User Manual for Sleep modes options? Tested any?
It’s rendering on the Intel even though Nvidia drivers are installed. It’s a hybrid laptop so one must have some way of switching Gpu. So the sleep and suspend process to resume would be on the Intel Gpu?
With the data at hand, I can only make assumptions. Looks like, not it is, because the logs show two cards and two video drivers in action (card0, card1 and modesetting, NVIDIA). In a pure single GPU system/boot, you can see only one of them. Of course, as I said…
depending on how the vendor implements GPU connections, where vendors supply a dGPU-only option, the iGPU would not show, and the system will work like the iGPU is completely absent. Not many Laptop vendors do it, though. Many Laptops have the external output connected to the dGPU, which make us workaround it at times. In the same sense, I assumed that if the embeded monitor was connected to the iGPU, a PRIME setup is the only way, even if a BIOS setting was supplied. My assumption was made, because you said
answering to my post:
My misunderstanding, of course.
But we are having a good time, aren’t we?
I regret there is no extra clues, and I don’t expect any, since you haven’t changed anything, in comparison to previous ones (I think). That’s why I thought that an option for a single-GPU setup might give more data (hopefully ). But since there is no such option…
I wouldn’t dare asking you to disable nvidia with some magic tricks. FWIW, I also have a similar issue (session killed after some time in idle), but I prefer to keep working and suspend manually, instead of troubleshooting it (waste of time… ).
In my case, and I suspect this for other (forum unsolved topics) cases, I suspect the OOMkiller, but as I said, I won’t waste my time, and may just wait for a new package with a fix.
BTW, some BIOS firmware uncover extra settings, when you add/initiate the Admin password…
Yeah, I settled into just not auto-suspending now. It works most times when suspend via the lid. And I save my work often enough, so restarting doesn’t lead to data loss.
Guess I’ll wait and hope the next kernel/driver releases fix something. I’ll update here when they do.
Thanks for the time you’ve put it, really appreciate it!!
So there are no settings in the Bios for Hybrid or Dedicated or Internal graphics? Have you tried optimus-manager or other method to switch to dedicated graphics so it’ rendering on the nvidia card and see if it resumes if using that? Just curious?
AMOF this is a good idea, easy, quick, and can undo it easily. I don’t usually suggest optimus-manager for a PRIME setup, but for testing this issue, it is an easy testing option.
.
, I would try disabling nvidia card, since you also have iGPU.
(you need to check the date), not journal log, where you are getting what you request 
.
.
) Hope they help
). But since there is no such option… 