Linux-EDAC Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] trace: ras: print the raw data of arm processor error info
@ 2019-12-14 12:11 Xie XiuQi
  2019-12-16 10:17 ` Denverton decoding: BIOS performance setting Hermann Ruckerbauer
  2020-01-09 11:46 ` [PATCH] trace: ras: print the raw data of arm processor error info Borislav Petkov
  0 siblings, 2 replies; 5+ messages in thread
From: Xie XiuQi @ 2019-12-14 12:11 UTC (permalink / raw)
  To: tony.luck, bp; +Cc: linux-edac, linux-kernel

User space tools such as rasdaemon need the complete error
information from trace event. So, we print the raw data of
error information in arm_event.

In the past, I try to parse them in trace event, but it's
hard to deal the dynamic error item. And in commit 301f55b1a917
("efi: Parse ARM error information value"), the error information
already been parsed to syslog.

So, just print the raw data in trace event for simpler.

Cc: Borislav Petkov <bp@suse.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tyler Baicar <tbaicar@codeaurora.org>
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
---
 include/ras/ras_event.h | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 36c5c5e38c1d..2023ba9206b3 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -180,6 +180,9 @@ TRACE_EVENT(arm_event,
 		__field(u32, running_state)
 		__field(u32, psci_state)
 		__field(u8, affinity)
+		__field(u32, count)
+		__field(u32, len)
+		__dynamic_array(u8, err_info, proc->err_info_num * sizeof(struct cper_arm_err_info))
 	),
 
 	TP_fast_assign(
@@ -199,12 +202,18 @@ TRACE_EVENT(arm_event,
 			__entry->running_state = ~0;
 			__entry->psci_state = ~0;
 		}
+
+		__entry->count = proc->err_info_num;
+		__entry->len = __entry->count * sizeof(struct cper_arm_err_info);
+		memcpy(__get_dynamic_array(err_info), proc + 1, __entry->len);
 	),
 
 	TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
-		  "running state: %d; PSCI state: %d",
+		  "running state: %d; PSCI state: %d; error count: %d; "
+		  "raw data: %s",
 		  __entry->affinity, __entry->mpidr, __entry->midr,
