https://bugzilla.kernel.org/show_bug.cgi?id=103211
--- Comment #3 from Aaron Lu <[email protected]> --- (In reply to Justin Dray from comment #2) > Thanks, I went from the top down, and this is what I've observed: > > # echo reboot > /sys/power/disk > # echo disk > /sys/power/state > worked; it hibernated, rebooted and went straight back to the terminal in > ~6-7 seconds as expected. Doing it a second time however, gave me a black > unresponsive screen (with the keyboard backlight still on; this silly model > has no power light). Forcing it to power off after a minute at this black > screen and then powering it on, it resumed from hibernate! Doing this test a This suggests that everything worked well, except the reboot. > couple more times resulting in random instability. Even after only a single > suspend, sometimes it would hang a short time after coming back from > hibernation (30-60 seconds) dmesg at this point would be useful, i.e. after the 1st time resume, before it hang. > > # echo platform > /sys/power/disk > # echo disk > /sys/power/state > Without pm_test set to core: Hangs when it should have rebooted. Keyboard The mode is set to platform, so it should power off instead of reboot. Anyway, it again means the system is not able to power off under Linux. > backlight stays on and the display is blank. Holding in power for 5 seconds > to shut down and then powering it back on resumes from where it was. Doing Again, this means everything worked well except the power off. > this a second time resulted in it sitting at the prompt without returning > from the 'echo disk' command for about 30-40 seconds. Then it had the same > outcome as the first time I ran it. Seems something is broken here. And by "the same outcome as the first time I ran it", do you mean it returned back to normal state? > > When I set pm_test to core for each of the above, they both appeared to > work. But with a very high (read all except one time) chance of it locking > up completely after 60 seconds. I think this may have to do with the dmesg before it completely lock up would be useful. > brcmfmac driver. removing the brcmfmac module before doing the tests left it > stable for some time. reloading the brcmfmac driver later resulted in it not > finding any wifi networks. But there is a seperate bug for brcmfmac issues: > https://bugzilla.kernel.org/show_bug.cgi?id=103201 Can you please redo all these suspend/resume tests with this wifi driver removed/unloaded? i.e. do not build the driver or make sure it's not loaded before you attempt any of these tests. > > Logs (with pm_test set to core): > reboot mode: https://gist.github.com/justin8/eef75db997219001a1e6 > platform mode: https://gist.github.com/justin8/524547161e2e42d440f9 -- You are receiving this mail because: You are watching the assignee of the bug. ------------------------------------------------------------------------------ _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
