From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752047AbdHHBak (ORCPT ); Mon, 7 Aug 2017 21:30:40 -0400 Received: from conssluserg-06.nifty.com ([210.131.2.91]:40109 "EHLO conssluserg-06.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751950AbdHHBai (ORCPT ); Mon, 7 Aug 2017 21:30:38 -0400 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com v781UWUc027265 X-Nifty-SrcIP: [209.85.161.171] MIME-Version: 1.0 In-Reply-To: <93b9efde-397d-d7bb-787d-c28ff754b6a5@arm.com> References: <4d6b511a-61d5-3c5e-a406-9f71d83670b6@linux.intel.com> <1d2c51f3-a655-2223-68a9-e6d700e7d8e1@intel.com> <412a3ab0-4ae5-b27a-0b2d-d2e03b27a999@intel.com> <93b9efde-397d-d7bb-787d-c28ff754b6a5@arm.com> From: Masahiro Yamada Date: Tue, 8 Aug 2017 10:30:31 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Suspend-resume failure on Intel Eagle Lake Core2Duo To: Marc Zyngier Cc: Thomas Gleixner , Tomi Sarvela , Martin Peres , Jeffy Chen , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, 2017-08-07 17:17 GMT+09:00 Marc Zyngier : > On 07/08/17 05:45, Masahiro Yamada wrote: >> Hi Marc, >> >> >> 2017-08-03 22:30 GMT+09:00 Marc Zyngier : >>> On 03/08/17 13:52, Masahiro Yamada wrote: >>>> Hi Marc, >>>> >>>> 2017-08-03 17:41 GMT+09:00 Marc Zyngier : >>>>> Hi Masahiro, >>>>> >>>>> On 03/08/17 08:32, Masahiro Yamada wrote: >>>>>> Hi. >>>>>> >>>>>> 2017-08-01 0:55 GMT+09:00 Thomas Gleixner : >>>>>>> On Mon, 31 Jul 2017, Tomi Sarvela wrote: >>>>>>>> On 31/07/17 18:06, Thomas Gleixner wrote: >>>>>>>>> Can you please remove the patch. And try the following: >>>>>>>>> >>>>>>>>> # echo N > /sys/module/printk/parameters/console_suspend >>>>>>>>> >>>>>>>>> # echo mem > /sys/power/state >>>>>>>>> >>>>>>>>> and log the output of the serial console. That way we might get a clue >>>>>>>>> where it gets stuck. >>>>>>>> >>>>>>>> I'm afraid it hangs right away. No response from SSH, no output to serial. >>>>>>> >>>>>>> What means hangs right away? Is there no output at all on the serial >>>>>>> console? Or does it just stop at some point? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> tglx >>>>>>> >>>>>> >>>>>> Sorry for jumping in. >>>>>> Finally, I found this thread. >>>>>> >>>>>> >>>>>> My environment is completely different (ARM64 board), >>>>>> I am also suffering from a hibernation problem >>>>>> since this commit. >>>>>> >>>>>> >>>>>> I get no response on the serial console >>>>>> after "Restarting tasks ... done." log message. >>>>>> >>>>>> >>>>>> By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level >>>>>> irq function calls", I can get hibernation working again. >>>>>> >>>>>> >>>>>> SW info: >>>>>> defconfig: arch/arm64/configs/defconfig >>>>>> DT : arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts >>>>>> PSCI : ARM Trusted Firmware >>>>>> >>>>>> >>>>>> SoC info: >>>>>> CPU : Cortex-A72 * 2 + Cortex-A53 * 2 >>>>>> irqchip : GICv3 (drivers/irq/irq-gic-v3.c) >>>>> >>>>> Let me take an educated guess: It feels like your firmware doesn't >>>>> save/restore the GIC context across suspend/resume. Is that something >>>>> you could check, assuming you have access to the firmware source code? >>>> >>>> Thanks for your comments. >>>> >>>> >>>> I do not know much about the manner of preserving GICv3 context. >>>> >>>> I can see this patch (rejected?) : >>>> https://patchwork.kernel.org/patch/9343061/ >>>> >>>> >>>> Is it something that should be completely cared by firmware >>>> instead of kernel? >>> >>> That was definitely the intention, but it looks like something that ATF >>> has only started supporting very recently: >>> >>> https://github.com/ARM-software/arm-trusted-firmware/pull/1047 >>> >>>> ARM Trusted Firmware (https://github.com/ARM-software/arm-trusted-firmware) >>>> is open source software, and I pushed my platform code to the upstream. >>>> >>>> So, yes, I (and everybody) can have access to the firmware source code. >>>> >>>> >>>> I am not sure how ATF saves the context during hibernation, though. >>> >>> See the above link. Is there any chance of you trying this into your >>> firmware? >>> >>> Thanks, >> >> Thanks for the pointer. >> >> >> Yes. I will try that once GIC-v3 context save/restore is supported in ATF. >> >> I think that will basically work for suspend-to-ram >> because all contexts including both non-secure and secure worlds will >> be retained in the main memory. >> >> However, I still do not understand how the context is preserved during >> the hibernation (suspend-to-disk). >> >> >> If my understanding is correct, hibernation on Linux works like follows: >> >> [1] Freeze all tasks >> [2] CPU_OFF for non-boot CPUs >> [3] Create a hibernation image >> [4] CPU_ON for non-boot CPUs >> [5] Write the hibernation image to the disk (=swap area) >> [6] SYSTEM_OFF >> >> >> IIUC, [5] only writes the context Linux takes care of (only non-secure). >> >> If so, where and how does the firmware write the GIC-v3 context >> to the disk? > > Gah, I completely missed the fact that you were talking about suspend to > disk, sorry about that. > > It is likely that some driver doesn't restore its state properly. Is > there any chance that you could pinpoint which device creates the issue? > I use eMMC to store the hibernation image, but I do not think eMMC driver is the cause of the issue. I guess the cause of the issue is GIC-v3 context is lost. I am not an expert in this, so I will ask the ATF community about how ATF can support suspend-to-disk. -- Best Regards Masahiro Yamada