Since the update from kernel 3.13-6 to 3.13-7 (i686), the Lid switch of my laptop (samsung N210) is not working. I am using systemd v212 (/etc/systemd/logind.conf) to suspend my laptop, but after the first suspend, systemd keep suspending everytime the laptop wake up. Here is what I get (with the lid opened or closed):
$ cat /proc/acpi/button/lid/LID0/state state: closed
The same command before suspending returns "state: opened". Downgrading solve the problem, so this is not hardware. I can't find anything interesting in the logs (except that after suspending there is no trace of the lid switch). Other information: If I disable the suspend on lid switch, the lid state is working properly (changing between opened and closed).
I have another laptop (Dell XPS) which works fine, even on kernel 3.13-7 (x86_64). On this one I use kde power manager (but I don't think systemd is the problem).
Any one has an idea or a similar problem?
Thank you for your help.
From a quick glance, this () might be related - this patch is in 3.13.6, but not 3.13.7. It may have had some adverse effects, I suggest you write an email to the people listed there and see what they have to say:
Nearly same for me on Samsung N150.
Monitoring lid by systemd: after first lid close, a endless chain of suspends follows
Monitoring lid by XFCE: toggeling suspend by lid close works sometimes.
Switching to linux-lts kernel solved the problem for now.
If none of you guys gets in touch with the maintainers, this problem will stay forever. Here is what the kernel says you should write to:
$ git show ad332c8a45330d170bb38b95209de449b31cd1b4 | ./scripts/get_maintainer.pl "Rafael J. Wysocki" <firstname.lastname@example.org> (supporter:ACPI) Len Brown <email@example.com> (supporter:ACPI) firstname.lastname@example.org (open list:ACPI) email@example.com (open list)
Thanks for pointing that possibility to us, I just wrote an email to firstname.lastname@example.org.
Hm, you should write all of those addresses at once.
Sorry I completely forgot this thread (and I didn't get any notification...). I already reported the problem, and it has already be fix.
Here is the link to the patch you can apply to kernel 3.13.7 (in the attachment of the comment): https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173
I tested the patch on linux 3.13.7 and it works just great. I'll try to upload my configuration to AUR (although I don't have much time and I that would be my first time). I can at least send you the PKGBUILD: http://bpaste.net/show/xLBQcAW9Z0vUa5BNlpBE/
Here is a quick (and maybe not that good) explanation of the problem for those interested (skip it if you don't care):
The patch that causes the problem fix a very critical problem on new samsung laptops. Those computers continue to report acpi events when they are in suspend mode but do not send them to the kernel (the processor being off), even after resuming. If too many events are recorded, the acpi controller get stuck (and it looks like it is permanent, because it affects windows too). So the solution is to clear the old acpi events after resuming. The problem is that old samsung laptop that do not have this problem fail to send the lid open event after resuming (this event is reported before resuming, but not after), so it is cleared because of the new patch. The patch I sent will process these evens instead of ignoring them. I hope this is clear.
For the full thread, here are the link, from the linux-acpi mailing list that explain why this happens: http://marc.info/?l=linux-acpi&m=139564741817605&w=2
The fix won't be available in the mainline before a long time because of the very critical status of the previous commit, which fixes a problem a lot worse that the one it creates. So it has to be carefully tested
If you have any problem or questions don't hesitate to contact me. I subscribed to the topic so I should receive the notifications now.
I also have similar issue with systemd 212 but not that too serious. After wake up from sleep, like after 20 seconds, my Samsung N148 will suspend again and I have to close and reopen the lid. If I execute systemctl suspend from command line, the system run just fine after wake up from sleep. I'm using kernel 3.14 with this patches applied. Same problem, my machine will suspend again after wake up from sleep.
Last edited by serdotlinecho (2014-04-03 12:07:38)
You need to apply the patch in the attachment of the comment (attachment 131151). If you use my PKGBUILD file (the one I sent via pastebin), you need to call it ec_clear_process.patch. Please tell me if it works or not, otherwise I need to prevent the kernel team to modify the patch.
This bug is not due to systemd. We should expect any power manager to behave the same way if they are configured to suspend the laptop after closing the lid.
Thanks Nicop for your explanation and your effort. I'll test the patch asap.
sorry, I didn't knew what I didn't know, so my first attempt to use that patch failed, but that was my fault, haven't done such things before.
running a makepkg now, however long thatt t takes on a n150 if the package is the kernel...
[old post deleted]
Last edited by Carl Karl (2014-04-05 06:55:20)
OK, now I got it, complining the kernel with a N150 takes ages, but I can confirm:
Works for me, the patch! :-)
($ uname -a
Linux archie 3.13.8-1-ARCH #2 SMP PREEMPT Sat Apr 5 22:19:19 CEST 2014 i686 GNU/Linux
Thanks for submitting it!
How can I know when this patch is included?
Before that, updating the kernel doesn't seem to be useful to me, compiling it by myself just takes too long...
First of all, the patch must be commited in some upstream git tree, so that we know it will be merged into the Linus tree eventually. We can then backport the patch to Arch's kernel.
Thanks for your answer, I'll IgnorePkg = linux, linux-headers meanwhile... ...and hope somebody feels responsible.
But to be honest, the lts-kernel seems to be running better at the moment, with 3.13, sometimes USB-devices aren't recognized.
As you can read above, the patch is not submitted yet, but you can build your own kernel including it if you want to. Or use linux-lts.
Or use linux-lts.
Actually that is what I do. It takes a lot of time to compile custom kernel on Atom N270 CPU.
Last edited by knedlyk (2014-04-13 05:39:39)
The patch will soon be communicated to the upstream, so it should be included soon in the latest kernel.
I created a custom kernel in AUR that include the patch. Here is the link: linux-samsung-netbook.
I hope this will be useful. I will tell you when the patch is released in the archlinux binary kernel using this thread, so that you can switch back to it.
Last edited by Nicop (2014-05-03 02:32:02)
Can you give an estimate on when the patch will be release in the arch binary kernel?
I just got a new Thinkpad X1 Carbon with Kernel version 3.14.4-1 and am experiencing the same issue (also fn key not working, with a patch available, but not yet upstream). If it is only a matter of a few weeks, I will just stick with the situation for now and avoid closing the lid for the time being and install the new kernel as soon as it is distributed.
Thanks for the work you put in this.
edit: Contrary to what I had said before, I just installed the kernel and still faced the same problem.
I will open a new thread for the thinkpad (and paste the link here).
Last edited by hanslovsky (2014-05-19 20:04:27)
Sorry for the late answer. The patch that caused only applies to Samsung laptops as the code is only executed on laptops reporting a Samsung brand when using dmidecode. I'll answer you more precisly on your thread.
As for the patch, it has been committed in the stable branch of linux-3.14, so it should be available in the next release. I am still maintaining the patched kernel in the AUR repository, but I will delete it as soon as the patch is available in the archlinux official kernel. I'll let you know when it is done.
Thank you for your patience.