From patchwork Thu Oct 15 13:36:17 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?C=C3=A9dric_Le_Goater?= X-Patchwork-Id: 530706 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 573E5140157 for ; Fri, 16 Oct 2015 00:36:42 +1100 (AEDT) Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4331C1A06B9 for ; Fri, 16 Oct 2015 00:36:42 +1100 (AEDT) X-Original-To: skiboot@lists.ozlabs.org Delivered-To: skiboot@lists.ozlabs.org Received: from e06smtp17.uk.ibm.com (e06smtp17.uk.ibm.com [195.75.94.113]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id C930D1A0688 for ; Fri, 16 Oct 2015 00:36:37 +1100 (AEDT) Received: from localhost by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Oct 2015 14:36:33 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp17.uk.ibm.com (192.168.101.147) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 15 Oct 2015 14:36:32 +0100 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: clg@fr.ibm.com X-IBM-RcptTo: skiboot@lists.ozlabs.org Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 3092E1B08070 for ; Thu, 15 Oct 2015 14:36:37 +0100 (BST) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t9FDaVfv39845930 for ; Thu, 15 Oct 2015 13:36:31 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t9FCaWIa018272 for ; Thu, 15 Oct 2015 06:36:32 -0600 Received: from hermes.lab.toulouse-stg.fr.ibm.com (hermes.lab.toulouse-stg.fr.ibm.com [9.101.4.42]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t9FCaOKN017852; Thu, 15 Oct 2015 06:36:27 -0600 From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= To: skiboot@lists.ozlabs.org Date: Thu, 15 Oct 2015 15:36:17 +0200 Message-Id: <1444916177-23904-1-git-send-email-clg@fr.ibm.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15101513-0029-0000-0000-000008A4F661 Subject: [Skiboot] [PATCH v2] fsp/rtc: ignore TOD_RESET status X-BeenThere: skiboot@lists.ozlabs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Mailing list for skiboot development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: skiboot-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Skiboot" When the timeofday is considered INVALID by the FSP : System time is INVALID: 2015/10/14 20:13:53.305261 it will return a FSP_STATUS_TOD_RESET (0xA9) to any TOD read request done by OPAL. This status stays invalid until a write request is done. This is a problem for the kernel as the OPAL_RTC_READ calls are done in loops. The consequence is that the skiroot kernel hangs quite early in the boot looping on : [9163642153,3] RTC TOD in invalid state [9186642687,3] RTC TOD in invalid state [9204379669,3] RTC TOD in invalid state [9226043775,3] RTC TOD in invalid state [9240944791,3] RTC TOD in invalid state with other unpleasant consequences following. The system is left unusable and it is difficult for the user to know what is happening. This patch modifies the behavior of the read request when an invalid status is received. It simply ignores it and considers the read as successful. This breaks the loops done in the kernel on OPAL_RTC_READ calls and lets the boot complete. The status is expected to become valid after the first TOD write request. Signed-off-by: Cédric Le Goater --- Tested on failing system with skiboot-5.1.7 Changes since v1: - simply log the status and ignore it instead of keeping a permanent error on the TOD hw/fsp/fsp-rtc.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) Index: skiboot.git/hw/fsp/fsp-rtc.c =================================================================== --- skiboot.git.orig/hw/fsp/fsp-rtc.c +++ skiboot.git/hw/fsp/fsp-rtc.c @@ -169,13 +169,6 @@ static void fsp_rtc_process_read(struct assert(rtc_read_request_state == RTC_READ_PENDING_REQUEST); switch (val) { - case FSP_STATUS_TOD_RESET: - log_simple_error(&e_info(OPAL_RC_RTC_TOD), - "RTC TOD in invalid state\n"); - rtc_tod_state = RTC_TOD_INVALID; - rtc_read_request_state = RTC_READ_NO_REQUEST; - break; - case FSP_STATUS_TOD_PERMANENT_ERROR: log_simple_error(&e_info(OPAL_RC_RTC_TOD), "RTC TOD in permanent error state\n"); @@ -183,6 +176,17 @@ static void fsp_rtc_process_read(struct rtc_read_request_state = RTC_READ_NO_REQUEST; break; + case FSP_STATUS_TOD_RESET: + prerror("RTC TOD in invalid state\n"); + /* + * The RESET status indicates that the TOD was + * powered up with an invalid state, which will be + * cleared by the first write request. + * + * As this is a rare scenario, let's pretend the read + * request is a success and let the first write + * request clear the status. + */ case FSP_STATUS_SUCCESS: /* Save the read RTC value in our cache */ rtc_read_request_state = RTC_READ_REQUEST_AVAILABLE;