[PATCH v2] mm/compaction: remove unused variable sysctl_compact_memory

. No functionality is broken or changed this way. Signed-off-by: Pintu Kumar Signed-off-by: Pintu Agarwal --- v2: completely get rid of this variable and set .data to NULL Suggested-by: Vlastimil Babka include/linux/compaction.h | 1 - kernel/sysctl.c| 2 +- mm/compaction.c

[PATCH] mm/compaction: remove unused variable sysctl_compact_memory

or changed this way. Signed-off-by: Pintu Kumar Signed-off-by: Pintu Agarwal --- include/linux/compaction.h | 1 - kernel/sysctl.c| 1 + mm/compaction.c| 3 --- 3 files changed, 1 insertion(+), 4 deletions(-) diff --git a/include/linux/compaction.h b/include/linux/compaction.h

[PATCH] mm: introduce clear all vm events counters

ode is filled with default or current value. There could be few other use cases where this can be useful. Signed-off-by: Pintu Kumar Signed-off-by: Pintu Agarwal --- Documentation/admin-guide/sysctl/vm.rst | 8 include/linux/vmstat.h | 7 +++ kernel/sysct

[PATCH] mm/util.c: Add error logs for commitment overflow

y: commitment overflow: ppid:150, pid:164, pages:62451 fork failed[count:0]: Cannot allocate memory Signed-off-by: Pintu Kumar --- mm/util.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/util.c b/mm/util.c index 5ef378a..9431ce7a 100644 --- a/mm/util.c +++ b/mm/util.c @@ -895,6

[PATCH] mm/slab.h: Fix duplicate include file kmemleak.h

As I was browsing through this code, I found that linux/kmemleak.h was declared twice. When I run ./scripts/checkincludes.pl it reported the same: mm/slab.h: linux/kmemleak.h is included more than once. Thus removing the last included header. Signed-off-by: Pintu Kumar --- mm/slab.h | 1 - 1

Re: KSM not working in 4.9 Kernel

can I interpret from this? And, what does it mean by: pages_volatile:1 ? Basically, I wanted to understand, is there any problem with the above output, or it is fine. If it is fine, how to prove it? Thanks, Pintu On Mon, Sep 17, 2018 at 8:29 PM Mike Rapoport wrote: > > On Mon, Sep 17, 2

Re: KSM not working in 4.9 Kernel

can I interpret from this? And, what does it mean by: pages_volatile:1 ? Basically, I wanted to understand, is there any problem with the above output, or it is fine. If it is fine, how to prove it? Thanks, Pintu On Mon, Sep 17, 2018 at 8:29 PM Mike Rapoport wrote: > > On Mon, Sep 17, 2

Re: KSM not working in 4.9 Kernel

On Mon, Sep 17, 2018 at 11:46 AM Pintu Kumar wrote: > > > But still no effect. > > > And I checked LTP test cases. It almost doing the same thing. > > > > > > I observed that [ksmd] thread is not waking up at all. > > > I gave some print inside

Re: KSM not working in 4.9 Kernel

On Mon, Sep 17, 2018 at 11:46 AM Pintu Kumar wrote: > > > But still no effect. > > > And I checked LTP test cases. It almost doing the same thing. > > > > > > I observed that [ksmd] thread is not waking up at all. > > > I gave some print inside

Re: KSM not working in 4.9 Kernel

On Mon, Sep 17, 2018 at 10:07 AM Mike Rapoport wrote: > > On Sun, Sep 16, 2018 at 10:35:17PM +0530, Pintu Kumar wrote: > > On Sun, Sep 16, 2018 at 9:02 PM Mike Rapoport > > wrote: > > > > > > On Fri, Sep 14, 2018 at 07:58:01PM +0530, Pintu Kumar wrote: &

Re: KSM not working in 4.9 Kernel

On Mon, Sep 17, 2018 at 10:07 AM Mike Rapoport wrote: > > On Sun, Sep 16, 2018 at 10:35:17PM +0530, Pintu Kumar wrote: > > On Sun, Sep 16, 2018 at 9:02 PM Mike Rapoport > > wrote: > > > > > > On Fri, Sep 14, 2018 at 07:58:01PM +0530, Pintu Kumar wrote: &

Re: KSM not working in 4.9 Kernel

On Sun, Sep 16, 2018 at 9:02 PM Mike Rapoport wrote: > > On Fri, Sep 14, 2018 at 07:58:01PM +0530, Pintu Kumar wrote: > > Hi All, > > > > Board: Hikey620 ARM64 > > Kernel: 4.9.20 > > > > I am trying to verify KSM (Kernel Same Page Merging) functionality

Re: KSM not working in 4.9 Kernel

