kexec February 2017

kexec@lists.fedoraproject.org

3 participants
6 discussions

[PATCH rhel7.4] Document: fix incorrect link in fadump-how.txt
by Pingfan Liu 01 Mar '17

01 Mar '17

The file fadump-howto.txt has an incorrect link for further information about sysrq usage. Fix it. Signed-off-by: Pingfan Liu <piliu(a)redhat.com> --- fadump-howto.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fadump-howto.txt b/fadump-howto.txt index cfde878..1613d02 100644 --- a/fadump-howto.txt +++ b/fadump-howto.txt @@ -163,7 +163,7 @@ on your system, with the scripts enabled as described in the section above. FAdump can be triggered with the combination of the 'Alt','SysRq' and 'C' keyboard keys. Please refer to the following link for more details: -http://kbase.redhat.com/faq/FAQ_43_5559.shtm +https://access.redhat.com/articles/231663 In addition, on PowerPC boxes, fadump can also be triggered via Hardware Management Console(HMC) using 'Ctrl', 'O' and 'C' keyboard keys. -- 1.8.3.1

2 3

[PATCH] kdump-lib.sh: fix incorrect usage with pipe as input for grep -q in is_pcs_fence_kdump()
by Pingfan Liu 01 Mar '17

01 Mar '17

For -q option, as man grep says: Exit immediately with zero status if any match is found, even if an error was detected. So when matching, the read side of pipe is closed by "grep -q", while the write side still try to write more data, which cause SIGPIPE to the process, and the shell can not exit with 0. It depends on the kernel's implementation of pipe to decide how much data written by the producer can trigger the bug. Bash test script: #!/bin/sh set -o pipefail dd if=/dev/zero of=text.file bs=1M count=1 sed -i '1s/^/keyword /' text.file cat text.file | grep -q keyword echo $? Notice the "set -o pipefail" is set by dracut, so mkdumprd -> dracut -> dracut-module-setup.sh -> is_pcs_fence_kdump() trigger the bug. Signed-off-by: Pingfan Liu <piliu(a)redhat.com> --- kdump-lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kdump-lib.sh b/kdump-lib.sh index e3b5a01..8ebad70 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -63,7 +63,7 @@ is_pcs_fence_kdump() [ -x $FENCE_KDUMP_SEND ] || return 1 # fence kdump not configured? - (pcs cluster cib | grep -q 'type="fence_kdump"') &> /dev/null || return 1 + (pcs cluster cib | grep 'type="fence_kdump"') &> /dev/null || return 1 } # Check if fence_kdump is configured using kdump options -- 2.7.4

3 3

Re: [PATCH RFC] memtrace: Trace peak memory allocation of task and kernel module
by Pratyush Anand 28 Feb '17

28 Feb '17

On Tuesday 28 February 2017 02:46 AM, Steven Rostedt wrote: > On Mon, 27 Feb 2017 21:52:11 +0530 > Pratyush Anand <panand(a)redhat.com> wrote: > >> Hi Steve, >> >> On Tuesday 21 February 2017 12:17 AM, Steven Rostedt wrote: >>>> Can you please help me with some pointer so that I can parse them >>>> correctly. >>> Take a look at the latest kbuffer-parse.c and kbuffer.h. That's the >>> code that does the parsing. You should be able to use that code >>> directly and simply just use those functions instead of having to parse >>> it yourself. >>> >>> >> >> Thanks for the pointer. It was helpful. >> >> I have added an option in trace-cmd itself which can help to detect >> *approximate* peak memory.Not sure on which mailing list I can send the >> RFC for trace-cmd. BTW my rough patch is here. Before it can be >> polished, an early feedback would be helpful. >> >> https://github.com/pratyushanand/trace-cmd/commit/d3710da68f8eecf4d99a1c49c… >> > > Feel free to just post it ;-) I think having code polished in the open > is always the best. Yes,yes..I wasn't just sure that which mailing list should I use. OK, I will use same mailing list and cc list as of this patch. > > Anyway, the few things that I will have you change is the changing of > static to global. There may be functions that are already global that > you can use. Or at least, we should change the names. The OK. > "host_is_big_endian" can be derived from the pevent. I'm assuming that > you'll require creating a pevent. HUmm..tracecmd_alloc_fd() populates pevent->host_bigendian. However, this code does not work on a trace data acquired in a file, rather it works on live streamed trace buffer. So tracecmd_alloc_fd() will not be called. However, I can use tracecmd_host_bigendian() from trace-cmd.h. Anyway, let me post the patch and we can discuss it over there. Thanks for your time. ~Pratyush

1 0

Re: [PATCH RFC] memtrace: Trace peak memory allocation of task and kernel module
by Pratyush Anand 27 Feb '17

27 Feb '17

