From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423433AbdDUSJM (ORCPT ); Fri, 21 Apr 2017 14:09:12 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:34212 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161274AbdDUSJG (ORCPT ); Fri, 21 Apr 2017 14:09:06 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 3AF05607A7 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=tbaicar@codeaurora.org Subject: Re: [PATCH V15 03/11] cper: add timestamp print to CPER status printing To: Borislav Petkov Cc: christoffer.dall@linaro.org, marc.zyngier@arm.com, pbonzini@redhat.com, rkrcmar@redhat.com, linux@armlinux.org.uk, catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net, lenb@kernel.org, matt@codeblueprint.co.uk, robert.moore@intel.com, lv.zheng@intel.com, nkaje@codeaurora.org, zjzhang@codeaurora.org, mark.rutland@arm.com, james.morse@arm.com, akpm@linux-foundation.org, eun.taik.lee@samsung.com, sandeepa.s.prabhu@gmail.com, labbott@redhat.com, shijie.huang@arm.com, rruigrok@codeaurora.org, paul.gortmaker@windriver.com, tn@semihalf.com, fu.wei@linaro.org, rostedt@goodmis.org, bristot@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-efi@vger.kernel.org, Suzuki.Poulose@arm.com, punit.agrawal@arm.com, astone@redhat.com, harba@codeaurora.org, hanjun.guo@linaro.org, john.garry@huawei.com, shiju.jose@huawei.com, joe@perches.com, rafael@kernel.org, tony.luck@intel.com, gengdongjiu@huawei.com, xiexiuqi@huawei.com References: <1492556723-9189-1-git-send-email-tbaicar@codeaurora.org> <1492556723-9189-4-git-send-email-tbaicar@codeaurora.org> <20170421122150.76cce2cfrt767glv@pd.tnic> <35cc4ae0-e8fa-fd3a-5d7f-243ed2e82ea0@codeaurora.org> <20170421172603.4574wonnm5tgvbcn@pd.tnic> From: "Baicar, Tyler" Message-ID: Date: Fri, 21 Apr 2017 12:08:43 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <20170421172603.4574wonnm5tgvbcn@pd.tnic> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/21/2017 11:26 AM, Borislav Petkov wrote: > On Fri, Apr 21, 2017 at 10:04:35AM -0600, Baicar, Tyler wrote: >> This is basically what I already had in v14...you asked to move it into a >> different if-statement? https://lkml.org/lkml/2017/4/12/397 > Well, clearly I've been smoking some nasty potent sh*t. :-\ > > /me goes and looks at the spec: > > "Bit 0 – Timestamp is precise if this bit is set and correlates to the > time of the error event." > > So why are we even printing the timestamp when !precise? > > IOW, I think we should do: > > if (!(timestamp[3] & 0x1)) > printk("%stimestamp imprecise\n", pfx); > else { > sec = .. > min = ... > > ... > } > > and print the actual values only when the timestamp is precise. > Otherwise it has *some* values which could just as well be completely > random. And it's not like we're reporting the error tomorrow - it is > mostly a couple of seconds from logging to the fw pushing it out... The timestamp may still be useful when it is imprecise. In the polling case, you may only poll every minute or so, so the time may be useful. Also, I imagine there could be interrupt based errors happening much faster than the FW/OS handshake can happen. Maybe we can just use what I had before but also specify imprecise so that it is clear: printk("%s%ststamp: %02d%02d-%02d-%02d %02d:%02d:%02d\n", pfx, (timestamp[3] & 0x1 ? "precise " : "imprecise "), century, year, mon, day, hour, min, sec); Thanks, Tyler -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.