On Sun, Sep 16, 2018 at 9:02 PM Mike Rapoport wrote: > > On Fri, Sep 14, 2018 at 07:58:01PM +0530, Pintu Kumar wrote: > > Hi All, > > > > Board: Hikey620 ARM64 > > Kernel: 4.9.20 > > > > I am trying to verify KSM (Kernel Same Page Merging) functionality

Re: KSM not working in 4.9 Kernel

On Fri, 14 Sep 2018, 10:42 pm Yang Shi, wrote: > > Hi Pintu, > > I recall there are some ksm test cases in LTP. Did you try them out? No. I haven't seen the LTP test. I will check out now. But I wonder what is the problem with my test? > On Fri, Sep 14, 2018 at 7:28 AM Pin

Re: KSM not working in 4.9 Kernel

On Fri, 14 Sep 2018, 10:42 pm Yang Shi, wrote: > > Hi Pintu, > > I recall there are some ksm test cases in LTP. Did you try them out? No. I haven't seen the LTP test. I will check out now. But I wonder what is the problem with my test? > On Fri, Sep 14, 2018 at 7:28 AM Pin

KSM not working in 4.9 Kernel

Hi All, Board: Hikey620 ARM64 Kernel: 4.9.20 I am trying to verify KSM (Kernel Same Page Merging) functionality on 4.9 Kernel using "mmap" and madvise user space test utility. But to my observation, it seems KSM is not working for me. CONFIG_KSM=y is enabled in kernel. ksm_init is also called

KSM not working in 4.9 Kernel

Hi All, Board: Hikey620 ARM64 Kernel: 4.9.20 I am trying to verify KSM (Kernel Same Page Merging) functionality on 4.9 Kernel using "mmap" and madvise user space test utility. But to my observation, it seems KSM is not working for me. CONFIG_KSM=y is enabled in kernel. ksm_init is also called

Re: [PREEMPT_RT]: Using printk-rt-aware.patch in non-rt kernel

On Thu, Jul 26, 2018 at 9:08 PM Sebastian Andrzej Siewior wrote: > > On 2018-07-18 20:19:15 [+0530], Pintu Kumar wrote: > > Hi All, > Hi, > > > I have a question about PREEMPT_RT patch for 3.10 kernel. > > I am trying to port this rt patch: 0224-printk-rt-aware.

Re: [PREEMPT_RT]: Using printk-rt-aware.patch in non-rt kernel

On Thu, Jul 26, 2018 at 9:08 PM Sebastian Andrzej Siewior wrote: > > On 2018-07-18 20:19:15 [+0530], Pintu Kumar wrote: > > Hi All, > Hi, > > > I have a question about PREEMPT_RT patch for 3.10 kernel. > > I am trying to port this rt patch: 0224-printk-rt-aware.

Re: [PREEMPT_RT]: Using printk-rt-aware.patch in non-rt kernel

-rt kernel? Is this the expected behavior, even on PREEMPT_RT kernel? Is there a way we can fix this issue on non-rt kernel? Please help us with your suggestions. Thanks, Pintu On Wed, Jun 13, 2018 at 8:02 PM Pintu Kumar wrote: > > Dear Thomas, > > I was looking into this RT patches fo

Re: [PREEMPT_RT]: Using printk-rt-aware.patch in non-rt kernel

-rt kernel? Is this the expected behavior, even on PREEMPT_RT kernel? Is there a way we can fix this issue on non-rt kernel? Please help us with your suggestions. Thanks, Pintu On Wed, Jun 13, 2018 at 8:02 PM Pintu Kumar wrote: > > Dear Thomas, > > I was looking into this RT patches fo

Re: [PATCH 2/3] selftests/android: initialize heap_type to avoid compiling warning

On Tue, Jul 10, 2018 at 8:20 PM Shuah Khan wrote: > > Hi Li Zhijian, > > On 07/01/2018 09:53 PM, Li Zhijian wrote: > > root@vm-lkp-nex04-8G-7 ~/linux-v4.18-rc2/tools/testing/selftests/android# > > make > > make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make > > rule. > >

Re: [PATCH 2/3] selftests/android: initialize heap_type to avoid compiling warning

On Tue, Jul 10, 2018 at 8:20 PM Shuah Khan wrote: > > Hi Li Zhijian, > > On 07/01/2018 09:53 PM, Li Zhijian wrote: > > root@vm-lkp-nex04-8G-7 ~/linux-v4.18-rc2/tools/testing/selftests/android# > > make > > make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make > > rule. > >

Re: Delivery Status Notification (Failure)

l I am not familiar with this. So, I need your help. Thank You! Regards, Pintu On Thu, May 17, 2018 at 6:58 PM, Pintu Kumar <pintu.p...@gmail.com> wrote: > On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar <pintu.p...@gmail.com> wrote: >> >> On Mon, May 14, 2018

Re: Delivery Status Notification (Failure)