Hi Steve, On Tuesday 21 February 2017 12:17 AM, Steven Rostedt wrote: >> Can you please help me with some pointer so that I can parse them >> correctly. > Take a look at the latest kbuffer-parse.c and kbuffer.h. That's the > code that does the parsing. You should be able to use that code > directly and simply just use those functions instead of having to parse > it yourself. > > Thanks for the pointer. It was helpful. I have added an option in trace-cmd itself which can help to detect *approximate* peak memory.Not sure on which mailing list I can send the RFC for trace-cmd. BTW my rough patch is here. Before it can be polished, an early feedback would be helpful. https://github.com/pratyushanand/trace-cmd/commit/d3710da68f8eecf4d99a1c49c… ~Pratyush

1 0

Re: [PATCH RFC] memtrace: Trace peak memory allocation of task and kernel module
by Pratyush Anand 20 Feb '17

20 Feb '17

Hi Steve, On Friday 09 December 2016 09:11 AM, Steven Rostedt wrote: > On Fri, 9 Dec 2016 10:08:35 +0800 > Dave Young <dyoung(a)redhat.com> wrote: > >> Ccing Steven, see if he has some comments about the design. > Thanks! > > [snip] > >>> +int main(int argc, char *argv[]) >>> +{ >>> + char trace_dir[64]; >>> + struct sigaction sterm, sprint; >>> + pthread_t tid; >>> + int i; >>> + >>> + if (argc >= 2 && strlen(argv[1]) < 64) >>> + strcpy(trace_dir, argv[1]); >>> + else >>> + strcpy(trace_dir, "/sys/kernel/debug/tracing/"); >>> + >>> + if (argc >= 3 && strlen(argv[2]) < 64) >>> + strcpy(trace_info.log_path, argv[2]); >>> + else >>> + strcpy(trace_info.log_path, DEFAULT_LOG_PATH); >>> + strcpy(trace_info.trace_path, trace_dir); >>> + strcat(trace_info.trace_path, "trace_pipe"); > Please don't parse the text files. Can you open up the per_cpu > trace_pipe_raw instead. I stated playing with trace_pipe_raw. But, I am a bit confused with lack of documentation around the format of ring buffer raw data (I tried to look through kenrel/trace-cmd code, and may be I am not looking at the right section of code, probably you can help here with some pointers). This is what I understood: Every page of data will have: - 8 bytes of timestamp - 4/8 bytes (long) of flags+size - size bytes of data - 4/8 bytes of lost_events Now coming to data, it will have: - 4 bytes of type_len + time_delta - If type is padding, then next 4 bytes pad length - if type is time_extend, then next 4 bytes about extend info - if it is time_stamp, next 12 byes is time_stamp info - if it is 0, next 4 bytes is length of data - else data length is type_len * 4. and data should be as per format specified in events/system/subsystem/format. For sure there is something wrong with above understanding, because it does not map to the data I am getting. I got first few bytes of a page data like following (event id which was enabled: mm_page_free = 0x1be) 15 df e7 60 b ba 0 0 e4 f 0 c0 ff ff ff ff 6 0 0 0 be 1 0 0 6a 6b 0 0 36 a3 22 0 0 0 0 0 0 0 0 0 ca 80 42 2 e6 18 0 0 be 1 0 0 6a 6b 0 0 82 1c 20 So here: time stamp -> 15 df e7 60 b ba 0 0 flags+size -> e4 f 0 c0 ff ff ff ff (so size if 0xfe4, which seems correct) type_len_ts -> 6 0 0 0 type_len = 0x6 there fore data length should be 24 data -> be 1 0 0 6a 6b 0 0 36 a3 22 0 0 0 0 0 0 0 0 0 ca 80 42 2 So, it seems to be of mm_page_free, but they are not matching completely with the format specified in events/kmem/mm_page_free/format. So, whats missing? Next type_len_ts -> e6 18 0 0 This also not seems correct type_len_ts, so I missed something and I am at wrong offset. Can you please help me with some pointer so that I can parse them correctly. Thanks ~Pratyush PS: # cat /sys/kernel/debug/tracing/events/kmem/mm_page_free/format name: mm_page_free ID: 446 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:unsigned long pfn; offset:8; size:8; signed:0; field:unsigned int order; offset:16; size:4; signed:0; print fmt: "page=%p pfn=%lu order=%d", (((struct page *)vmemmap_base) + (REC->pfn)), REC->pfn, REC->order

1 0

[f25 PATCH 0/4] patchset to correct the usage of "grep -q"
by Pingfan Liu 08 Feb '17

08 Feb '17

The same issue, but arrange the fix in each separated file Pingfan Liu (4): kdump-lib.sh: fix incorrect usage with pipe as input for grep -q dracut-module-setup.sh: fix incorrect usage with pipe as input for grep -q kdumpctl: fix incorrect usage with pipe as input for grep -q dracut-kdump.sh: fix incorrect usage with pipe as input for grep -q dracut-kdump.sh | 2 +- dracut-module-setup.sh | 4 ++-- kdump-lib.sh | 12 ++++++------ kdumpctl | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) -- 2.7.4

3 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

kexec February 2017