Bug 53011
| Summary: | Resumed system freezes - Toshiba Tecra R950-117 | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | kk1 (ja.schm) |
| Component: | Hibernation/Suspend | Assignee: | Lv Zheng (lv.zheng) |
| Status: | CLOSED DUPLICATE | ||
| Severity: | normal | CC: | aaron.lu, lenb, rui.zhang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101897 | ||
| Kernel Version: | 3.8 rc4 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | acpidump | ||
|
Description
kk1
2013-01-24 21:16:33 UTC
It seems the big problem is that your system freezes after the resume. The fact that Fn keys are not working is interesting, but there are bigger problems:-) Please describe the failure in more detail. Are you able to use the system for a while before it freezes, or does it freeze before you can get control? Does the keyboard work? Network? Can you observe changes in /proc/interrupts? how about the power button -- does a single press cause an acpi event and the system shuts down under software control, or do you have to hold the power button down for 5 sec for a "hard" power-off? I don`t have a problem with resume. I have a problem with the second suspend. 1. I power on notebook normally, all is working 2. I suspend to RAM -> Notebook suspends normally 3. I resume from suspend normally, but Brightness, suspend and mute Fn Keys do not work and I'm not able suspend second time because when I try to suspend for the second time, system freezes. The volume Fn keys, network, keyboard always work after resume. System freezes when I start to suspend via Window manager ( Fn key not working) or via terminal with pm-suspend command for the second time. Suspend start normally but never finish. After start of the second suspend I have to hold power button for a "hard" power-off. With kernel 3.3.8 I'm able to suspend to RAM more then once. Brightness Fn keys work after resume with this hack: http://askubuntu.com/questions/184584/backlight-does-not-work-on-toshiba-portege-and-lts-12-04 . Interesting is, that this problem occured when I upgraded BIOS to version 6.40. I think, this bug is the same or very similar to bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088721 or https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1094800 You have some interesting stuff in the kernel command line. Why do you need them? Are they still needed with 3.8-rc5? Hello kkl, Please attach the output of acpidump: # acpidump > acpidump.out It looks like to me, the FADT table may have the sleep control/status reg set. Created attachment 97721 [details]
acpidump
I have attached acpidump.out. I don't know if it's important but program acpidump finished with message "Wrong checksum for FADT!"
I forgot to say thank you Aaron Lu. (In reply to comment #6) > I forgot to say thank you Aaron Lu. Hi kk1, You are welcome. Can you please test the following git commits? 1 da0df92b57311aa1b26a2a90599ed16e1e968b90 expected result: everything works fine 2 b74f05d61b73af584d0c39121980171389ecfaaa expected result: first resume will result in reboot 3 0dd90aa9d6222e12201f05c0058e8741b7f66474 expected result: first resume will result in reboot 4 dba69d1092e291e257fb5673a3ad0e4c87878ebc expected result: first suspend ok, but second suspend will freeze 5 latest linus' git tree expected result: first suspend ok, but second suspend will freeze Thanks. Sorry for my late answer, but I copiled kernel and here is result: commit da0df92b57311aa1b26a2a90599ed16e1e968b90 is as you wrote commit b74f05d61b73af584d0c39121980171389ecfaaa is as you wrote commit 0dd90aa9d6222e12201f05c0058e8741b7f66474 is as you wrote commit dba69d1092e291e257fb5673a3ad0e4c87878ebc Oddly enough, this commit is ok. It's this commit right?, because I think it's kernel 3.3.0 and first broken kernel was 3.4 for me. last commit f94eeb423bd6061fe68c490dcb11c74e5267f6a2 from http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux is as you wrote Thanks. Thanks a lot for the test! > > commit dba69d1092e291e257fb5673a3ad0e4c87878ebc Oddly enough, this commit is > ok. It's this commit right?, because I think it's kernel 3.3.0 and first > broken > kernel was 3.4 for me. this commit is meant to fix the first-resume-resulted-in-reboot issue, but is believed to cause the 2nd suspend failure problem according to the linked ubuntu bug page, but obviously, it is not the case. So with this commit, everything works OK? If so, there must be a commit somewhere between this commit and v3.4 that broke the 2nd suspend. Please use git-bisect to find it, below are steps: 1 git clone Linus' tree if you haven't yet: $ git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2 start bisect $ git bisect start 3 mark the good commit that you have verified $ git bisect good dba69d1092e291e257fb5673a3ad0e4c87878ebc 4 mark the bad commit $ git bisect bad v3.4 And then you will see: Bisecting: 1288 revisions left to test after this (roughly 10 steps) Now build kernel and test, depending on if this build works or not, mark it as good or bad. Finally, a commit will be found as the 1st commit to cause this problem. A link to git-bisect: http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search Thanks. OK I made a bisect, bat I`m a little bit confused. I made a bisect between 3.3.8 and 3.4-rc1 one month ago and the result was same as here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1094800. The first bad commit was b74f05d61b73af584d0c39121980171389ecfaaa. But now when I made a bisect between 3.3 and 3.4 the first bad commit is ad50c15919e8aca7ea30f9dcf4bac52448c9ab46, but there is nothing important, only maintainer change. Thanks for the bisect, but I have a question: I don't think it is possible to bisect from 3.3.8 to 3.4-rc1, as in Linus' tree, there is no 3.3.8 tag, only Greg's stable tree has, but you are not supposed to mix the two trees I think. Did you do the bisect using the steps as listed in comment #9? Yes I did. Twice. Bisect between 3.3.8 to 3.4-rc1 was made from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git. Now I made bisect from http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git as you wrote. Here is my bisect log: # bad: [76e10d158efb6d4516018846f60c2ab5501900bc] Linux 3.4 # good: [dba69d1092e291e257fb5673a3ad0e4c87878ebc] x86, kvm: Call restore_sched_clock_state() only after %gs is initialized git bisect start 'v3.4' 'dba69d1092e291e257fb5673a3ad0e4c87878ebc' # bad: [ecca5c3acc0d0933d89abc44e60afb0cc8170e35] Merge branch 'akpm' (Andrew's patch-bomb) git bisect bad ecca5c3acc0d0933d89abc44e60afb0cc8170e35 # bad: [54229ff359250ce7292dbeb59f157a2d3b67e30c] arch/tile: fix finv_buffer_remote() for tilegx git bisect bad 54229ff359250ce7292dbeb59f157a2d3b67e30c # bad: [c39e8ede284f469971589f2e04af78216e1a771d] Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect bad c39e8ede284f469971589f2e04af78216e1a771d # bad: [a9d38a4f2da6c49a257253a9fdef7a6bcb0e0e4f] Merge branch 'dunlap' (Randy's Documentation patches) git bisect bad a9d38a4f2da6c49a257253a9fdef7a6bcb0e0e4f # good: [66c2689226ac322fbc9acd2e8e418b78dcd52f51] Btrfs: do not bother to defrag an extent if it is a big real extent git bisect good 66c2689226ac322fbc9acd2e8e418b78dcd52f51 # good: [b7e68d6876dfbab087bc3859211a9efc74cbe30c] sh: Support I/O space swapping where needed. git bisect good b7e68d6876dfbab087bc3859211a9efc74cbe30c # bad: [307cc7904841fd66a848ece16a179b49ae1a4ba4] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc git bisect bad 307cc7904841fd66a848ece16a179b49ae1a4ba4 # good: [16bf288c4be67b68c3fcb6561ff145702cb7bd22] Input: wacom - create inputs when wireless connect git bisect good 16bf288c4be67b68c3fcb6561ff145702cb7bd22 # good: [f182394033d639679264d61e6dca62761e659ff7] Input: wacom - check for allocation failure in probe() git bisect good f182394033d639679264d61e6dca62761e659ff7 # bad: [2f7fa1be66dce77608330c5eb918d6360b5525f2] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input git bisect bad 2f7fa1be66dce77608330c5eb918d6360b5525f2 # bad: [8f121918f2e49f852de1acdc5255cc1ef440d85b] cgroup: cgroup_attach_task() could return -errno after success git bisect bad 8f121918f2e49f852de1acdc5255cc1ef440d85b # bad: [ad50c15919e8aca7ea30f9dcf4bac52448c9ab46] cgroup: update MAINTAINERS entry git bisect bad ad50c15919e8aca7ea30f9dcf4bac52448c9ab46 I really think it is same bug as here: https://bugzilla.kernel.org/show_bug.cgi?id=54181, because before I upgrade bios to version 6.40 and then 6.50 everything works fine. Mark the problem as a duplicate of bug 54181 according to https://bugzilla.kernel.org/show_bug.cgi?id=54181#c32 Comment #32 From kk1 2013-04-25 08:21:06 (-) [reply] Private I confirm, that the patch solved problem with second suspend for me on notebook Toshiba Tecra R950. I tested kernel 3.9-rc8 with applied patch. Second suspend problem still occurs on kernel 3.9-rc8 without patch. *** This bug has been marked as a duplicate of bug 54181 *** |