l I am not familiar with this. So, I need your help. Thank You! Regards, Pintu On Thu, May 17, 2018 at 6:58 PM, Pintu Kumar wrote: > On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar wrote: >> >> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach wrote: >> > Am Montag, den 14.0

Re: Delivery Status Notification (Failure)

On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar <pintu.p...@gmail.com> wrote: > > On Mon, May 14, 2018 at 6:41 PM, Lucas Stach <l.st...@pengutronix.de> wrote: > > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar: > >> Hi, > >> > >> Is

Re: Delivery Status Notification (Failure)

On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar wrote: > > On Mon, May 14, 2018 at 6:41 PM, Lucas Stach wrote: > > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar: > >> Hi, > >> > >> Is there any work around possible to set IRQ affinity for some

Re: Delivery Status Notification (Failure)

On Mon, May 14, 2018 at 6:41 PM, Lucas Stach <l.st...@pengutronix.de> wrote: > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar: >> Hi, >> >> Is there any work around possible to set IRQ affinity for some GPIO >> interrupt ? >> How to avoid CPU

Re: Delivery Status Notification (Failure)

On Mon, May 14, 2018 at 6:41 PM, Lucas Stach wrote: > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar: >> Hi, >> >> Is there any work around possible to set IRQ affinity for some GPIO >> interrupt ? >> How to avoid CPU0 to receive the current GPIO int

Re: Delivery Status Notification (Failure)

be served by another CPU ? Need your inputs to decide whether it is still possible to set affinity for GPIO interrupt, or its impossible ? Thanks, Pintu On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar <pintu.p...@gmail.com> wrote: > On Fri, May 11, 2018 at 6:34 PM, Lucas St

Re: Delivery Status Notification (Failure)

be served by another CPU ? Need your inputs to decide whether it is still possible to set affinity for GPIO interrupt, or its impossible ? Thanks, Pintu On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar wrote: > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach wrote: >> Am Freitag, den 1

Re: [PATCH] selftests: android: delete RUN_TESTS and EMIT_TESTS overrides

On Thu, May 3, 2018 at 2:48 AM, Shuah Khan (Samsung OSG) wrote: > Delete RUN_TESTS and EMIT_TESTS overrides and use common defines in > lib.mk. Common defines work just fine and there is no need to define > custom overrides. > > Signed-off-by: Shuah Khan (Samsung OSG)

Re: [PATCH] selftests: android: delete RUN_TESTS and EMIT_TESTS overrides

On Thu, May 3, 2018 at 2:48 AM, Shuah Khan (Samsung OSG) wrote: > Delete RUN_TESTS and EMIT_TESTS overrides and use common defines in > lib.mk. Common defines work just fine and there is no need to define > custom overrides. > > Signed-off-by: Shuah Khan (Samsung OSG) > --- >

Re: Delivery Status Notification (Failure)

On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.st...@pengutronix.de> wrote: > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux: >> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote: >> > Hi, >> > >> > I need one help. >

Re: Delivery Status Notification (Failure)

On Fri, May 11, 2018 at 6:34 PM, Lucas Stach wrote: > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux: >> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote: >> > Hi, >> > >> > I need one help. >> > I am using

Re: Delivery Status Notification (Failure)

Hi, I need one help. I am using i.MX7 Sabre board with kernel version 4.1.15 Let's say I am interested in GPIO number: 21 I wanted to set CPU affinity for particular GPIO->IRQ number, so I tried the below steps: root@10:~# echo 21 > /sys/class/gpio/export root@10:~# echo "rising" >

Re: Delivery Status Notification (Failure)

Hi, I need one help. I am using i.MX7 Sabre board with kernel version 4.1.15 Let's say I am interested in GPIO number: 21 I wanted to set CPU affinity for particular GPIO->IRQ number, so I tried the below steps: root@10:~# echo 21 > /sys/class/gpio/export root@10:~# echo "rising" >

Re: [PATCH 01/24] selftests: android: ion: return Kselftest Skip code for skipped tests

On Sat, May 5, 2018 at 6:43 AM, Shuah Khan (Samsung OSG) wrote: > When ion test is skipped because of unmet dependencies and/or unsupported > configuration, it returns 0 which is treated as a pass by the Kselftest > framework. This leads to false positive result even when the

Re: [PATCH 01/24] selftests: android: ion: return Kselftest Skip code for skipped tests

On Sat, May 5, 2018 at 6:43 AM, Shuah Khan (Samsung OSG) wrote: > When ion test is skipped because of unmet dependencies and/or unsupported > configuration, it returns 0 which is treated as a pass by the Kselftest > framework. This leads to false positive result even when the test could > not be

Re: [HELP] CPU Hard LOCKUP during boot up with HPET clock source

Hi, As a simple query, Is there a way to skip current available clock source (hpet) and allow to pick the next one ? I guess this will solve our purpose. Thanks, Pintu On Fri, Apr 6, 2018 at 8:37 PM, Pintu Kumar <pintu.p...@gmail.com> wrote: > Hi, > > First the few details: &