-		  __entry->running_state, __entry->psci_state)
+		  __entry->running_state, __entry->psci_state, __entry->count,
+		  __print_hex(__get_dynamic_array(err_info), __entry->len))
 );
 
 /*
-- 
2.20.1


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Denverton decoding: BIOS performance setting
  2019-12-14 12:11 [PATCH] trace: ras: print the raw data of arm processor error info Xie XiuQi
@ 2019-12-16 10:17 ` Hermann Ruckerbauer
  2020-01-09 11:46 ` [PATCH] trace: ras: print the raw data of arm processor error info Borislav Petkov
  1 sibling, 0 replies; 5+ messages in thread
From: Hermann Ruckerbauer @ 2019-12-16 10:17 UTC (permalink / raw)
  To: tony.luck; +Cc: linux-edac, linux-kernel

Hello,

not sure if this is a bit off topic, but I hope to get some answers ...

I looked to the Apollo lake pnd2_edac.c  code, my understandig is, that
this is the same as for denverton.
but in our BIOS is see one point in the memory settings called
"Performance profile"
Selectable is "17_9_13_18", "17_19_6_18" or "17_19_6_7"
This setting seems to be realated to the DMAP table... but for APL there
are just the "standard" configs visible.

Does anybody know if these DMAP settings are different in Denverton vs.
Apollo lake, and how these are decoded in the PND2_edac.c cource code ?
at least I have not found any hint on this performance setting in the
code..

Thanks a lot

-- 

EKH - EyeKnowHow 
Signal Quality - Made in Bavaria
Hermann Ruckerbauer
www.EyeKnowHow.de
Hermann.Ruckerbauer@EyeKnowHow.de
Itzlinger Strasse 21a
94469 Deggendorf
Tel.:	+49 (0)991 / 29 69 29 05
Mobile:	+49 (0)176  / 787 787 77
Fax:	+49 (0)3212 / 121 9008


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] trace: ras: print the raw data of arm processor error info
  2019-12-14 12:11 [PATCH] trace: ras: print the raw data of arm processor error info Xie XiuQi
  2019-12-16 10:17 ` Denverton decoding: BIOS performance setting Hermann Ruckerbauer
@ 2020-01-09 11:46 ` Borislav Petkov
  2020-01-13 14:10   ` Xie XiuQi
  1 sibling, 1 reply; 5+ messages in thread
From: Borislav Petkov @ 2020-01-09 11:46 UTC (permalink / raw)
  To: Xie XiuQi, James Morse
  Cc: tony.luck, linux-edac, linux-kernel, linux-arm-kernel

On Sat, Dec 14, 2019 at 08:11:09PM +0800, Xie XiuQi wrote:
> User space tools such as rasdaemon need the complete error
> information from trace event. So, we print the raw data of
> error information in arm_event.
> 
> In the past, I try to parse them in trace event, but it's
> hard to deal the dynamic error item. And in commit 301f55b1a917
> ("efi: Parse ARM error information value"), the error information
> already been parsed to syslog.
> 
> So, just print the raw data in trace event for simpler.
> 
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
> ---
>  include/ras/ras_event.h | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
> index 36c5c5e38c1d..2023ba9206b3 100644
> --- a/include/ras/ras_event.h
> +++ b/include/ras/ras_event.h
> @@ -180,6 +180,9 @@ TRACE_EVENT(arm_event,
>  		__field(u32, running_state)
>  		__field(u32, psci_state)
>  		__field(u8, affinity)
> +		__field(u32, count)
> +		__field(u32, len)
> +		__dynamic_array(u8, err_info, proc->err_info_num * sizeof(struct cper_arm_err_info))
>  	),
>  
>  	TP_fast_assign(
> @@ -199,12 +202,18 @@ TRACE_EVENT(arm_event,
>  			__entry->running_state = ~0;
>  			__entry->psci_state = ~0;
>  		}
> +
> +		__entry->count = proc->err_info_num;
> +		__entry->len = __entry->count * sizeof(struct cper_arm_err_info);
> +		memcpy(__get_dynamic_array(err_info), proc + 1, __entry->len);
>  	),
>  
>  	TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
> -		  "running state: %d; PSCI state: %d",
> +		  "running state: %d; PSCI state: %d; error count: %d; "
> +		  "raw data: %s",
>  		  __entry->affinity, __entry->mpidr, __entry->midr,
> -		  __entry->running_state, __entry->psci_state)
> +		  __entry->running_state, __entry->psci_state, __entry->count,
> +		  __print_hex(__get_dynamic_array(err_info), __entry->len))
>  );
>  
>  /*
> -- 

That's for ARM folks to decide whether they wanna shuffle raw error
records into userspace like that. CCed.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] trace: ras: print the raw data of arm processor error info
  2020-01-09 11:46 ` [PATCH] trace: ras: print the raw data of arm processor error info Borislav Petkov
@ 2020-01-13 14:10   ` Xie XiuQi
  2020-02-26 15:14     ` James Morse
  0 siblings, 1 reply; 5+ messages in thread
From: Xie XiuQi @ 2020-01-13 14:10 UTC (permalink / raw)
  To: Borislav Petkov, James Morse
  Cc: tony.luck, linux-edac, linux-kernel, linux-arm-kernel

Hi James,

What do you think of this patch?

On 2020/1/9 19:46, Borislav Petkov wrote:
>>  );
>>  
>>  /*
>> -- 
> That's for ARM folks to decide whether they wanna shuffle raw error
> records into userspace like that. CCed.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] trace: ras: print the raw data of arm processor error info
  2020-01-13 14:10   ` Xie XiuQi
@ 2020-02-26 15:14     ` James Morse
  0 siblings, 0 replies; 5+ messages in thread
From: James Morse @ 2020-02-26 15:14 UTC (permalink / raw)
  To: Xie XiuQi
  Cc: Borislav Petkov, tony.luck, linux-edac, linux-kernel, linux-arm-kernel

Hi Xie,

On 13/01/2020 14:10, Xie XiuQi wrote:
> What do you think of this patch?
> 
> On 2020/1/9 19:46, Borislav Petkov wrote:
>>>  );
>>>  
>>>  /*

What patch?!

(digs in the headers)
https://lore.kernel.org/linux-edac/20191214121109.8349-1-xiexiuqi@huawei.com/

>>> -- 
>> That's for ARM folks to decide whether they wanna shuffle raw error
>> records into userspace like that. CCed.

Hmm, this dumps more of 'CPER_SEC_PROC_ARM' to user-space. But not all of it ... (ugh,
this is the thing with three variable length fields in it!) I would like to be able to
parse these in the kernel eventually, but that doesn't matter right now.

I agree privileged user-space should be able to collect all the CPER for some tool to
analyse it. (what else would we do with 'vendor specific error info'?). I'm not totally
convinced tracepoints are the right thing for big blobs of data like this, but its what
we're using today.


I'll show my ignorance about trace points:

How does rasdaemon react to you expanding the trace point like this? I recall they are
self-describing, if user-space doesn't hard code the layout...

You export what may be kernel pointers with the virtual fault address. Is there any way an
unprivileged user can get hold of these?
(its somewhat pointless as user-space can't know what that pointer means)



Thanks,

James

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-14 12:11 [PATCH] trace: ras: print the raw data of arm processor error info Xie XiuQi
2019-12-16 10:17 ` Denverton decoding: BIOS performance setting Hermann Ruckerbauer
2020-01-09 11:46 ` [PATCH] trace: ras: print the raw data of arm processor error info Borislav Petkov
2020-01-13 14:10   ` Xie XiuQi
2020-02-26 15:14     ` James Morse

Linux-EDAC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-edac/0 linux-edac/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-edac linux-edac/ https://lore.kernel.org/linux-edac \
		linux-edac@vger.kernel.org
	public-inbox-index linux-edac

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-edac


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git