[PATCH rhel7.4] Document: fix incorrect link in fadump-how.txt
by Pingfan Liu
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
6 years, 3 months
[PATCH] kdump-lib.sh: fix incorrect usage with pipe as input for grep -q in is_pcs_fence_kdump()
by Pingfan Liu
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
6 years, 3 months
Re: [PATCH RFC] memtrace: Trace peak memory allocation of task and
kernel module
by Pratyush Anand
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/d3710da68f8eecf4d99a1c4...
>>
>
> 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
6 years, 3 months
Re: [PATCH RFC] memtrace: Trace peak memory allocation of task and
kernel module
by Pratyush Anand
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/d3710da68f8eecf4d99a1c4...
~Pratyush
6 years, 3 months
Re: [PATCH RFC] memtrace: Trace peak memory allocation of task and
kernel module
by Pratyush Anand
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
6 years, 3 months
[f25 PATCH 0/4] patchset to correct the usage of "grep -q"
by Pingfan Liu
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
6 years, 3 months