Re: [HELP] CPU Hard LOCKUP during boot up with HPET clock source

Hi, As a simple query, Is there a way to skip current available clock source (hpet) and allow to pick the next one ? I guess this will solve our purpose. Thanks, Pintu On Fri, Apr 6, 2018 at 8:37 PM, Pintu Kumar wrote: > Hi, > > First the few details: > Kernel: 4.9.20 > Machi

Re: [PATCH v2] selftests/android/ion: fix heap_type may be uninitialized

On Thu, Apr 5, 2018 at 1:09 PM, Anders Roxell wrote: > gcc warns that 'heap_type' is not initialized if we don't come through > any of the two 'case' statesments before: > > ionapp_export.c:91:2: warning: ‘heap_type’ may be used uninitialized in > this function

Re: [PATCH v2] selftests/android/ion: fix heap_type may be uninitialized

On Thu, Apr 5, 2018 at 1:09 PM, Anders Roxell wrote: > gcc warns that 'heap_type' is not initialized if we don't come through > any of the two 'case' statesments before: > > ionapp_export.c:91:2: warning: ‘heap_type’ may be used uninitialized in > this function [-Wmaybe-uninitialized] >

[HELP] CPU Hard LOCKUP during boot up with HPET clock source

Hi, First the few details: Kernel: 4.9.20 Machine: x86_64 (AMD) Model: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz Cores: 8 Available clock source: # cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm Problem: [ 28.027409] NMI watchdog: Watchdog detected hard

[HELP] CPU Hard LOCKUP during boot up with HPET clock source

Hi, First the few details: Kernel: 4.9.20 Machine: x86_64 (AMD) Model: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz Cores: 8 Available clock source: # cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm Problem: [ 28.027409] NMI watchdog: Watchdog detected hard

Re: [PATCH] selftests/android/ion: fix heap_type may be uninitialized

On Thu, Mar 8, 2018 at 7:18 PM, Anders Roxell wrote: > gcc warns that 'heap_type' is not initialized if we don't come through > any of the two 'case' statesments before: > OK thanks for your patch. > ionapp_export.c:91:2: warning: ‘heap_type’ may be used uninitialized

Re: [PATCH] selftests/android/ion: fix heap_type may be uninitialized

On Thu, Mar 8, 2018 at 7:18 PM, Anders Roxell wrote: > gcc warns that 'heap_type' is not initialized if we don't come through > any of the two 'case' statesments before: > OK thanks for your patch. > ionapp_export.c:91:2: warning: ‘heap_type’ may be used uninitialized in > this function

Re: [VDSO]: vdso_test failing on arm 32 bit

On Thu, Feb 8, 2018 at 9:41 PM, Lynch, Nathan wrote: >> I commented the device tree reading property: >> arm,cpu-registers-not-fw-configured , from the arch/arm/kernel/vdso.c > > Don't do that, please. The presence of that property indicates that the > counter is not

Re: [VDSO]: vdso_test failing on arm 32 bit

On Thu, Feb 8, 2018 at 9:41 PM, Lynch, Nathan wrote: >> I commented the device tree reading property: >> arm,cpu-registers-not-fw-configured , from the arch/arm/kernel/vdso.c > > Don't do that, please. The presence of that property indicates that the > counter is not suitable for use by the OS.

Re: [VDSO]: vdso_test failing on arm 32 bit

<li...@armlinux.org.uk> wrote: > On Thu, Dec 14, 2017 at 10:50:50AM +0530, Pintu Kumar wrote: >> Oh ok. Thanks for this information. >> So, in conclusion, can I summarize like this: VDSO support on ARM 32-bit >> 1) VDSO works only on Cortex A7/A15 -> where generic timer ext

Re: [VDSO]: vdso_test failing on arm 32 bit

rote: > On Thu, Dec 14, 2017 at 10:50:50AM +0530, Pintu Kumar wrote: >> Oh ok. Thanks for this information. >> So, in conclusion, can I summarize like this: VDSO support on ARM 32-bit >> 1) VDSO works only on Cortex A7/A15 -> where generic timer extension >> is availabl

Re: [PATCH] selftests/android: Fix line continuation in Makefile

On Wed, Feb 7, 2018 at 5:22 AM, Daniel Díaz wrote: > The Makefile lacks a couple of line continuation backslashes > in an `if' clause, which can make the subsequent rsync > command go awry over the whole filesystem (`rsync -a / /`). > > /bin/sh: -c: line 5: syntax error:

Re: [PATCH] selftests/android: Fix line continuation in Makefile

On Wed, Feb 7, 2018 at 5:22 AM, Daniel Díaz wrote: > The Makefile lacks a couple of line continuation backslashes > in an `if' clause, which can make the subsequent rsync > command go awry over the whole filesystem (`rsync -a / /`). > > /bin/sh: -c: line 5: syntax error: unexpected end of file

