Unsolved
This post is more than 5 years old
3 Posts
1
4279
Linux suspend status on Ubuntu 16.4.2 and 17.4
Hi guys.
I am an active member of the Linux community, and have been so for a long time, about 20 years. Done a bit of this and that. Last week i got a brand new Dell Latitude 7275, m7 version with 4G connection.
I really like the device, in many ways. Unfortunately it seems to suffer from the same problem that my old Lenovo device did. It cant suspend, I don't know why there is so muck trouble with this and why hardware manufacturers don't run proper tests.
The status is that it hangs pretty badly if you suspend it. My plan is to do some testing on it acroding to the Intel guide.
But I think it would be good if Dell helped our here
01.org/.../hibernate-issues
/Rene
nightsky3535
17 Posts
1
May 18th, 2017 09:00
The debugging is very interesting. I might try looking into that as well. Suspend/Hibernate have been a major issue for me on my 9360. I've had to disable suspend/hibernate to avoid locking up or not coming out of sleep entirely. I hate to have to hard reboot my laptop at all, and it is very aggravating when simply having it fall asleep necessitates that I do that.
Lack of support for these power saving features was even expressed as a major sticking point on hacker news a few months ago when Canonical asked what people wanted to see in new versions of Ubuntu.
DELL-Jared D
350 Posts
0
May 18th, 2017 11:00
We don't support Linux at all on the Latitude 7275 as we currently do nothing with Linux on any of our tablets or 2-in-1's (except Chromebook 2-in-1's of course). So you're right, we're not testing Linux at all on that device.
duke_h3
3 Posts
2
May 18th, 2017 14:00
Thank you I noticed ;).
I guess my obvios question would be why. But I guess I will get som form of "policy" answer.
Just to put the issue into context, I am currently working at Ericsson, and we are looking into devices to use for some of our staff, and for us Linux is a requirement.
Now I did some debugging into the problem. Now who could have guessed. The bloody trail leads to ACPI.
[ 4.626742] Magic number: 5:463:177
[ 4.628282] acpi device:0d: hash matches
Am I correctly informed that this is the result of BIOS problems, and hence very little that Linux can do?