Bug 14100
| Summary: | re-suspend on wakeup due to ata exceptions - Lenovo X61 Tablet | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Alexander Myodov (amyodov) |
| Component: | Power-Sleep-Wake | Assignee: | Zhang Rui (rui.zhang) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | enhancement | CC: | acpi-bugzilla, lenb, pn |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.30-1-amd64, 2.6.31-rc6-amd64 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
Dmesg output after suspend-resume-resuspend-resume
Better dmesg output |
||
|
Description
Alexander Myodov
2009-08-31 16:40:52 UTC
If you enter S3 by running "echo mem > /sys/power/state", and then press the power button to resume, does the problem still exist? Hmm, I've made several attempts and didn't got a problem even once. Any hints what that may mean and why it started only with upgrading to 2.6.29/30 (and goes back if I downgrade back to 2.6.26)? I mean, I've made several attempts of "echo mem > /sys/power/state", as you requested. the ata exceptions are still there in the above tests, right? I think the problem is that your laptop receives another lid event on resume. run "lsof /proc/acpi/event" to see which process is reading this file, kill that process and close the lid, does the laptop suspend? just to make sure I understand... When you suspend by typing "echo mem > /sys/power/state" and resume by using the power button, it always works in all versions tested, and has no ata errors no matter how many times it is invoked, yes? There are two issues here, maybe independent. Firstly, the LID events seem to be causing the double suspend. Secondly, the ata error messages... Zhang, it seems that since 2.6.30 (maybe even earlier), Debian kernel team stopped to include support of /proc/acpi/event into the debian kernels. Therefore, "lsof /proc/acpi/event" shows just the single acpid process under 2.6.26, and fails with "No such file or directory" under 2.6.30. But note it doesn't stop "echo mem > /sys/power/state" from working under both kernels! What is the most contemporary way of listening to the acpi events in 2.6.30 kernels, except /proc/acpi/event? How can I find out what is causing double suspend (if it is a root cause of the issue)? Does it worth to get the Debian maintainers for acpid and acpi-support packages notified on the issue, if it happens on the boundary of kernel and user-level acpi support? Len, I tried it again in 2.6.30, and it seems to me, thar the similar ATA/e1000e errors are STILL generated with "echo mem > /sys/power/state", but they do not block the laptop from wakeup. Yes, these may be two independent issues, and the ata errors are irrelevant to the double suspend. please run "echo 0x00080044 > /sys/module/acpi/parameters/debug_layer" "echo 0x88000107 > /sys/module/acpi/parameters/debug_level" and attach the dmesg output after suspend and resume. ping... Sorry for slow response. Seems like I don't have "CONFIG_ACPI_DEBUG=y" in stock Debian kernel config, hence I need to figure out how to properly recompile the kernel with these options, and to run the tests afterwards. I'll definitely reply as soon as I succeed. Well, if it helps - attaching the dmesg output. But seems it was stripped, and increasing the bufsize for dmesg does not help much. Created attachment 23277 [details]
Dmesg output after suspend-resume-resuspend-resume
please boot with log_buf_len=4M and reattach the dmesg output. Created attachment 23427 [details]
Better dmesg output
Attached the new files. I managed to catch "dmesg" in a second between the first resume and a moment it went suspended again, that is the "1" file. The "2" file is the dmesg output after the second, successful resume. please remove the acpi button driver before S3 and see if the problem still exists. Note that you may need to rebuild the kernel if button driver is built in. ping ... Please feel free to close this bug with something like INSUFFICIENT_DATA; I'm not sure if this bug is fixed, but I'm afraid I am not able to perform my part of investigation right now. If I get a chance to collect some more information, I'll reopen it, but at the moment, it should not spoil the statistics. Okay. close this bug for now. I was struck by the same issue, which is reported on several trackers. For me the solution "purge uswsusp" (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554046) solved the issue on Debian. Purging "uswsusp" didn't help in my case; neither did purging "apmd" or the outdated "kpowersave" and "klaptopdaemon". Purging "acpi-support" (as suggested over there too) caused my laptop to don't suspend automatically at all after closing the lid, so I returned it. I wonder what else could be purged while I am on the purging spree. |