Re: [PATCH] selftests/android: Fix line continuation in Makefile

On Wed, Feb 7, 2018 at 10:46 PM, Daniel Díaz Rodríguez <daniel.d...@linaro.org> wrote: > Hello! > > > On 7 February 2018 at 00:01, Pintu Kumar <pintu.p...@gmail.com> wrote: > [...] >> Thanks for your patch. >> However, I have copied this Makefile from &g

Re: [PATCH] selftests/android: Fix line continuation in Makefile

On Wed, Feb 7, 2018 at 10:46 PM, Daniel Díaz Rodríguez wrote: > Hello! > > > On 7 February 2018 at 00:01, Pintu Kumar wrote: > [...] >> Thanks for your patch. >> However, I have copied this Makefile from >> tools/testing/selftests/futex/Makefile before modif

Re: [PATCH] selftests/android: Fix line continuation in Makefile

On Wed, Feb 7, 2018 at 5:22 AM, Daniel Díaz wrote: > The Makefile lacks a couple of line continuation backslashes > in an `if' clause, which can make the subsequent rsync > command go awry over the whole filesystem (`rsync -a / /`). > > /bin/sh: -c: line 5: syntax error:

Re: [PATCH] selftests/android: Fix line continuation in Makefile

On Wed, Feb 7, 2018 at 5:22 AM, Daniel Díaz wrote: > The Makefile lacks a couple of line continuation backslashes > in an `if' clause, which can make the subsequent rsync > command go awry over the whole filesystem (`rsync -a / /`). > > /bin/sh: -c: line 5: syntax error: unexpected end of file

Re: [perf] perf test BPF fails on 4.9.20

On Mon, Feb 5, 2018 at 7:24 PM, Masami Hiramatsu <mhira...@kernel.org> wrote: > On Mon, 5 Feb 2018 15:17:41 +0530 > Pintu Kumar <pintu.p...@gmail.com> wrote: > >> On Sat, Feb 3, 2018 at 6:49 PM, Masami Hiramatsu <mhira...@kernel.org> wrote: >> > Hi Pi

Re: [perf] perf test BPF fails on 4.9.20

On Mon, Feb 5, 2018 at 7:24 PM, Masami Hiramatsu wrote: > On Mon, 5 Feb 2018 15:17:41 +0530 > Pintu Kumar wrote: > >> On Sat, Feb 3, 2018 at 6:49 PM, Masami Hiramatsu wrote: >> > Hi Pintu, >> > >> > On Fri, 2 Feb 2018 19:03:30 +0530 >> > Pintu

Re: [perf] perf test BPF fails on 4.9.20

On Sat, Feb 3, 2018 at 6:49 PM, Masami Hiramatsu <mhira...@kernel.org> wrote: > Hi Pintu, > > On Fri, 2 Feb 2018 19:03:30 +0530 > Pintu Kumar <pintu.p...@gmail.com> wrote: > >> Hi All, >> >> I have fixed both the issue with perf test. >> &

Re: [perf] perf test BPF fails on 4.9.20

On Sat, Feb 3, 2018 at 6:49 PM, Masami Hiramatsu wrote: > Hi Pintu, > > On Fri, 2 Feb 2018 19:03:30 +0530 > Pintu Kumar wrote: > >> Hi All, >> >> I have fixed both the issue with perf test. >> >> 1) 16: Try 'import perf' in python, checking link pr

Re: [perf] perf test BPF fails on 4.9.20

this issue I had to enable full version of CONFIG_DEBUG_INFO in kernel. Now, my question is: Is it possible to pass BPF test without enabling CONFIG_DEBUG_INFO in kernel ? Thanks, Pintu On Fri, Feb 2, 2018 at 1:25 PM, Pintu Kumar <pintu.p...@gmail.com> wrote: > Hi, > > perf te

Re: [perf] perf test BPF fails on 4.9.20

this issue I had to enable full version of CONFIG_DEBUG_INFO in kernel. Now, my question is: Is it possible to pass BPF test without enabling CONFIG_DEBUG_INFO in kernel ? Thanks, Pintu On Fri, Feb 2, 2018 at 1:25 PM, Pintu Kumar wrote: > Hi, > > perf test bpf prologue generation i

Re: [perf] perf test BPF fails on 4.9.20

! Is there any fix available for this issue? I searched 4.15, but could not relate any of the patches to this. Thanks, Pintu On Thu, Feb 1, 2018 at 7:34 PM, Pintu Kumar <pintu.p...@gmail.com> wrote: > Hi, > > After enabling DEBUG_INFO in kernel I still get this error for BPF test. > Pleas

Re: [perf] perf test BPF fails on 4.9.20

