No 3D accelerated graphics in Xorg after suspend/resume on Lenovo Ideapad 520S

icodeforyou

icodeforyou

Hey everyone! I have a strange problem with suspend/resume. It SOMETIMES happens that I loose 3D acceleration in XOrg when I suspend via acpiconf -s 3 and resume again. In this case picom crashes, so does alacritty and any attempt to run glxgears will make it crash again.

If, while being in this state, I suspend/resume AGAIN, 3D graphics will typically come back, but it will be significantly slower than it should be (like glxgears will give me framerates around 45fps, while we should be normally in the several 100s).

If, after first loosing 3D acceleration via suspend/resume and then regaining it via another suspend/resume, I restart the X server, we are back to normal. HOWEVER if I only restart the X server after loosing 3D acceleration that alone will not make it come back. I have to suspend/resume again.

The machine is a Lenovo Ideapad 520S with an Intel Kaby Lake i5 8250U CPU and 620 UHD graphics.

I am quite new to FreeBSD and even though it has been quite an interesting ride so far, I am a bit at a loss finding out what is going on here and how to debug it. Any suggestions are appreciated!
 
icodeforyou I have used Lenovo laptops for a very good - but not quite complete - desktop. I never got suspend/resume working (or at least the resume bit), and put up with merely shutting down the laptop when I wanted to fold it up. I understand suspend/resume works better now, but I can believe it is not perfect.

You might well get it working, but I am afraid I cannot help, except to say that many things with a desktop under Freebsd, often take a while, much thought and experimenting before you get them right. In any case, you should be able to use your laptop as a really good portable desktop.

Incidentally, I have just ordered a new Lenovo Ideapad (different model), so I will keep an eye on this thread.
 
Thanks for the reply Geezer! I might say that suspend/resume sometimes works fine with acpiconf -s 3 ... about 50% of the time I'd say. So whatever it is, there must be a reason that some part of the graphics card is not properly awake after resume in the 50% of the cases. I'd say: maybe sometimes the order of waking up different things is off? But I don't know anything about how this is implemented...

That being said: The general experience on the Ideapad 520S has been quite good. Most stuff works, even a fairly recent pair of bluetooth headphones is usable now for me on FreeBSD. The stuff that does not work at all is minor. The acpi issues are the most significant problem left I'd say.
 
I have hw.syscons.sc_no_suspend_vtswitch=1 in my /boot/loader.conf, maybe that helps with it. Currently my x230 suspends nicely and resumes 99%. Sometimes USB hangs, but that may be the docking station.
You may also want hw.acpi.reset_video=1 in your sysctl.conf. Please try and come back with results.
 
Thanks for your answers!

Crivens

Both these options do not appear to have any positive impact. In fact when setting hw.acpi.reset_video=1 suspend/resume basically stopped working as far as I can see. (I tried three times, so not really statistically sound, but that is about when it gets slightly tedious to re-type the encryption password for your disk). The machine would not come alive again at all.

bsduck

I'd love to try the new drivers, but they are not present in my version of the ports collection. The directory /usr/ports/graphics/drm-510-kmod/ does not exist. I tried updating it via portsnap fetch, but they aren't there. I am runnning 13.1-RELEASE indeed and I am on the latest branch for packages set in /usr/local/etc/pkg/repos/FreeBSD.conf.
 
You need portsnap fetch update to actually update the ports tree.

portsnap(8)
Code: 
update       Update a ports tree extracted using the extract command.  You must run this command to apply changes to your ports tree after downloading updates via
             the fetch or cron commands.  Again, note that in the parts of the ports tree which are being updated, any local changes or additions will be removed.

[...]

EXAMPLES
     Fetch the snapshots and create the ports(7) tree under /usr/ports:
           portsnap fetch extract
                  
     Update the ports tree:
           portsnap fetch update
 
bsduck

I forgot to do an extract apparently :) Now I have the newer driver (I hope). But suspend/resume sadly remains somewhat finicky... I just thought that I might put in that old Windows harddisk I have for this machine and try a bios update with it. Maybe that does something good...

