From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751433AbdHGEpx (ORCPT ); Mon, 7 Aug 2017 00:45:53 -0400 Received: from conssluserg-02.nifty.com ([210.131.2.81]:63883 "EHLO conssluserg-02.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751411AbdHGEpw (ORCPT ); Mon, 7 Aug 2017 00:45:52 -0400 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com v774jjWZ031083 X-Nifty-SrcIP: [209.85.161.178] MIME-Version: 1.0 In-Reply-To: References: <4d6b511a-61d5-3c5e-a406-9f71d83670b6@linux.intel.com> <7287f845-1012-51af-e696-99d26bcb9b7f@intel.com> <1d2c51f3-a655-2223-68a9-e6d700e7d8e1@intel.com> <412a3ab0-4ae5-b27a-0b2d-d2e03b27a999@intel.com> From: Masahiro Yamada Date: Mon, 7 Aug 2017 13:45:44 +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-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? -- Best Regards Masahiro Yamada