! Is there any fix available for this issue? I searched 4.15, but could not relate any of the patches to this. Thanks, Pintu On Thu, Feb 1, 2018 at 7:34 PM, Pintu Kumar wrote: > Hi, > > After enabling DEBUG_INFO in kernel I still get this error for BPF test. > Please help. > >

Re: [perf] perf probe fails sometimes on 4.9

f_mode. An error occurred in debuginfo analysis (-22). bpf_probe: failed to convert perf probe eventsFailed to add events selected by BPF test child finished with -1 end Test BPF filter subtest 1: FAILED! On Thu, Feb 1, 2018 at 10:50 AM, Pintu Kumar <pintu.p...@gmail.com> wrote:

Re: [perf] perf probe fails sometimes on 4.9

f_mode. An error occurred in debuginfo analysis (-22). bpf_probe: failed to convert perf probe eventsFailed to add events selected by BPF test child finished with -1 end Test BPF filter subtest 1: FAILED! On Thu, Feb 1, 2018 at 10:50 AM, Pintu Kumar wrote: > Dear Masami, > > Now I

Re: [perf] perf probe fails sometimes on 4.9

On Tue, 30 Jan 2018 19:20:36 +0530 > Pintu Kumar <pintu.p...@gmail.com> wrote: > >> On Tue, Jan 30, 2018 at 11:13 AM, Masami Hiramatsu <mhira...@kernel.org> >> wrote: >> > >> > On Mon, 29 Jan 2018 22:00:52 +0530 >> > Pintu Kumar <pin

Re: [perf] perf probe fails sometimes on 4.9

36 +0530 > Pintu Kumar wrote: > >> On Tue, Jan 30, 2018 at 11:13 AM, Masami Hiramatsu >> wrote: >> > >> > On Mon, 29 Jan 2018 22:00:52 +0530 >> > Pintu Kumar wrote: >> > >> > > Dear Masami, >> > > >> > > T

Re: [perf] perf probe fails sometimes on 4.9

On Tue, Jan 30, 2018 at 11:13 AM, Masami Hiramatsu <mhira...@kernel.org> wrote: > > On Mon, 29 Jan 2018 22:00:52 +0530 > Pintu Kumar <pintu.p...@gmail.com> wrote: > > > Dear Masami, > > > > Thank you so much for your reply. > > Please find some

Re: [perf] perf probe fails sometimes on 4.9

On Tue, Jan 30, 2018 at 11:13 AM, Masami Hiramatsu wrote: > > On Mon, 29 Jan 2018 22:00:52 +0530 > Pintu Kumar wrote: > > > Dear Masami, > > > > Thank you so much for your reply. > > Please find some of my answers inline. > > > > > > On Mon,

Re: [perf] perf probe fails sometimes on 4.9

Dear Masami, Thank you so much for your reply. Please find some of my answers inline. On Mon, Jan 29, 2018 at 7:47 PM, Masami Hiramatsu <mhira...@kernel.org> wrote: > On Mon, 29 Jan 2018 13:40:34 +0530 > Pintu Kumar <pintu.p...@gmail.com> wrote: > >> Hi All, &g

Re: [perf] perf probe fails sometimes on 4.9

Dear Masami, Thank you so much for your reply. Please find some of my answers inline. On Mon, Jan 29, 2018 at 7:47 PM, Masami Hiramatsu wrote: > On Mon, 29 Jan 2018 13:40:34 +0530 > Pintu Kumar wrote: > >> Hi All, >> >> 'perf probe' is failing sometimes on 4.9.20 w

Re: [perf] perf probe fails sometimes on 4.9

, Pintu Kumar <pintu.p...@gmail.com> wrote: > Hi, > > ** Changed the subject now, since these issues are related to general > perf commands. > > Following are the issues: > > 1) perf probe --add schedule - FAILED > output: > schedule is out of .text, skip it. >

Re: [perf] perf probe fails sometimes on 4.9

, Pintu Kumar wrote: > Hi, > > ** Changed the subject now, since these issues are related to general > perf commands. > > Following are the issues: > > 1) perf probe --add schedule - FAILED > output: > schedule is out of .text, skip it. > Error: Failed to add e

Re: [perf] perf test and probe fails sometimes on 4.9

-amd-x86-64/build If you have any clue about these failure please help me. Thanks, Pintu On Wed, Jan 24, 2018 at 8:23 PM, Pintu Kumar <pintu.p...@gmail.com> wrote: > Hi, > > Thanks for your help. > Yes it was a sub version issue. > > Earlier, while building the ke

Re: [perf] perf test and probe fails sometimes on 4.9

-amd-x86-64/build If you have any clue about these failure please help me. Thanks, Pintu On Wed, Jan 24, 2018 at 8:23 PM, Pintu Kumar wrote: > Hi, > > Thanks for your help. > Yes it was a sub version issue. > > Earlier, while building the kernel I left the SUBLEVEL as b