Other than that: is there any way to debug this, i.e. to actually see what is happening in the wake-up process? Given that it is rather like a lottery... sometimes it works, sometimes you get complete reboots, sometimes you loose 3D graphics. I'd say that sounds like the order in which things are happening isn't right at times. A race condition basically...
 
a particular sad fact: the acpi support for my laptop in Linux (Fedora 35 live usb) appears to be flawless. It sleeps and wakes up fast and reliably. And most media keys are working. But that should be possible in BSD-land as well, right?
 
icodeforyou said:
a particular sad fact: the acpi support for my laptop in Linux (Fedora 35 live usb) appears to be flawless. It sleeps and wakes up fast and reliably. And most media keys are working. But that should be possible in BSD-land as well, right?
Click to expand...
Nope.

You may not get everything working. You can get a great desktop, with all the features of Freebsd, that exceeds linux in total.
 
Geezer said:
Nope.

You may not get everything working. You can get a great desktop, with all the features of Freebsd, that exceeds linux in total.
Click to expand...
Nah, I am not convinced yet by that stance :D I am using FreeBSD just a little over 2 weeks now and it has been really enjoyable so far. My original intent was to learn about FreeBSD because I wanted to debug OPNsense. Turns out FreeBSD is quite nice on a laptop minus a few remaining quirks on this particular model.

But the stuff on Linux is all open source to be found somewhere, it should be doable to get it working on FreeBSD as well, right? Also the device I am running FreeBSD on is a Lenovo, and I can't imagine that Lenovo's implementation of things on Ideapads is vastly different from Thinkpads.
 
Little update on the suspend/resume issue. I am now running the new driver mentioned by bsduck. Right now the resume after suspend worked for 10x in a row. The only additional thing I have set now is debug.acpi.max_threads="1" in /boot/loader.conf. The reason being that I was suspecting a race condition which might disappear if I limit the number of threads to 1.

A little question on the sidelines. Is there a significant difference in the syntax between debug.acpi.max_threads="1" or debug.acpi.max_threads=1 for /boot/loader.conf? Just asking because I have seen both things already for certain settings.

We shall see if the current kinda working state is the new normal or a lucky exception. I will report back in the coming days or once it starts to fail again.

In any case: If anyone hows how to debug the suspend/resume process in more detail, I would love to know. Equally: if someone knows someone else who might know, this would be useful as well :D
 
The max threads setting is a good one. But it does wreck havoc with some asus.
Basically, lenovo is going downhill now with quality. No comparison with old Thinkpads IMHO.
 
Crivens, the Ideapad series is consumer hardware anyways. The price of this one new in 2018 might have been around $750-800 and I picked it up used recently. It was never meant to be on the same level as the Thinkpads, old or new. That being said, it does work quite well. It is upgradeable in terms of RAM, nvme and SATA SSD or HDD and battery. And the Intel Kaby Lake is a quad-core CPU, so not bad at all. The display on the other hand, while being IPS with good viewing angles, has quite washed-out colors and not a lot of brightness.

But I'd say the FreeBSD experiment has been a success on this machine so far.

Still I was wondering if there is a way to get the acpi_ibm module running on this one, which might provide support for media keys. I just can't imagine that the implmentation of the keyboard is that different to the thinkpad series of the same age. But that might be for another thread...
 
A little update: It appears to be working reliably now, I have not had a single crash. Apparently the mixture of new drivers plus debug.acpi.max_threads="1" in /boot/loader.conf has done it.

Thanks to all who have replied, Geezer, Crivens and of course bsduck
 
Installed graphics/drm-510-kmod and set debug.acpi.max_threads="1", no resume issues on Thinkpad X1 Yoga (1st Gen) so far.
 
May I add a warning for those to come? Try setting things up from the loader shell first. When it works, then add it to loader.conf. Much easier that getting a system to boot again that way when you did not put things in there that hose the boot process.
 
Crivens since I am a FreeBSD newbie, how would this be done? But of course it makes sense to test these settings before trying to boot them.

blackhaz then maybe you have a different problem then my case. I assume it never works for you?
 
You must log in or register to reply here.
Back
Top