Re: [tools/perf] perf test LLVM failure on 4.9

nvert perf probe eventsFailed to add events selected by BPF test child finished with -1 end Test BPF filter subtest 1: FAILED! Thanks, Pintu On Wed, Jan 24, 2018 at 6:39 AM, Wangnan (F) <wangn...@huawei.com> wrote: > > > On 2018/1/23 20:37, Pintu Kumar wrote: >> >

Re: [tools/perf] perf test LLVM failure on 4.9

nvert perf probe eventsFailed to add events selected by BPF test child finished with -1 end Test BPF filter subtest 1: FAILED! Thanks, Pintu On Wed, Jan 24, 2018 at 6:39 AM, Wangnan (F) wrote: > > > On 2018/1/23 20:37, Pintu Kumar wrote: >> >> Hi All, >> >&

[tools/perf] perf test LLVM failure on 4.9

Hi All, I am verifying all perf tests on Ubuntu-16 x86-64 platform using the kernel version 4.9.20. I have installed several others packages including: clang, llvm But, when I run 'perf test' I get some FAILURE. Specially, 'perf test LLVM' is failing. Please check the below error logs:

[tools/perf] perf test LLVM failure on 4.9

Hi All, I am verifying all perf tests on Ubuntu-16 x86-64 platform using the kernel version 4.9.20. I have installed several others packages including: clang, llvm But, when I run 'perf test' I get some FAILURE. Specially, 'perf test LLVM' is failing. Please check the below error logs:

[VDSO]: vdso_test failing on arm 32 bit

Hi All, Did anybody tried running vdso_test (under Documentation/vDSO in kernel 4.1) on an ARM 32 bit system? When I test it on iMX.7 board (kernel 4.1, ARM 32 bit), I get this: # ./vdso_test Could not find __vdso_gettimeofday When I check more in parse_vdso.c, I found that under vdso_sym

[VDSO]: vdso_test failing on arm 32 bit

Hi All, Did anybody tried running vdso_test (under Documentation/vDSO in kernel 4.1) on an ARM 32 bit system? When I test it on iMX.7 board (kernel 4.1, ARM 32 bit), I get this: # ./vdso_test Could not find __vdso_gettimeofday When I check more in parse_vdso.c, I found that under vdso_sym

Re: [tegra186]: emmc resume failing after booting from snapshot image

On Wed, Nov 22, 2017 at 9:45 PM, Jon Hunter <jonath...@nvidia.com> wrote: > > On 22/11/17 12:26, Pintu Kumar wrote: >> Hello Jon, >> Yes I raised my query there almost 1 week back here. >> https://devtalk.nvidia.com/default/topic/1026527/jetson-tx2/-jetson-tx2-mmc-re

Re: [tegra186]: emmc resume failing after booting from snapshot image

On Wed, Nov 22, 2017 at 9:45 PM, Jon Hunter wrote: > > On 22/11/17 12:26, Pintu Kumar wrote: >> Hello Jon, >> Yes I raised my query there almost 1 week back here. >> https://devtalk.nvidia.com/default/topic/1026527/jetson-tx2/-jetson-tx2-mmc-resume-errors-af

Re: [tegra186]: emmc resume failing after booting from snapshot image

MMC subsystem and Tegra MMC driver between upstream and >> downstream are currently quite diverged so the upstream folks are >> unlikely to be able to help with issues with the downstream code. >> >> Mikko >> >> On 22.11.2017 08:41, Pintu Kumar wrote: >>

Re: [tegra186]: emmc resume failing after booting from snapshot image

C driver between upstream and >> downstream are currently quite diverged so the upstream folks are >> unlikely to be able to help with issues with the downstream code. >> >> Mikko >> >> On 22.11.2017 08:41, Pintu Kumar wrote: >>> Hi, >>> >>>

Re: [tegra186]: emmc resume failing after booting from snapshot image

) - On Mon, Nov 20, 2017 at 12:48 PM, Pintu Kumar <pintu.p...@gmail.com> wrote: > Hi, > > I am trying to verify suspend-to-disk on jetson-tx2 board (nvidia tegra186). > Suspend is working fine, but during resume emmc is

Re: [tegra186]: emmc resume failing after booting from snapshot image

) - On Mon, Nov 20, 2017 at 12:48 PM, Pintu Kumar wrote: > Hi, > > I am trying to verify suspend-to-disk on jetson-tx2 board (nvidia tegra186). > Suspend is working fine, but during resume emmc is failing to resume. > Kern

[tegra186]: emmc resume errors after booting from suspend

Hi, I am trying to verify suspend-to-disk on jetson-tx2 board (nvidia tegra186). Suspend is working fine, but during resume emmc is failing to resume. Kernel version: 4.4 Repo: https://nv-tegra.nvidia.com/gitweb/?p=linux-4.4.git;a=summary It returns with: mmc0: error -110 during resume (card

[tegra186]: emmc resume errors after booting from suspend

Hi, I am trying to verify suspend-to-disk on jetson-tx2 board (nvidia tegra186). Suspend is working fine, but during resume emmc is failing to resume. Kernel version: 4.4 Repo: https://nv-tegra.nvidia.com/gitweb/?p=linux-4.4.git;a=summary It returns with: mmc0: error -110 during resume (card

Re: Proposal: single defconfig for all ARM

On Tue, Nov 7, 2017 at 4:21 AM, Enrico Weigelt, metux IT consult <me...@gmx.de> wrote: > On 26.10.2017 18:26, Pintu Kumar wrote: >> >> Hi, >> >> My proposal is to maintain a common base defconfig file for all ARM >> products and only add the additional config

Re: Proposal: single defconfig for all ARM

On Tue, Nov 7, 2017 at 4:21 AM, Enrico Weigelt, metux IT consult wrote: > On 26.10.2017 18:26, Pintu Kumar wrote: >> >> Hi, >> >> My proposal is to maintain a common base defconfig file for all ARM >> products and only add the additional configs in the new de

Re: [PATCHv5 1/1] [tools/selftests]: android/ion: userspace test utility for ion buffer sharing

On Fri, Nov 3, 2017 at 6:02 AM, Shuah Khan <shua...@osg.samsung.com> wrote: > On 11/02/2017 05:54 PM, Laura Abbott wrote: >> On 11/02/2017 10:53 AM, Shuah Khan wrote: >>> On 11/02/2017 10:19 AM, Shuah Khan wrote: >>>> On 11/02/2017 10:15 AM, Pintu Kumar wrote:

Re: [PATCHv5 1/1] [tools/selftests]: android/ion: userspace test utility for ion buffer sharing

On Fri, Nov 3, 2017 at 6:02 AM, Shuah Khan wrote: > On 11/02/2017 05:54 PM, Laura Abbott wrote: >> On 11/02/2017 10:53 AM, Shuah Khan wrote: >>> On 11/02/2017 10:19 AM, Shuah Khan wrote: >>>> On 11/02/2017 10:15 AM, Pintu Kumar wrote: >>>>> On T

Re: [PATCHv5 1/1] [tools/selftests]: android/ion: userspace test utility for ion buffer sharing

On Thu, Nov 2, 2017 at 8:37 PM, Shuah Khan wrote: > Hi Pintu, > > On 11/01/2017 11:00 AM, Pintu Agarwal wrote: >> This is a test utility to verify ION buffer sharing in user space >> between 2 independent processes. >> It uses unix domain socket (with SCM_RIGHTS) as IPC to

Re: [PATCHv5 1/1] [tools/selftests]: android/ion: userspace test utility for ion buffer sharing

On Thu, Nov 2, 2017 at 8:37 PM, Shuah Khan wrote: > Hi Pintu, > > On 11/01/2017 11:00 AM, Pintu Agarwal wrote: >> This is a test utility to verify ION buffer sharing in user space >> between 2 independent processes. >> It uses unix domain socket (with SCM_RIGHTS) as IPC to transfer an FD to >>

Re: [lkp-robot] [android/ion] 5fb70554d6: kernel_selftests.android.make_fail

On Wed, Nov 1, 2017 at 10:27 PM, Shuah Khan <sh...@kernel.org> wrote: > On 11/01/2017 10:26 AM, Pintu Kumar wrote: >> On Wed, Nov 1, 2017 at 8:34 PM, Shuah Khan <sh...@kernel.org> wrote: >>> On 11/01/2017 04:12 AM, Pintu Kumar wrote: >>>> On Wed,

Re: [lkp-robot] [android/ion] 5fb70554d6: kernel_selftests.android.make_fail

On Wed, Nov 1, 2017 at 10:27 PM, Shuah Khan wrote: > On 11/01/2017 10:26 AM, Pintu Kumar wrote: >> On Wed, Nov 1, 2017 at 8:34 PM, Shuah Khan wrote: >>> On 11/01/2017 04:12 AM, Pintu Kumar wrote: >>>> On Wed, Nov 1, 2017 at 3:28 AM, Laura Abbott wrote: >>>

Re: [lkp-robot] [android/ion] 5fb70554d6: kernel_selftests.android.make_fail

On Wed, Nov 1, 2017 at 8:34 PM, Shuah Khan <sh...@kernel.org> wrote: > On 11/01/2017 04:12 AM, Pintu Kumar wrote: >> On Wed, Nov 1, 2017 at 3:28 AM, Laura Abbott <labb...@redhat.com> wrote: >>> On 10/31/2017 03:21 AM, Pintu Kumar wrote: >>>> On Tue, O

  1   2   3   >