Re: [PATCH] parisc: avoid a warning on u8 cast for cmpxchg on u8 pointers

2021-04-06 Thread Rolf Eike Beer
Am Dienstag, 6. April 2021, 06:59:29 CEST schrieb Gao Xiang:
> From: Gao Xiang 
> 
> commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
> can generate a sparse warningi ("cast truncates bits from constant
   ^
> value"), which has been reported several times [1] [2] [3].



signature.asc
Description: This is a digitally signed message part.


[PATCH] typo: kthead -> kthread

2021-03-17 Thread Rolf Eike Beer
Signed-off-by: Rolf Eike Beer 
---
 kernel/rcu/tree_plugin.h | 2 +-
 mm/oom_kill.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 2d603771c7dc..5f22869d7c66 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1861,7 +1861,7 @@ static bool rcu_nocb_try_bypass(struct rcu_data *rdp, 
struct rcu_head *rhp,
 }
 
 /*
- * Awaken the no-CBs grace-period kthead if needed, either due to it
+ * Awaken the no-CBs grace-period kthread if needed, either due to it
  * legitimately being asleep or due to overload conditions.
  *
  * If warranted, also wake up the kthread servicing this CPUs queues.
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 9efaf430cfd3..cd7f9ac48746 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -922,7 +922,7 @@ static void __oom_kill_process(struct task_struct *victim, 
const char *message)
continue;
}
/*
-* No kthead_use_mm() user needs to read from the userspace so
+* No kthread_use_mm() user needs to read from the userspace so
 * we are ok to reap it.
 */
if (unlikely(p->flags & PF_KTHREAD))
-- 
2.30.2

-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





Re: [PATCH RFCv2] mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault/prealloc memory

2021-03-08 Thread Rolf Eike Beer

diff --git a/mm/internal.h b/mm/internal.h
index 9902648f2206..a5c4ed23b1db 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -340,6 +340,9 @@ void __vma_unlink_list(struct mm_struct *mm,
struct vm_area_struct *vma);
 #ifdef CONFIG_MMU
 extern long populate_vma_page_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end, int *nonblocking);
+extern long faultin_vma_page_range(struct vm_area_struct *vma,
+  unsigned long start, unsigned long end,
+  bool write, int *nonblocking);
 extern void munlock_vma_pages_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end);
 static inline void munlock_vma_pages_all(struct vm_area_struct *vma)


The parameter name does not match the one in the implementation.

Otherwise the implementation looks fine AFAICT.

Eike


[PATCH] Kconfig: fix help text of TRACEPOINT_BENCHMARK

2021-03-02 Thread Rolf Eike Beer
Signed-off-by: Rolf Eike Beer 
---
 kernel/trace/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 9c266b93cbc0..7fa82778c3e6 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -694,7 +694,7 @@ config TRACEPOINT_BENCHMARK
help
 This option creates the tracepoint "benchmark:benchmark_event".
 When the tracepoint is enabled, it kicks off a kernel thread that
-goes into an infinite loop (calling cond_sched() to let other tasks
+goes into an infinite loop (calling cond_resched() to let other tasks
 run), and calls the tracepoint. Each iteration will record the time
 it took to write to the tracepoint and the next iteration that
 data will be passed to the tracepoint itself. That is, the tracepoint
-- 
2.30.1

-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





[PATCH] simplify copy_mm()

2021-02-18 Thread Rolf Eike Beer
All this can happen without a single goto.

Signed-off-by: Rolf Eike Beer 
---
 kernel/fork.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index d66cd1014211..1cad8c622b34 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1382,7 +1382,6 @@ static struct mm_struct *dup_mm(struct task_struct *tsk,
 static int copy_mm(unsigned long clone_flags, struct task_struct *tsk)
 {
struct mm_struct *mm, *oldmm;
-   int retval;
 
tsk->min_flt = tsk->maj_flt = 0;
tsk->nvcsw = tsk->nivcsw = 0;
@@ -1409,21 +1408,15 @@ static int copy_mm(unsigned long clone_flags, struct 
task_struct *tsk)
if (clone_flags & CLONE_VM) {
mmget(oldmm);
mm = oldmm;
-   goto good_mm;
+   } else {
+   mm = dup_mm(tsk, current->mm);
+   if (!mm)
+   return -ENOMEM;
}
 
-   retval = -ENOMEM;
-   mm = dup_mm(tsk, current->mm);
-   if (!mm)
-   goto fail_nomem;
-
-good_mm:
tsk->mm = mm;
tsk->active_mm = mm;
return 0;
-
-fail_nomem:
-   return retval;
 }
 
 static int copy_fs(unsigned long clone_flags, struct task_struct *tsk)
-- 
2.30.0


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





Re: [PATCH RFC] mm/madvise: introduce MADV_POPULATE to prefault/prealloc memory

2021-02-18 Thread Rolf Eike Beer

Let's introduce MADV_POPULATE with the following semantics
1. MADV_POPULATED does not work on PROT_NONE and special VMAs. It 
works

   on everything else.
2. Errors during MADV_POPULATED (especially OOM) are reported. If we 
hit

   hardware errors on pages, ignore them - nothing we really can or
   should do.
3. On errors during MADV_POPULATED, some memory might have been
   populated. Callers have to clean up if they care.
4. Concurrent changes to the virtual memory layour are tolerated - we

^t

   process each and every PFN only once, though.
5. If MADV_POPULATE succeeds, all memory in the range can be accessed
   without SIGBUS. (of course, not if user space changed mappings in 
the

   meantime or KSM kicked in on anonymous memory).


You are talking both about MADV_POPULATE and MADV_POPULATED here.

Eike


Re: [PATCH] scripts: Fix linking extract-cert against libcrypto

2021-02-11 Thread Rolf Eike Beer
Am Donnerstag, 11. Februar 2021, 11:29:33 CET schrieb Rolf Eike Beer:

> I'm just guessing, but your build error looks like you are also
> cross-building the tools, which is wrong. You want them to be host-tools.
> So don't export PKG_CONFIG_SYSROOT_DIR, it would then try to link target
> libraries into a host binary.

I have looked again how I do it:

# this is for additional _host_ .pc files
export PKG_CONFIG_PATH=${prefix}/lib/pkgconfig

Then have a target-pkg-config, so this code inside several kernel Makefiles 
will work:

PKG_CONFIG ?= $(CROSS_COMPILE)pkg-config

And then export your PKG_CONFIG_SYSROOT_DIR and the like inside that. I bet 
you have all of this already in place, so just remove the SYSROOT_DIR from 
your kernel build script and things should work.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH] scripts: Fix linking extract-cert against libcrypto

2021-02-11 Thread Rolf Eike Beer
Am Dienstag, 9. Februar 2021, 09:44:33 CET schrieb Rolf Eike Beer:
> Am Dienstag, 9. Februar 2021, 05:59:56 CET schrieb Daniel Díaz:
> > When compiling under OpenEmbedded, the following error is seen
> > 
> > as of recently:
> >   /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside /
> >   /srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a
> > 
> > inside / /srv/oe/build/tmp/hosttools/ld: cannot find
> > /lib/ld-linux-x86-64.so.2 inside / collect2: error: ld returned 1 exit
> > status
> > 
> >   make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1
> 
> [...]
> 
> > As per `make`'s documentation:
> >   LDFLAGS
> >   
> > Extra flags to give to compilers when they are supposed to
> > invoke the linker, ‘ld’, such as -L. Libraries (-lfoo)
> > should be added to the LDLIBS variable instead.
> >   
> >   LDLIBS
> >   
> > Library flags or names given to compilers when they are
> > supposed to invoke the linker, ‘ld’. LOADLIBES is a
> > deprecated (but still supported) alternative to LDLIBS.
> > Non-library linker flags, such as -L, should go in the
> > LDFLAGS variable.
> 
> Correct. And the patch I use for my local 4.19 build actually uses LDLIBS,
> so it must have gone wrong in some rebase for one of the intermediate
> versions.
> 
> Acked-by: Rolf Eike Beer 

Ok, now actually with proper testing: no, your patch doesn't work. When 
changing LDLIBS to LDFLAGS things do not show up on the commandline at all.

LDLIBS:

  gcc -Wp,-MMD,scripts/.sign-file.d -Wall -Wmissing-prototypes -Wstrict-
prototypes -O2 -fomit-frame-pointer -std=gnu89  -I/opt/emlix/test/include 
-I ./scripts   -o scripts/sign-file /tmp/e2/build/linux-kernel/scripts/sign-
file.c   -L/opt/emlix/test/lib -lcrypto -lz -ldl -pthread

LDFLAGS:

  gcc -Wp,-MMD,scripts/.sign-file.d -Wall -Wmissing-prototypes -Wstrict-
prototypes -O2 -fomit-frame-pointer -std=gnu89  -I/opt/emlix/test/include 
-I ./scripts   -o scripts/sign-file /tmp/e2/build/linux-kernel/scripts/sign-
file.c   

When looking closely you may notice that this is not entirely the same as 
current master would output: I missed the CFLAGS for sign-file in my patch. 
When testing your patch I accidentially had a .config that had module 
signatures disabled, so I have not tested it actually, that's why I didn't 
notice that it doesn't work.

I'm just guessing, but your build error looks like you are also cross-building 
the tools, which is wrong. You want them to be host-tools. So don't export 
PKG_CONFIG_SYSROOT_DIR, it would then try to link target libraries into a host  
binary.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH] scripts: Fix linking extract-cert against libcrypto

2021-02-11 Thread Rolf Eike Beer
Am Dienstag, 9. Februar 2021, 09:44:33 CET schrieb Rolf Eike Beer:
> Am Dienstag, 9. Februar 2021, 05:59:56 CET schrieb Daniel Díaz:
> > When compiling under OpenEmbedded, the following error is seen
> > 
> > as of recently:
> >   /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside /
> >   /srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a
> > 
> > inside / /srv/oe/build/tmp/hosttools/ld: cannot find
> > /lib/ld-linux-x86-64.so.2 inside / collect2: error: ld returned 1 exit
> > status
> > 
> >   make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1
> 
> [...]
> 
> > As per `make`'s documentation:
> >   LDFLAGS
> >   
> > Extra flags to give to compilers when they are supposed to
> > invoke the linker, ‘ld’, such as -L. Libraries (-lfoo)
> > should be added to the LDLIBS variable instead.
> >   
> >   LDLIBS
> >   
> > Library flags or names given to compilers when they are
> > supposed to invoke the linker, ‘ld’. LOADLIBES is a
> > deprecated (but still supported) alternative to LDLIBS.
> > Non-library linker flags, such as -L, should go in the
> > LDFLAGS variable.
> 
> Correct. And the patch I use for my local 4.19 build actually uses LDLIBS,
> so it must have gone wrong in some rebase for one of the intermediate
> versions.
> 
> Acked-by: Rolf Eike Beer 

Oh, scrap that. I misread your patch. I was actually using LDLIBS exclusively, 
no LDFLAGS at all.

I'll have to get my test setup ready for this, can take a moment.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH] scripts: Fix linking extract-cert against libcrypto

2021-02-09 Thread Rolf Eike Beer
Am Dienstag, 9. Februar 2021, 05:59:56 CET schrieb Daniel Díaz:
> When compiling under OpenEmbedded, the following error is seen
> as of recently:
> 
>   /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside /
>   /srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a
> inside / /srv/oe/build/tmp/hosttools/ld: cannot find
> /lib/ld-linux-x86-64.so.2 inside / collect2: error: ld returned 1 exit
> status
>   make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1

[...]
> As per `make`'s documentation:
> 
>   LDFLAGS
> Extra flags to give to compilers when they are supposed to
> invoke the linker, ‘ld’, such as -L. Libraries (-lfoo)
> should be added to the LDLIBS variable instead.
> 
>   LDLIBS
> Library flags or names given to compilers when they are
> supposed to invoke the linker, ‘ld’. LOADLIBES is a
> deprecated (but still supported) alternative to LDLIBS.
> Non-library linker flags, such as -L, should go in the
> LDFLAGS variable.

Correct. And the patch I use for my local 4.19 build actually uses LDLIBS, so 
it must have gone wrong in some rebase for one of the intermediate versions.

Acked-by: Rolf Eike Beer 
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

2021-02-08 Thread Rolf Eike Beer
Am Dienstag, 9. Februar 2021, 03:31:44 CET schrieb Naresh Kamboju:
> On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
> 
>  wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5
> > .10.15-rc1.gz> 
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-
> > rc.git linux-5.10.y> 
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Due to the patch below, the x86_64 build breaks with gcc 7.3.x
> This issue is specific to openembedded kernel builder.
> 
> We have also noticed on mainline, Linux next and now on stable-rc 5.10.
> 
> collect2: error: ld returned 1 exit status
> make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1
> 
> ref:
> Build failure link,
> https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/D
> ISTRO=lkft,MACHINE=intel-corei7-64,label=docker-buster-lkft/64/consoleText

Is this part relevant or does that always happen with your builder.

| /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/libc.so.6 inside 
/
| /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /usr/lib/
libc_nonshared.a inside /
| /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/ld-linux-
x86-64.so.2 inside /

Can you provide a log with V=1 where we can see what actually is going on?

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


[PATCH v6] scripts: use pkg-config to locate libcrypto

2021-01-27 Thread Rolf Eike Beer
>From f467f251e44cd406c9556ea7d68d131f56e0d832 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer 
Date: Thu, 22 Nov 2018 16:40:49 +0100
Subject: [PATCH] scripts: use pkg-config to locate libcrypto

Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer 
Cc: sta...@vger.kernel.org # 5.6.x
---
 scripts/Makefile | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Changes in v6:
 - hardcode pkg-config

diff --git a/scripts/Makefile b/scripts/Makefile
index b5418ec587fb..9de3c03b94aa 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -3,6 +3,9 @@
 # scripts contains sources for various helper programs used throughout
 # the kernel for the build process.
 
+CRYPTO_LIBS = $(shell pkg-config --libs libcrypto 2> /dev/null || echo 
-lcrypto)
+CRYPTO_CFLAGS = $(shell pkg-config --cflags libcrypto 2> /dev/null)
+
 hostprogs-always-$(CONFIG_BUILD_BIN2C) += bin2c
 hostprogs-always-$(CONFIG_KALLSYMS)+= kallsyms
 hostprogs-always-$(BUILD_C_RECORDMCOUNT)   += recordmcount
@@ -14,8 +17,9 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE)   += 
insert-sys-cert
 
 HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
+HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
+HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
 
 ifdef CONFIG_UNWINDER_ORC
 ifeq ($(ARCH),x86_64)
-- 
2.30.0

-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





Re: [PATCH v5] scripts: use pkg-config to locate libcrypto

2021-01-26 Thread Rolf Eike Beer
Am Mittwoch, 13. Januar 2021, 13:49:12 CET schrieb Rolf Eike Beer:
> Otherwise build fails if the headers are not in the default location. While
> at it also ask pkg-config for the libs, with fallback to the existing
> value.

Can someone please take this through the kbuild-tree? Noone seems to be 
interested in picking this up so far.

Thanks,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source


signature.asc
Description: This is a digitally signed message part.


Re: [PATCH v5] scripts: use pkg-config to locate libcrypto

2021-01-26 Thread Rolf Eike Beer
Am Dienstag, 26. Januar 2021, 07:30:03 CET schrieb Masahiro Yamada:
> On Tue, Jan 26, 2021 at 2:42 PM Rolf Eike Beer  wrote:
> > Am Mittwoch, 13. Januar 2021, 13:49:12 CET schrieb Rolf Eike Beer:
> > > Otherwise build fails if the headers are not in the default location.
> > > While
> > > at it also ask pkg-config for the libs, with fallback to the existing
> > > value.
> > 
> > Can someone please take this through the kbuild-tree? Noone seems to be
> > interested in picking this up so far.

> Is 'PKG_CONFIG' necessary?
> 
> I see many Makefiles hard-coding 'pkg-config'.

Well, it depends ;)

When people use pkgconf then this usually installs a pkg-config alias, too, so 
that would be no problem. The problem comes when other places in the kernel 
start copying that code over, and then hardcode pkg-config for stuff that 
needs a prefixed pkg-config because it is about target code.

Given that I would prefer it this way, but YMMV. If it is that variable that 
blocks integrating I'll change it.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source


signature.asc
Description: This is a digitally signed message part.


[PATCH v5] scripts: use pkg-config to locate libcrypto

2021-01-13 Thread Rolf Eike Beer
Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer 
Cc: sta...@vger.kernel.org # 5.6.x
---
 scripts/Makefile | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

This has been sent multiple times since more than 2 year, please pick it up 
through whatever tree. I need to patch every new stable kernel version to 
make them build in our chrooted environment.


diff --git a/scripts/Makefile b/scripts/Makefile
index b5418ec587fb..7553692d241f 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -3,6 +3,11 @@
 # scripts contains sources for various helper programs used throughout
 # the kernel for the build process.
 
+PKG_CONFIG ?= pkg-config
+
+CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || echo 
-lcrypto)
+CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null)
+
 hostprogs-always-$(CONFIG_BUILD_BIN2C) += bin2c
 hostprogs-always-$(CONFIG_KALLSYMS)+= kallsyms
 hostprogs-always-$(BUILD_C_RECORDMCOUNT)   += recordmcount
@@ -14,8 +19,9 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE)   += 
insert-sys-cert
 
 HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
+HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
+HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
 
 ifdef CONFIG_UNWINDER_ORC
 ifeq ($(ARCH),x86_64)
-- 
2.29.2
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





Re: [PATCH] kbuild: improve libelf detection

2021-01-13 Thread Rolf Eike Beer
Am Dienstag, 12. Januar 2021, 20:00:10 CET schrieb Alistair Delva:
> When `pkg-config --libs' wasn't used or didn't return anything useful,
> the test for libelf would fail even if the headers and libraries were
> available to kbuild via KBUILD_HOSTCFLAGS and KBUILD_HOSTLDFLAGS.
> 
> This makes the check in the core Makefile match the check that is done
> in tools/objtool/Makefile. Specifically, the C compiler is passed the
> full KBUILD_HOSTCFLAGS and KBUILD_HOSTLDFLAGS, which may have set up
> additional sysroot/include/library search paths to find libelf.

Sounds plausible.

-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source


signature.asc
Description: This is a digitally signed message part.


[PATCH] Documentation: fix typos in split page table lock description

2021-01-12 Thread Rolf Eike Beer
Signed-off-by: Rolf Eike Beer 
---
 Documentation/vm/split_page_table_lock.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/vm/split_page_table_lock.rst 
b/Documentation/vm/split_page_table_lock.rst
index ff51f4a5494d..c08919662704 100644
--- a/Documentation/vm/split_page_table_lock.rst
+++ b/Documentation/vm/split_page_table_lock.rst
@@ -32,7 +32,7 @@ There are helpers to lock/unlock a table and other accessor 
functions:
 
 Split page table lock for PTE tables is enabled compile-time if
 CONFIG_SPLIT_PTLOCK_CPUS (usually 4) is less or equal to NR_CPUS.
-If split lock is disabled, all tables guaded by mm->page_table_lock.
+If split lock is disabled, all tables are guarded by mm->page_table_lock.
 
 Split page table lock for PMD tables is enabled, if it's enabled for PTE
 tables and the architecture supports it (see below).
-- 
2.29.2

-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





Re: [RFC PATCH] treewide: remove bzip2 compression support

2020-11-19 Thread Rolf Eike Beer

Am 2020-11-17 23:32, schrieb Alex Xu (Hello71):

bzip2 is either slower or larger than every other supported algorithm,
according to benchmarks at [0]. It is far slower to decompress than any
other algorithm, and still larger than lzma, xz, and zstd.




diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index abb9fc164657..b74d14caabe6 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -781,10 +781,10 @@ Protocol: 2.08+
   The payload may be compressed. The format of both the compressed and
   uncompressed data should be determined using the standard magic
   numbers.  The currently supported compression formats are gzip
-  (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
-  (magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number
-  02 21) and ZSTD (magic number 28 B5). The uncompressed payload is
-  currently always ELF (magic number 7F 45 4C 46).
+  (magic numbers 1F 8B or 1F 9E), LZMA (magic number 5D 00), XZ (magic
+  number FD 37), LZ4 (magic number 02 21) and ZSTD (magic number 28
+  B5). The uncompressed payload is currently always ELF (magic number
+  7F 45 4C 46).

    ==
 Field name:payload_length
diff --git a/arch/arm/configs/aspeed_g4_defconfig
b/arch/arm/configs/aspeed_g4_defconfig
index 58d293b63581..f2f5dcd0e59c 100644


I would keep the magic number, and just tell that it is not supported by 
newer kernels anymore if at all. It's just handy to be able to look into 
the most recent documentation and see what the values are for. If you 
look at an older image and don't find the magic number my first impulse 
would not be to look at older versions of the documentation for things 
that were removed.


Maybe something like:

"Formerly supported was also bzip2 (magic number 42 5A)."

Eike


[PATCH] binfmt_elf: simplify error handling in load_elf_phdrs()

2020-11-03 Thread Rolf Eike Beer
Signed-off-by: Rolf Eike Beer 
---
 fs/binfmt_elf.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index b588d1291b25..74827a7a06d0 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -458,7 +458,7 @@ static struct elf_phdr *load_elf_phdrs(const struct elfhdr 
*elf_ex,
   struct file *elf_file)
 {
struct elf_phdr *elf_phdata = NULL;
-   int retval, err = -1;
+   int retval = -1;
unsigned int size;
 
/*
@@ -480,15 +480,9 @@ static struct elf_phdr *load_elf_phdrs(const struct elfhdr 
*elf_ex,
 
/* Read in the program headers */
retval = elf_read(elf_file, elf_phdata, size, elf_ex->e_phoff);
-   if (retval < 0) {
-   err = retval;
-   goto out;
-   }
 
-   /* Success! */
-   err = 0;
 out:
-   if (err) {
+   if (retval) {
kfree(elf_phdata);
elf_phdata = NULL;
}
-- 
2.29.1


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





fix typos in "compress" variants

2020-11-03 Thread Rolf Eike Beer
Signed-off-by: Rolf Eike Beer 
---
 arch/x86/kernel/head64.c | 2 +-
 fs/f2fs/data.c   | 2 +-
 scripts/kallsyms.c   | 2 +-
 scripts/spelling.txt | 3 +++
 4 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 05e117137b45..a18a11acad92 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -105,7 +105,7 @@ static unsigned int __head *fixup_int(void *ptr, unsigned 
long physaddr)
 static bool __head check_la57_support(unsigned long physaddr)
 {
/*
-* 5-level paging is detected and enabled at kernel decomression
+* 5-level paging is detected and enabled at kernel decompression
 * stage. Only check if it has been enabled there.
 */
if (!(native_read_cr4() & X86_CR4_LA57))
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index be4da52604ed..93c23ae5723d 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -2377,7 +2377,7 @@ static int f2fs_mpage_readpages(struct inode *inode,
 
 #ifdef CONFIG_F2FS_FS_COMPRESSION
if (f2fs_compressed_file(inode)) {
-   /* there are remained comressed pages, submit them */
+   /* there are remained compressed pages, submit them */
if (!f2fs_cluster_can_merge_page(, page->index)) {
ret = f2fs_read_multi_pages(, ,
max_nr_pages,
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 7ecd2ccba531..623dedecd8e3 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -12,7 +12,7 @@
  *  map char code 0xF7 to represent "write_" and then in every symbol where
  *  "write_" appears it can be replaced by 0xF7, saving 5 bytes.
  *  The used codes themselves are also placed in the table so that the
- *  decompresion can work without "special cases".
+ *  decompression can work without "special cases".
  *  Applied to kernel symbols, this usually produces a compression ratio
  *  of about 50%.
  *
diff --git a/scripts/spelling.txt b/scripts/spelling.txt
index 953f4a2de1e5..061e15201739 100644
--- a/scripts/spelling.txt
+++ b/scripts/spelling.txt
@@ -338,6 +338,7 @@ compoment||component
 comppatible||compatible
 compres||compress
 compresion||compression
+comressed||compressed
 comression||compression
 comunication||communication
 conbination||combination
@@ -406,6 +407,8 @@ debouce||debounce
 decendant||descendant
 decendants||descendants
 decompres||decompress
+decompresion||decompression
+decomression||decompression
 decsribed||described
 decription||description
 dectected||detected
-- 
2.29.1


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





binfmt_elf: simplify error handling in load_elf_phdrs()

2020-08-05 Thread Rolf Eike Beer
---
 fs/binfmt_elf.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 251298d25c8c..64b4b47448af 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -434,7 +434,7 @@ static struct elf_phdr *load_elf_phdrs(const struct elfhdr 
*elf_ex,
   struct file *elf_file)
 {
struct elf_phdr *elf_phdata = NULL;
-   int retval, err = -1;
+   int retval = -1;
unsigned int size;
 
/*
@@ -456,15 +456,9 @@ static struct elf_phdr *load_elf_phdrs(const struct elfhdr 
*elf_ex,
 
/* Read in the program headers */
retval = elf_read(elf_file, elf_phdata, size, elf_ex->e_phoff);
-   if (retval < 0) {
-   err = retval;
-   goto out;
-   }
 
-   /* Success! */
-   err = 0;
 out:
-   if (err) {
+   if (retval) {
kfree(elf_phdata);
elf_phdata = NULL;
}
-- 
2.28.0


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





[PATCH] binfmt_elf: fix documented return value for load_elf_phdrs()

2020-08-05 Thread Rolf Eike Beer
This function has never returned anything but a plain NULL.

Fixes: 6a8d38945cf4e6e819d6b550250615db763065a0
Signed-off-by: Rolf Eike Beer 
---
 fs/binfmt_elf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 9fe3b51c116a..251298d25c8c 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -428,7 +428,7 @@ static int elf_read(struct file *file, void *buf, size_t 
len, loff_t pos)
  *
  * Loads ELF program headers from the binary file elf_file, which has the ELF
  * header pointed to by elf_ex, into a newly allocated array. The caller is
- * responsible for freeing the allocated data. Returns an ERR_PTR upon failure.
+ * responsible for freeing the allocated data. Returns NULL upon failure.
  */
 static struct elf_phdr *load_elf_phdrs(const struct elfhdr *elf_ex,
   struct file *elf_file)
-- 
2.28.0


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





Re: [PATCH v4] scripts: use pkg-config to locate libcrypto

2020-07-30 Thread Rolf Eike Beer
Am Montag, 27. April 2020, 10:11:28 CEST schrieb Rolf Eike Beer:
> From 082ba542ca4c710dcf592a6f9233603b9275d05d Mon Sep 17 00:00:00 2001
> From: Rolf Eike Beer 
> Date: Thu, 22 Nov 2018 16:40:49 +0100
> Subject: [PATCH 1/2] scripts: use pkg-config to locate libcrypto
> 
> Otherwise build fails if the headers are not in the default location. While
> at it also ask pkg-config for the libs, with fallback to the existing
> value.

Close to 2 years since the original patch… can this please be applied? It 
get's annoying to patch every new kernel version the same way again.

Thx

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source


signature.asc
Description: This is a digitally signed message part.


Re: [PATCH] parisc: suppress error messages for 'make clean'

2020-06-13 Thread Rolf Eike Beer
Helge Deller wrote:
> On 10.05.20 03:19, Masahiro Yamada wrote:
> > Hi Helge,
> > 
> > On Sun, May 10, 2020 at 2:39 AM Helge Deller  wrote:

> > I will drop this patch from my kbuild tree,
> > then you will apply what you think is best
> > to your tree.
> > 
> > What do you think?
> 
> Sure, I'll take it through the parisc tree.

Is this already in 5.7.2? I get these:

pioneer /usr/src/linux-5.7.1-gentoo #  make distclean
gcc: error: missing argument to '-Wframe-larger-than='
gcc: error: missing argument to '-Wframe-larger-than='
  CLEAN   arch/parisc/kernel
gcc: error: missing argument to '-Wframe-larger-than='
gcc: error: missing argument to '-Wframe-larger-than='

Eike

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH 08/12] parisc: use pgtable-nopXd instead of 4level-fixup

2019-10-23 Thread Rolf Eike Beer
diff --git a/arch/parisc/include/asm/page.h 
b/arch/parisc/include/asm/page.h

index 93caf17..1d339ee 100644
--- a/arch/parisc/include/asm/page.h
+++ b/arch/parisc/include/asm/page.h
@@ -42,48 +42,54 @@ typedef struct { unsigned long pte; } pte_t; /*
either 32 or 64bit */

 /* NOTE: even on 64 bits, these entries are __u32 because we allocate
  * the pmd and pgd in ZONE_DMA (i.e. under 4GB) */
-typedef struct { __u32 pmd; } pmd_t;
 typedef struct { __u32 pgd; } pgd_t;
 typedef struct { unsigned long pgprot; } pgprot_t;

-#define pte_val(x) ((x).pte)
-/* These do not work lvalues, so make sure we don't use them as such. 
*/

+#if CONFIG_PGTABLE_LEVELS == 3
+typedef struct { __u32 pmd; } pmd_t;
+#define __pmd(x)   ((pmd_t) { (x) } )
+/* pXd_val() do not work lvalues, so make sure we don't use them as 
such. */


For me it sounds like there is something missing, maybe an "as" before 
lvalues?

And it was "These", so plural, and now it is singular, so do -> does?

Eike


Re: [PATCH v3][RESEND] scripts: use pkg-config to locate libcrypto

2019-09-11 Thread Rolf Eike Beer
Am Dienstag, 10. September 2019, 12:48:30 CEST schrieb Sasha Levin:
> Hi,
> 
> [This is an automated email]
> 
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
> 
> The bot has tested the following trees: v5.2.13, v4.19.71, v4.14.142,
> v4.9.191, v4.4.191.
> 
> v5.2.13: Build OK!
> v4.19.71: Build OK!
> v4.14.142: Failed to apply! Possible dependencies:
> 8377bd2b9ee1 ("kbuild: Rename HOST_LOADLIBES to KBUILD_HOSTLDLIBS")

This one causes the collision, the simple fix would probably be to manually 
use the old variable names when cherry-picking.

> How should we proceed with this patch?

I can send a backport or you manually fix it up when applying, as you wish.

Greetings,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


[PATCH v3][RESEND] scripts: use pkg-config to locate libcrypto

2019-09-10 Thread Rolf Eike Beer
Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer 
Cc: sta...@vger.kernel.org
---
 scripts/Makefile | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile b/scripts/Makefile
index 16bcb8087899..1715adcd8f81 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -8,7 +8,11 @@
 # conmakehash:   Create chartable
 # conmakehash:  Create arrays for initializing the kernel console tables
 
+PKG_CONFIG?= pkg-config
+
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include
+CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || echo 
-lcrypto)
+CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null)
 
 hostprogs-$(CONFIG_BUILD_BIN2C)  += bin2c
 hostprogs-$(CONFIG_KALLSYMS) += kallsyms
@@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += 
insert-sys-cert
 
 HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
+HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
+HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
 
 always := $(hostprogs-y) $(hostprogs-m)
 
-- 
2.23.0






Re: Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …

2019-08-02 Thread Rolf Eike Beer
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
> On Thu, Jun 6, 2019 at 8:59 PM Greg KH  wrote:
> > "manually fixing it up" means "hacked it to pieces" to me, I have no
> > idea what the end result really was :)
> > 
> > If someone wants to send me some patches I can actually apply, that
> > would be best...
> 
> I will give it a go whenever I get some free time :)

I fear this has never happened, did it?

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

2019-08-02 Thread Rolf Eike Beer
Nathan Chancellor wrote:
> On Fri, Aug 02, 2019 at 09:57:45AM +0200, Greg KH wrote:
> > On Thu, Jun 06, 2019 at 09:11:00AM +0200, Rolf Eike Beer wrote:
> > > Nick Desaulniers wrote:
> > > > On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers
> > > > 
> > > >  wrote:
> > > > > On Wed, Jun 5, 2019 at 9:26 AM Greg KH  
wrote:
> > > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote:
> > > > > > > I decided to dig out a toy project which uses a DragonBoard
> > > > > > > 410c. This
> > > > > > > has
> > > > > > > been "running" with kernel 4.9, which I would keep this way for
> > > > > > > unrelated
> > > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but
> > > > > > > it was
> > > > > > > buildable, which was good enough.
> > > > > > > 
> > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly
> > > > > > > fail:
> > > > > > > 
> > > > > > > aarch64-unknown-linux-gnueabi-ld:
> > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in
> > > > > > > function
> > > > > > > `handle_kernel_image':
> > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-s
> > > > > > > tub.c:
> > > > > > > 63:
> > > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_'
> > > > > > > aarch64-unknown-linux-gnueabi-ld:
> > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o):
> > > > > > > relocation
> > > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol
> > > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can
> > > > > > > not
> > > > > > > be used when making a shared object; recompile with -fPIC
> > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-s
> > > > > > > tub.c:
> > > > > > > 63:
> > > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation
> > > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target
> > > > > > > 'vmlinux'
> > > > > > > failed -make[1]: *** [vmlinux] Error 1
> > > > > > > 
> > > > > > > This is caused by commit
> > > > > > > 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from
> > > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be),
> > > > > > > reverting
> > > > > > > this commit fixes the build.

> > Did this ever get resolved, or is it still an issue?
> 
> This appears to have been resolved by commit 8fca3c364683 ("efi/libstub:
> Unify command line param parsing") in 4.9.181. I can build defconfig +
> CONFIG_RANDOMIZE_BASE without any issues.

I can confirm that 4.9.186 builds without issues with my original config.

Thanks for paying attention.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH v3] scripts: use pkg-config to locate libcrypto

2019-07-03 Thread Rolf Eike Beer
> From 71e19be4247fbaa2540dfb321e2b148234680a13 Mon Sep 17 00:00:00 2001
> From: Rolf Eike Beer 
> Date: Thu, 22 Nov 2018 16:40:49 +0100
> Subject: [PATCH] scripts: use pkg-config to locate libcrypto
> 
> Otherwise build fails if the headers are not in the default location. While
> at it also ask pkg-config for the libs, with fallback to the existing
> value.

Ping?
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH] parisc: asm: psw.h: missing header guard

2019-06-23 Thread Rolf Eike Beer
Denis Efremov wrote:
> The psw.h header file contains #ifndef directive of the guard,
> but the complimentary #define directive is missing. The patch
> adds the appropriate #define to fix the header guard.
> 
> Signed-off-by: Denis Efremov 
> ---
>  arch/parisc/include/asm/psw.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/parisc/include/asm/psw.h b/arch/parisc/include/asm/psw.h
> index 76c301146c31..7a175e866ed0 100644
> --- a/arch/parisc/include/asm/psw.h
> +++ b/arch/parisc/include/asm/psw.h
> @@ -1,5 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  #ifndef _PARISC_PSW_H
> +#define _PARISC_PSW_H
> 
> 
>  #define  PSW_I   0x0001

You could have removed one of the 2 empty lines then.

Eike

signature.asc
Description: This is a digitally signed message part.


riscv: remove unused barrier defines

2019-06-17 Thread Rolf Eike Beer
>From 947f9fe483dc6561e31f0d2294eb6fedc1d6d9bb Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer 
Date: Mon, 17 Jun 2019 14:22:37 +0200
Subject: [PATCH] riscv: remove unused barrier defines

They were introduced in fab957c11efe2f405e08b9f0d080524bc2631428 long after
2e39465abc4b7856a0ea6fcf4f6b4668bb5db877 removed the remnants of all previous
instances from the tree.

Signed-off-by: Rolf Eike Beer 
---
 arch/riscv/include/asm/bitops.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/riscv/include/asm/bitops.h b/arch/riscv/include/asm/bitops.h
index 3943be480af0..396a3303c537 100644
--- a/arch/riscv/include/asm/bitops.h
+++ b/arch/riscv/include/asm/bitops.h
@@ -15,11 +15,6 @@
 #include 
 #include 
 
-#ifndef smp_mb__before_clear_bit
-#define smp_mb__before_clear_bit()  smp_mb()
-#define smp_mb__after_clear_bit()   smp_mb()
-#endif /* smp_mb__before_clear_bit */
-
 #include 
 #include 
 #include 
-- 
2.21.0
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source




[PATCH RESEND] H8300: remove unused barrier defines

2019-06-17 Thread Rolf Eike Beer
>From c907e749917f430e3dc62048985c8419778572f9 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer 
Date: Fri, 14 Jul 2017 11:19:08 +0200
Subject: [PATCH] H8300: remove unused barrier defines

They were introduced in d2a5f4999f6c211adf30d9788349e13988d6f2a7 long after
2e39465abc4b7856a0ea6fcf4f6b4668bb5db877 removed the remnants of all previous
instances from the tree.

Signed-off-by: Rolf Eike Beer 
---
 arch/h8300/include/asm/bitops.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/h8300/include/asm/bitops.h b/arch/h8300/include/asm/bitops.h
index 647a83bd40b7..7aa16c732aa9 100644
--- a/arch/h8300/include/asm/bitops.h
+++ b/arch/h8300/include/asm/bitops.h
@@ -51,12 +51,6 @@ static inline void FNAME(int nr, volatile unsigned long 
*addr)   \
}   \
 }
 
-/*
- * clear_bit() doesn't provide any barrier for the compiler.
- */
-#define smp_mb__before_clear_bit() barrier()
-#define smp_mb__after_clear_bit()  barrier()
-
 H8300_GEN_BITOP(set_bit,"bset")
 H8300_GEN_BITOP(clear_bit,  "bclr")
 H8300_GEN_BITOP(change_bit, "bnot")
-- 
2.21.0
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source




Re: Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …

2019-06-12 Thread Rolf Eike Beer
Am Donnerstag, 6. Juni 2019, 20:59:00 CEST schrieb Greg KH:
> On Thu, Jun 06, 2019 at 08:25:28PM +0200, Miguel Ojeda wrote:
> > On Thu, Jun 6, 2019 at 5:29 PM Greg KH  wrote:
> > > And if you want this, you should look at how the backports to 4.14.y
> > > worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use
> > > feature checks instead of version checks"), as that gets really messy...
> > 
> > I am confused -- I interpreted Rolf's message as reporting that he
> > already successfully built 4.9 by applying a6e60d84989f
> > ("include/linux/module.h: copy __init/__exit attrs to
> > init/cleanup_module") and manually fixing it up. But maybe I am
> > completely wrong... :-)
> 
> "manually fixing it up" means "hacked it to pieces" to me, I have no
> idea what the end result really was :)
> 
> If someone wants to send me some patches I can actually apply, that
> would be best...

Hi all,

the patch I actually used was this:

diff --git a/include/linux/module.h b/include/linux/module.h
index 8fa38d3e7538..f5bc4c046461 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -129,13 +129,13 @@ extern void cleanup_module(void);
 #define module_init(initfn)\
static inline initcall_t __maybe_unused __inittest(void)
\
{ return initfn; }  \
-   int init_module(void) __attribute__((alias(#initfn)));
+   int init_module(void) __attribute__((__copy__(initfn))) 
__attribute__((alias(#initfn)));
 
 /* This is only required if you want to be unloadable. */
 #define module_exit(exitfn)\
static inline exitcall_t __maybe_unused __exittest(void)
\
{ return exitfn; }  \
-   void cleanup_module(void) __attribute__((alias(#exitfn)));
+   void cleanup_module(void) __attribute__((__copy__(exitfn))) 
__attribute__((alias(#exitfn)));
 
 #endif
 

So the final question is: do we want 4.9.x to be buildable with gcc 9.x? If
yes then we can probably get this patches into shape.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …

2019-06-06 Thread Rolf Eike Beer
/linux-4.9.180/include/linux/platform_device.h:228:2: note: in 
expansion of macro 'module_driver'
  228 |  module_driver(__platform_driver, platform_driver_register, \
  |  ^
/tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1:
 note: in expansion of macro 'module_platform_driver'
  581 | module_platform_driver(mpc52xx_lpbfifo_driver);
  | ^~
In file included from 
/tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/io.h:27,
 from /tmp/e2/build/linux-4.9.180/include/linux/io.h:25,
 from /tmp/e2/build/linux-4.9.180/include/linux/irq.h:24,
 from 
/tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/hardirq.h:5,
 from /tmp/e2/build/linux-4.9.180/include/linux/hardirq.h:8,
 from /tmp/e2/build/linux-4.9.180/include/linux/interrupt.h:12,
 from 
/tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:12:
/tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:24:
 note: 'init_module' target declared here
  581 | module_platform_driver(mpc52xx_lpbfifo_driver);
  |^~
/tmp/e2/build/linux-4.9.180/include/linux/device.h:1351:19: note: in definition 
of macro 'module_driver'
 1351 | static int __init __driver##_init(void) \
  |   ^~~~
/tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1:
 note: in expansion of macro 'module_platform_driver'
  581 | module_platform_driver(mpc52xx_lpbfifo_driver);
  | ^~


So this needs a6e60d84989fa0e91db7f236eda40453b0e44afa, which needs 
c0d9782f5b6d7157635ae2fd782a4b27d55a6013, which can't be applied cleanly 
because a3f8a30f3f0079c7edfc72e329eee8594fb3e3cb is missing in 4.9.

I have applied a6e60d84989fa0e91db7f236eda40453b0e44afa and modified it to 
directly use __attribute__((__copy__(initfn))) and (exitfn), which fixes the 
build for me.

Greetings,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

2019-06-06 Thread Rolf Eike Beer
Ard Biesheuvel wrote:
> On Thu, 6 Jun 2019 at 09:50, Rolf Eike Beer  wrote:
> > Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer:
> > > Greg KH wrote:
> > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote:
> > > > > I decided to dig out a toy project which uses a DragonBoard 410c.
> > > > > This
> > > > > has
> > > > > been "running" with kernel 4.9, which I would keep this way for
> > > > > unrelated
> > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it
> > > > > was
> > > > > buildable, which was good enough.
> > > > > 
> > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail:
> > > > > 
> > > > > aarch64-unknown-linux-gnueabi-ld:
> > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in
> > > > > function
> > > > > `handle_kernel_image':
> > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.
> > > > > c:63
> > > > > 
> > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_'
> > > > > aarch64-unknown-linux-gnueabi-ld:
> > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation
> > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol
> > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not
> > > > > be
> > > > > used when making a shared object; recompile with -fPIC
> > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.
> > > > > c:63
> > > > > 
> > > > > (.init.text+0xc): dangerous relocation: unsupported relocation
> > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target
> > > > > 'vmlinux'
> > > > > failed -make[1]: *** [vmlinux] Error 1
> > > > > 
> > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca
> > > > > from
> > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be),
> > > > > reverting
> > > > > this commit fixes the build.
> > > > > 
> > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as
> > > > > 9.1.0.
> > > > > See
> > > > > the attached .config for reference.
> > > > > 
> > > > > If you have questions or patches just ping me.
> > > > 
> > > > Does Linus's latest tree also fail for you (or 5.1)?
> > > 
> > > 5.1.7 with the same config as before and "make olddefconfig" builds for
> > > me.
> > 
> > Just for the fun of it: both 4.19 and 4.19.48 also work.

> Could you please check whether patch
> 60f38de7a8d4e816100ceafd1b382df52527bd50 applies cleanly, and whether
> it fixes the problem? Thanks.

The part in drivers/firmware/efi/libstub/arm-stub.c needs to be applied by 
hand, but afterwards things build fine.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


[PATCH v3] scripts: use pkg-config to locate libcrypto

2019-06-06 Thread Rolf Eike Beer
>From 71e19be4247fbaa2540dfb321e2b148234680a13 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer 
Date: Thu, 22 Nov 2018 16:40:49 +0100
Subject: [PATCH] scripts: use pkg-config to locate libcrypto

Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer 
Cc: sta...@vger.kernel.org # 4.19.x
---
 scripts/Makefile | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

v2: add CRYPTO_LIBS and CRYPTO_CFLAGS
v3: fix fallback -lcrypto

diff --git a/scripts/Makefile b/scripts/Makefile
index 9d442ee050bd..9489c3b550df 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -8,7 +8,11 @@
 # conmakehash:   Create chartable
 # conmakehash:  Create arrays for initializing the kernel console tables
 
+PKG_CONFIG?= pkg-config
+
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include
+CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || echo 
-lcrypto)
+CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null)
 
 hostprogs-$(CONFIG_BUILD_BIN2C)  += bin2c
 hostprogs-$(CONFIG_KALLSYMS) += kallsyms
@@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += 
insert-sys-cert
 
 HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
+HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
+HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
 
 always := $(hostprogs-y) $(hostprogs-m)
 
-- 
2.21.0


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source




Re: [PATCH v2 RESEND] scripts: use pkg-config to locate libcrypto

2019-06-06 Thread Rolf Eike Beer
David Woodhouse wrote:
> On Thu, 2019-06-06 at 09:55 +0200, Rolf Eike Beer wrote:
> > +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null ||
> > -lcrypto)
> That's going to run:
> 
> $ pkg-config --libs libcrypto || -lcrypto
> 
> 
> If libcrypto.pc isn't there, it's going to get this:
> 
> 
> -lcrypto: command not found
> 
> I think you meant:
> 
> +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || echo
> -lcrypto)

Doh! Thanks, v3 in a minute.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


[PATCH v2 RESEND] scripts: use pkg-config to locate libcrypto

2019-06-06 Thread Rolf Eike Beer
>From cca931322233827dc21c7609f21f4042d78f220e Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer 
Date: Thu, 22 Nov 2018 16:40:49 +0100
Subject: scripts: use pkg-config to locate libcrypto

Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer 
Cc: sta...@vger.kernel.org # 4.19.x
---
 scripts/Makefile | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

Last time I got notice about a build error with 4.19.3, but it works fine for
me on top of both 4.19 and 4.19.48.

diff --git a/scripts/Makefile b/scripts/Makefile
index 9d442ee050bd..bd2a30b43f28 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -8,7 +8,11 @@
 # conmakehash:   Create chartable
 # conmakehash:  Create arrays for initializing the kernel console tables
 
+PKG_CONFIG?= pkg-config
+
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include
+CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || -lcrypto)
+CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null)
 
 hostprogs-$(CONFIG_BUILD_BIN2C)  += bin2c
 hostprogs-$(CONFIG_KALLSYMS) += kallsyms
@@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += 
insert-sys-cert
 
 HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
+HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
+HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
 
 always := $(hostprogs-y) $(hostprogs-m)
 
-- 
2.21.0






Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

2019-06-06 Thread Rolf Eike Beer
Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer:
> Greg KH wrote:
> > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote:
> > > I decided to dig out a toy project which uses a DragonBoard 410c. This
> > > has
> > > been "running" with kernel 4.9, which I would keep this way for
> > > unrelated
> > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was
> > > buildable, which was good enough.
> > > 
> > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail:
> > > 
> > > aarch64-unknown-linux-gnueabi-ld:
> > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function
> > > `handle_kernel_image':
> > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63
> > > :
> > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_'
> > > aarch64-unknown-linux-gnueabi-ld:
> > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation
> > > R_AARCH64_ADR_PREL_PG_HI21 against symbol
> > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be
> > > used when making a shared object; recompile with -fPIC
> > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63
> > > :
> > > (.init.text+0xc): dangerous relocation: unsupported relocation
> > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux'
> > > failed -make[1]: *** [vmlinux] Error 1
> > > 
> > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from
> > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be),
> > > reverting
> > > this commit fixes the build.
> > > 
> > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0.
> > > See
> > > the attached .config for reference.
> > > 
> > > If you have questions or patches just ping me.
> > 
> > Does Linus's latest tree also fail for you (or 5.1)?
> 
> 5.1.7 with the same config as before and "make olddefconfig" builds for me.

Just for the fun of it: both 4.19 and 4.19.48 also work.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH linux] objtool: fix pkg-config query in case of cross-compilation

2019-04-11 Thread Rolf Eike Beer
Am Donnerstag, 11. April 2019, 11:26:12 CEST schrieb Nicolas Dichtel:
> Le 11/04/2019 à 10:52, Rolf Eike Beer a écrit :
> > Am Donnerstag, 11. April 2019, 10:39:40 CEST schrieb Nicolas Dichtel:
> >> In case of cross-compilation, there may be two pkg-config tools, one for
> >> the host and one for the target. Enable to override the default name.
> >> 
> >> Fixes: 056d28d135bc ("objtool: Query pkg-config for libelf location")
> >> Signed-off-by: Nicolas Dichtel 
> > 
> > If you do that, you have to fix a lot of other places, too. This starts in
> > scripts/kconfig/ and also includes e.g. tools/testing/.
> > 
> > Usually you have pkg-config for host and ${target_platform}-pkg-config for
> > the
> My use case was for buildroot, which define pkg-config and host-pkgconf. In
> fact, I've just seen that a buildroot patch was accepted for this problem:
> https://patchwork.ozlabs.org/patch/1081379/

I agree that it makes sense to have both host and target pkg-config 
configurable. But IMHO that must happen in a central place (i.e. ./Makefile), 
and it has to be used everywhere. Currently PKG_CONFIG is defined at multiple 
places, sometimes host, sometimes target, and often pkg-config is called 
directly, also mixing both usages.

So, IMHO, if you want to fix this: fix it once and for all in the whole 
kernel, not just one place. What I have introduced was just the same as 
kconfig is using to find the dependencies for some of the *config variants, so 
this usecase would break for you anyway, although I don't think anyone in 
buildroot will notice this.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH linux] objtool: fix pkg-config query in case of cross-compilation

2019-04-11 Thread Rolf Eike Beer
Am Donnerstag, 11. April 2019, 10:39:40 CEST schrieb Nicolas Dichtel:
> In case of cross-compilation, there may be two pkg-config tools, one for
> the host and one for the target. Enable to override the default name.
> 
> Fixes: 056d28d135bc ("objtool: Query pkg-config for libelf location")
> Signed-off-by: Nicolas Dichtel 

If you do that, you have to fix a lot of other places, too. This starts in 
scripts/kconfig/ and also includes e.g. tools/testing/.

Usually you have pkg-config for host and ${target_platform}-pkg-config for the 
target, and the PKG_CONFIG variable for the target, usually initialized to $
(CROSS_COMPILE)pkg-config. I have sent a bunch of patches to replace the usage 
of plain pkg-config at several places with the cross-aware version, but sadly 
a lot of them have not been picked up. It break cross-building tests basically 
all the time. One example is here: 

https://marc.info/?l=linux-acpi=153544231529066=2

For me it looks like you are trying to go into the wrong direction.

Greetings,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


[tip:core/urgent] objtool: Query pkg-config for libelf location

2019-03-28 Thread tip-bot for Rolf Eike Beer
Commit-ID:  056d28d135bca0b1d0908990338e00e9dadaf057
Gitweb: https://git.kernel.org/tip/056d28d135bca0b1d0908990338e00e9dadaf057
Author: Rolf Eike Beer 
AuthorDate: Tue, 26 Mar 2019 12:48:39 -0500
Committer:  Thomas Gleixner 
CommitDate: Thu, 28 Mar 2019 13:32:01 +0100

objtool: Query pkg-config for libelf location

If it is not in the default location, compilation fails at several points.

Signed-off-by: Rolf Eike Beer 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Thomas Gleixner 
Cc: sta...@vger.kernel.org
Link: 
https://lkml.kernel.org/r/91a25e992566a7968fedc89ec80e7f4c83ad0548.1553622500.git.jpoim...@redhat.com

---
 Makefile   | 4 +++-
 tools/objtool/Makefile | 7 +--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index c0a34064c574..eef3d3f87c3b 100644
--- a/Makefile
+++ b/Makefile
@@ -950,9 +950,11 @@ mod_sign_cmd = true
 endif
 export mod_sign_cmd
 
+HOST_LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf)
+
 ifdef CONFIG_STACK_VALIDATION
   has_libelf := $(call try-run,\
-   echo "int main() {}" | $(HOSTCC) -xc -o /dev/null -lelf -,1,0)
+   echo "int main() {}" | $(HOSTCC) -xc -o /dev/null 
$(HOST_LIBELF_LIBS) -,1,0)
   ifeq ($(has_libelf),1)
 objtool_target := tools/objtool FORCE
   else
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index c9d038f91af6..53f8be0f4a1f 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -25,14 +25,17 @@ LIBSUBCMD   = $(LIBSUBCMD_OUTPUT)libsubcmd.a
 OBJTOOL:= $(OUTPUT)objtool
 OBJTOOL_IN := $(OBJTOOL)-in.o
 
+LIBELF_FLAGS := $(shell pkg-config libelf --cflags 2>/dev/null)
+LIBELF_LIBS  := $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf)
+
 all: $(OBJTOOL)
 
 INCLUDES := -I$(srctree)/tools/include \
-I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
-I$(srctree)/tools/objtool/arch/$(ARCH)/include
 WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
-CFLAGS   += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES)
-LDFLAGS  += -lelf $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
+CFLAGS   += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) 
$(LIBELF_FLAGS)
+LDFLAGS  += $(LIBELF_LIBS) $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
 
 # Allow old libelf to be used:
 elfshdr := $(shell echo '$(pound)include ' | $(CC) $(CFLAGS) -x c -E 
- | grep elf_getshdr)


[PATCH v2] objtool: query pkg-config for libelf location

2019-03-20 Thread Rolf Eike Beer
If it is not in the default location compilation would fail at several points.

Signed-off-by: Rolf Eike Beer 
---
Changes in v2:
  -also hide stderr when querying cflags
  -use ":=" assignment as in other places in that file

 Makefile   | 4 +++-
 tools/objtool/Makefile | 7 +--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 99c0530489ef..32caf30e0d79 100644
--- a/Makefile
+++ b/Makefile
@@ -950,9 +950,11 @@ mod_sign_cmd = true
 endif
 export mod_sign_cmd
 
+HOST_LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf)
+
 ifdef CONFIG_STACK_VALIDATION
   has_libelf := $(call try-run,\
-   echo "int main() {}" | $(HOSTCC) -xc -o /dev/null -lelf -,1,0)
+   echo "int main() {}" | $(HOSTCC) -xc -o /dev/null 
$(HOST_LIBELF_LIBS) -,1,0)
   ifeq ($(has_libelf),1)
 objtool_target := tools/objtool FORCE
   else
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index c9d038f91af6..53f8be0f4a1f 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -25,14 +25,17 @@ LIBSUBCMD   = $(LIBSUBCMD_OUTPUT)libsubcmd.a
 OBJTOOL:= $(OUTPUT)objtool
 OBJTOOL_IN := $(OBJTOOL)-in.o
 
+LIBELF_FLAGS := $(shell pkg-config libelf --cflags 2>/dev/null)
+LIBELF_LIBS  := $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf)
+
 all: $(OBJTOOL)
 
 INCLUDES := -I$(srctree)/tools/include \
-I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
-I$(srctree)/tools/objtool/arch/$(ARCH)/include
 WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
-CFLAGS   += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES)
-LDFLAGS  += -lelf $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
+CFLAGS   += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) 
$(LIBELF_FLAGS)
+LDFLAGS  += $(LIBELF_LIBS) $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
 
 # Allow old libelf to be used:
 elfshdr := $(shell echo '$(pound)include ' | $(CC) $(CFLAGS) -x c -E 
- | grep elf_getshdr)
-- 
2.21.0

-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH] objtool: query pkg-config for libelf location

2019-03-20 Thread Rolf Eike Beer
Josh Poimboeuf wrote:
> On Tue, Mar 19, 2019 at 08:20:12AM +0100, Rolf Eike Beer wrote:

> > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> > index c9d038f91af6..0c8dd1609348 100644
> > --- a/tools/objtool/Makefile
> > +++ b/tools/objtool/Makefile
> > @@ -25,14 +25,17 @@ LIBSUBCMD   = $(LIBSUBCMD_OUTPUT)libsubcmd.a
> > 
> >  OBJTOOL:= $(OUTPUT)objtool
> >  OBJTOOL_IN := $(OBJTOOL)-in.o
> > 
> > +LIBELF_FLAGS = $(shell pkg-config libelf --cflags)
> > +LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf)
> 
> Should LIBELF_FLAGS also pipe stderr to /dev/null?

Probably. New version in a minute.

Thanks,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


[PATCH] objtool: query pkg-config for libelf location

2019-03-19 Thread Rolf Eike Beer
If it is not in the default location compilation would fail at several points.

Signed-off-by: Rolf Eike Beer 
---
 Makefile   | 4 +++-
 tools/objtool/Makefile | 7 +--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 9ef547fc7ffe..666b52c1c5f4 100644
--- a/Makefile
+++ b/Makefile
@@ -940,9 +940,11 @@ mod_sign_cmd = true
 endif
 export mod_sign_cmd
 
+HOST_LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf)
+
 ifdef CONFIG_STACK_VALIDATION
   has_libelf := $(call try-run,\
-   echo "int main() {}" | $(HOSTCC) -xc -o /dev/null -lelf -,1,0)
+   echo "int main() {}" | $(HOSTCC) -xc -o /dev/null 
$(HOST_LIBELF_LIBS) -,1,0)
   ifeq ($(has_libelf),1)
 objtool_target := tools/objtool FORCE
   else
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index c9d038f91af6..0c8dd1609348 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -25,14 +25,17 @@ LIBSUBCMD   = $(LIBSUBCMD_OUTPUT)libsubcmd.a
 OBJTOOL:= $(OUTPUT)objtool
 OBJTOOL_IN := $(OBJTOOL)-in.o
 
+LIBELF_FLAGS = $(shell pkg-config libelf --cflags)
+LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf)
+
 all: $(OBJTOOL)
 
 INCLUDES := -I$(srctree)/tools/include \
-I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
-I$(srctree)/tools/objtool/arch/$(ARCH)/include
 WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
-CFLAGS   += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES)
-LDFLAGS  += -lelf $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
+CFLAGS   += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) 
$(LIBELF_FLAGS)
+LDFLAGS  += $(LIBELF_LIBS) $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
 
 # Allow old libelf to be used:
 elfshdr := $(shell echo '$(pound)include ' | $(CC) $(CFLAGS) -x c -E 
- | grep elf_getshdr)
-- 
2.21.0


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source





Re: [PATCH v2] scripts: use pkg-config to locate libcrypto

2018-12-14 Thread Rolf Eike Beer
Am Montag, 26. November 2018, 10:13:23 CET schrieb Rolf Eike Beer:
> Am Samstag, 24. November 2018, 06:53:39 CET schrieb Sasha Levin:
> > Hi,
> > 
> > [This is an automated email]
> > 
> > This commit has been processed because it contains a -stable tag.
> > The stable tag indicates that it's relevant for the following trees: all
> > 
> > The bot has tested the following trees: v4.19.3, v4.14.82, v4.9.138,
> > v4.4.164, v3.18.126.
> > 
> > v4.19.3: Build failed! Errors:
> > collect2: error: ld returned 1 exit status
> 
> This sounds like it could actually be a problem, can you point me to the
> full log, please?
> 
> > v4.14.82: Failed to apply! Possible dependencies:
> > Unable to calculate
> 
> This would either need 8377bd2b9ee1be35b39b5523f640a2b75ddd7c4e as well, or
> a modified patch. Manually fixing this up should be trivial. Just tell me
> which way you prefer.

Ping?
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH v2] scripts: use pkg-config to locate libcrypto

2018-11-26 Thread Rolf Eike Beer
Am Samstag, 24. November 2018, 06:53:39 CET schrieb Sasha Levin:
> Hi,
> 
> [This is an automated email]
> 
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
> 
> The bot has tested the following trees: v4.19.3, v4.14.82, v4.9.138,
> v4.4.164, v3.18.126.
> 
> v4.19.3: Build failed! Errors:
> collect2: error: ld returned 1 exit status

This sounds like it could actually be a problem, can you point me to the full 
log, please?

> v4.14.82: Failed to apply! Possible dependencies:
> Unable to calculate

This would either need 8377bd2b9ee1be35b39b5523f640a2b75ddd7c4e as well, or a 
modified patch. Manually fixing this up should be trivial. Just tell me which 
way you prefer.

Greetings,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH v2] scripts: use pkg-config to locate libcrypto

2018-11-26 Thread Rolf Eike Beer
Am Samstag, 24. November 2018, 06:53:39 CET schrieb Sasha Levin:
> Hi,
> 
> [This is an automated email]
> 
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
> 
> The bot has tested the following trees: v4.19.3, v4.14.82, v4.9.138,
> v4.4.164, v3.18.126.
> 
> v4.19.3: Build failed! Errors:
> collect2: error: ld returned 1 exit status

This sounds like it could actually be a problem, can you point me to the full 
log, please?

> v4.14.82: Failed to apply! Possible dependencies:
> Unable to calculate

This would either need 8377bd2b9ee1be35b39b5523f640a2b75ddd7c4e as well, or a 
modified patch. Manually fixing this up should be trivial. Just tell me which 
way you prefer.

Greetings,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

signature.asc
Description: This is a digitally signed message part.


[PATCH v2] scripts: use pkg-config to locate libcrypto

2018-11-22 Thread Rolf Eike Beer
Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer 
Cc: sta...@vger.kernel.org
---
 scripts/Makefile | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile b/scripts/Makefile
index ece52ff20171..769fa6b7b685 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -8,7 +8,11 @@
 # conmakehash:   Create chartable
 # conmakehash:  Create arrays for initializing the kernel console tables
 
+PKG_CONFIG?= pkg-config
+
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include
+CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || -lcrypto)
+CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null)
 
 hostprogs-$(CONFIG_BUILD_BIN2C)  += bin2c
 hostprogs-$(CONFIG_KALLSYMS) += kallsyms
@@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += 
insert-sys-cert
 
 HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
+HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
+HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
 
 always := $(hostprogs-y) $(hostprogs-m)
 
-- 
2.19.1

-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source




[PATCH v2] scripts: use pkg-config to locate libcrypto

2018-11-22 Thread Rolf Eike Beer
Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer 
Cc: sta...@vger.kernel.org
---
 scripts/Makefile | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile b/scripts/Makefile
index ece52ff20171..769fa6b7b685 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -8,7 +8,11 @@
 # conmakehash:   Create chartable
 # conmakehash:  Create arrays for initializing the kernel console tables
 
+PKG_CONFIG?= pkg-config
+
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include
+CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || -lcrypto)
+CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null)
 
 hostprogs-$(CONFIG_BUILD_BIN2C)  += bin2c
 hostprogs-$(CONFIG_KALLSYMS) += kallsyms
@@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += 
insert-sys-cert
 
 HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
+HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
+HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
 
 always := $(hostprogs-y) $(hostprogs-m)
 
-- 
2.19.1

-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source




[PATCH] scripts: use pkg-config to locate libcrypto

2018-11-22 Thread Rolf Eike Beer
Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer 
Cc: sta...@vger.kernel.org
---
 scripts/Makefile | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile b/scripts/Makefile
index ece52ff20171..a303f478a65b 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -8,6 +8,8 @@
 # conmakehash:   Create chartable
 # conmakehash:  Create arrays for initializing the kernel console tables
 
+PKG_CONFIG?= pkg-config
+
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include
 
 hostprogs-$(CONFIG_BUILD_BIN2C)  += bin2c
@@ -23,8 +25,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += 
insert-sys-cert
 
 HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || 
-lcrypto)
+HOSTCFLAGS_extract-cert.o = $(shell $(PKG_CONFIG) --cflags libcrypto 2> 
/dev/null)
+HOSTLDLIBS_extract-cert = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null 
|| -lcrypto)
 
 always := $(hostprogs-y) $(hostprogs-m)
 
-- 
2.19.1


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source




[PATCH] scripts: use pkg-config to locate libcrypto

2018-11-22 Thread Rolf Eike Beer
Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer 
Cc: sta...@vger.kernel.org
---
 scripts/Makefile | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile b/scripts/Makefile
index ece52ff20171..a303f478a65b 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -8,6 +8,8 @@
 # conmakehash:   Create chartable
 # conmakehash:  Create arrays for initializing the kernel console tables
 
+PKG_CONFIG?= pkg-config
+
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include
 
 hostprogs-$(CONFIG_BUILD_BIN2C)  += bin2c
@@ -23,8 +25,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += 
insert-sys-cert
 
 HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || 
-lcrypto)
+HOSTCFLAGS_extract-cert.o = $(shell $(PKG_CONFIG) --cflags libcrypto 2> 
/dev/null)
+HOSTLDLIBS_extract-cert = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null 
|| -lcrypto)
 
 always := $(hostprogs-y) $(hostprogs-m)
 
-- 
2.19.1


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source




Re: [PATCH v2 6/7] drivers: oprofile: Avoids building driver from direct make command

2018-09-27 Thread Rolf Eike Beer

Am 2018-09-27 13:23, schrieb Leonardo Bras:

Hello Rolf,

On Thu, Sep 27, 2018 at 3:34 AM, Rolf Eike Beer  
wrote:
Am Donnerstag, 27. September 2018, 03:41:38 CEST schrieb Leonardo 
Brás:

Creates new Makefile to avoid building driver if
'make drivers/oprofile/' is called directly.

This driver is usually built from arch/$ARCH and seems to have
no meaning building alone.

Signed-off-by: Leonardo Brás 
---
 drivers/oprofile/Makefile | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 drivers/oprofile/Makefile

diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile
new file mode 100644
index ..acaed2ad6eee
--- /dev/null
+++ b/drivers/oprofile/Makefile
@@ -0,0 +1,2 @@
+#Does nothing, since the source is called from arch/$ARCH/ tree.
+


Now there is a blank line where it does not need to be.

Eike


Oh, it's a Makefile, and as all text files, it have to end with 
newline.

If I am wrong, please let me know.


No, that's fine. But it means it has to have one LF after "tree.". It 
had none, now it hat 2.


Eike


Re: [PATCH v2 6/7] drivers: oprofile: Avoids building driver from direct make command

2018-09-27 Thread Rolf Eike Beer

Am 2018-09-27 13:23, schrieb Leonardo Bras:

Hello Rolf,

On Thu, Sep 27, 2018 at 3:34 AM, Rolf Eike Beer  
wrote:
Am Donnerstag, 27. September 2018, 03:41:38 CEST schrieb Leonardo 
Brás:

Creates new Makefile to avoid building driver if
'make drivers/oprofile/' is called directly.

This driver is usually built from arch/$ARCH and seems to have
no meaning building alone.

Signed-off-by: Leonardo Brás 
---
 drivers/oprofile/Makefile | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 drivers/oprofile/Makefile

diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile
new file mode 100644
index ..acaed2ad6eee
--- /dev/null
+++ b/drivers/oprofile/Makefile
@@ -0,0 +1,2 @@
+#Does nothing, since the source is called from arch/$ARCH/ tree.
+


Now there is a blank line where it does not need to be.

Eike


Oh, it's a Makefile, and as all text files, it have to end with 
newline.

If I am wrong, please let me know.


No, that's fine. But it means it has to have one LF after "tree.". It 
had none, now it hat 2.


Eike


Re: [PATCH v2 1/7] drivers: dio: Avoids building driver if CONFIG_DIO is disabled

2018-09-27 Thread Rolf Eike Beer
Am Donnerstag, 27. September 2018, 03:39:56 CEST schrieb Leonardo Brás:
> Avoids building driver if 'make drivers/dio/' is called and
> CONFIG_DIO is disabled.
> 
> Signed-off-by: Leonardo Brás 
> ---
>  drivers/dio/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dio/Makefile b/drivers/dio/Makefile
> index ae92d17083f2..f5cffe232448 100644
> --- a/drivers/dio/Makefile
> +++ b/drivers/dio/Makefile
> @@ -2,4 +2,4 @@
>  # Makefile for the linux kernel.
>  #
> 
> -obj-y := dio.o dio-driver.o dio-sysfs.o
> +obj-$(CONFIG_DIO) := dio.o dio-driver.o dio-sysfs.o
> \ No newline at end of file
  ^^

One more.


signature.asc
Description: This is a digitally signed message part.


Re: [PATCH v2 1/7] drivers: dio: Avoids building driver if CONFIG_DIO is disabled

2018-09-27 Thread Rolf Eike Beer
Am Donnerstag, 27. September 2018, 03:39:56 CEST schrieb Leonardo Brás:
> Avoids building driver if 'make drivers/dio/' is called and
> CONFIG_DIO is disabled.
> 
> Signed-off-by: Leonardo Brás 
> ---
>  drivers/dio/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dio/Makefile b/drivers/dio/Makefile
> index ae92d17083f2..f5cffe232448 100644
> --- a/drivers/dio/Makefile
> +++ b/drivers/dio/Makefile
> @@ -2,4 +2,4 @@
>  # Makefile for the linux kernel.
>  #
> 
> -obj-y := dio.o dio-driver.o dio-sysfs.o
> +obj-$(CONFIG_DIO) := dio.o dio-driver.o dio-sysfs.o
> \ No newline at end of file
  ^^

One more.


signature.asc
Description: This is a digitally signed message part.


Re: [PATCH v2 6/7] drivers: oprofile: Avoids building driver from direct make command

2018-09-27 Thread Rolf Eike Beer
Am Donnerstag, 27. September 2018, 03:41:38 CEST schrieb Leonardo Brás:
> Creates new Makefile to avoid building driver if
> 'make drivers/oprofile/' is called directly.
> 
> This driver is usually built from arch/$ARCH and seems to have
> no meaning building alone.
> 
> Signed-off-by: Leonardo Brás 
> ---
>  drivers/oprofile/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>  create mode 100644 drivers/oprofile/Makefile
> 
> diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile
> new file mode 100644
> index ..acaed2ad6eee
> --- /dev/null
> +++ b/drivers/oprofile/Makefile
> @@ -0,0 +1,2 @@
> +#Does nothing, since the source is called from arch/$ARCH/ tree.
> +

Now there is a blank line where it does not need to be.

Eike


signature.asc
Description: This is a digitally signed message part.


Re: [PATCH v2 6/7] drivers: oprofile: Avoids building driver from direct make command

2018-09-27 Thread Rolf Eike Beer
Am Donnerstag, 27. September 2018, 03:41:38 CEST schrieb Leonardo Brás:
> Creates new Makefile to avoid building driver if
> 'make drivers/oprofile/' is called directly.
> 
> This driver is usually built from arch/$ARCH and seems to have
> no meaning building alone.
> 
> Signed-off-by: Leonardo Brás 
> ---
>  drivers/oprofile/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>  create mode 100644 drivers/oprofile/Makefile
> 
> diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile
> new file mode 100644
> index ..acaed2ad6eee
> --- /dev/null
> +++ b/drivers/oprofile/Makefile
> @@ -0,0 +1,2 @@
> +#Does nothing, since the source is called from arch/$ARCH/ tree.
> +

Now there is a blank line where it does not need to be.

Eike


signature.asc
Description: This is a digitally signed message part.


Re: [PATCH 6/7] drivers: oprofile: Avoids building driver from direct make command

2018-09-26 Thread Rolf Eike Beer

Leonardo Brás wrote:

Creates new Makefile to avoid building driver if
'make drivers/oprofile/' is called directly.

This driver is usually built from arch/$ARCH and seems to have
no meaning building alone.

Signed-off-by: Leonardo Brás 
---
 drivers/oprofile/Makefile | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 drivers/oprofile/Makefile

diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile
new file mode 100644
index ..6b36c93e9762
--- /dev/null
+++ b/drivers/oprofile/Makefile
@@ -0,0 +1 @@
+#Does nothing, since the source is called from arch/$ARCH/ tree.
\ No newline at end of file

^

Is that intentional or bogus?

Eike


Re: [PATCH 6/7] drivers: oprofile: Avoids building driver from direct make command

2018-09-26 Thread Rolf Eike Beer

Leonardo Brás wrote:

Creates new Makefile to avoid building driver if
'make drivers/oprofile/' is called directly.

This driver is usually built from arch/$ARCH and seems to have
no meaning building alone.

Signed-off-by: Leonardo Brás 
---
 drivers/oprofile/Makefile | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 drivers/oprofile/Makefile

diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile
new file mode 100644
index ..6b36c93e9762
--- /dev/null
+++ b/drivers/oprofile/Makefile
@@ -0,0 +1 @@
+#Does nothing, since the source is called from arch/$ARCH/ tree.
\ No newline at end of file

^

Is that intentional or bogus?

Eike


Re: [PATCH] video/fbdev/stifb: Delete an error message for a failed memory allocation in stifb_init_fb()

2017-11-24 Thread Rolf Eike Beer
Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 24 Nov 2017 22:22:06 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/video/fbdev/stifb.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
> index 6ded5c198998..fe217a2f7d21 100644
> --- a/drivers/video/fbdev/stifb.c
> +++ b/drivers/video/fbdev/stifb.c
> @@ -1126,10 +1126,8 @@ static int __init stifb_init_fb(struct sti_struct
> *sti, int bpp_pref) int bpp, xres, yres;
> 
>   fb = kzalloc(sizeof(*fb), GFP_ATOMIC);
> - if (!fb) {
> - printk(KERN_ERR "stifb: Could not allocate stifb structure\n");
> + if (!fb)
>   return -ENODEV;
> - }
> 
>   info = >info;

This should be -ENOMEM.

Eike

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH] video/fbdev/stifb: Delete an error message for a failed memory allocation in stifb_init_fb()

2017-11-24 Thread Rolf Eike Beer
Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 24 Nov 2017 22:22:06 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/video/fbdev/stifb.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
> index 6ded5c198998..fe217a2f7d21 100644
> --- a/drivers/video/fbdev/stifb.c
> +++ b/drivers/video/fbdev/stifb.c
> @@ -1126,10 +1126,8 @@ static int __init stifb_init_fb(struct sti_struct
> *sti, int bpp_pref) int bpp, xres, yres;
> 
>   fb = kzalloc(sizeof(*fb), GFP_ATOMIC);
> - if (!fb) {
> - printk(KERN_ERR "stifb: Could not allocate stifb structure\n");
> + if (!fb)
>   return -ENODEV;
> - }
> 
>   info = >info;

This should be -ENOMEM.

Eike

signature.asc
Description: This is a digitally signed message part.


[PATCH 2/3] selftests: do not require bash to run bpf tests

2016-12-14 Thread Rolf Eike Beer
>From b9d6c1b7427d708ef2d4d57aac17b700b3694d71 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer <eike-ker...@sf-tec.de>
Date: Wed, 14 Dec 2016 09:58:12 +0100
Subject: [PATCH 2/3] selftests: do not require bash to run bpf tests

Nothing in this minimal script seems to require bash. We often run these tests
on embedded devices where the only shell available is the busybox ash.

Signed-off-by: Rolf Eike Beer <e...@emlix.com>
---
 tools/testing/selftests/bpf/test_kmod.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/test_kmod.sh 
b/tools/testing/selftests/bpf/test_kmod.sh
index 92e627a..6d58cca 100755
--- a/tools/testing/selftests/bpf/test_kmod.sh
+++ b/tools/testing/selftests/bpf/test_kmod.sh
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 SRC_TREE=../../../../
 
-- 
2.8.3


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix – smart embedded open source



[PATCH 2/3] selftests: do not require bash to run bpf tests

2016-12-14 Thread Rolf Eike Beer
>From b9d6c1b7427d708ef2d4d57aac17b700b3694d71 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer 
Date: Wed, 14 Dec 2016 09:58:12 +0100
Subject: [PATCH 2/3] selftests: do not require bash to run bpf tests

Nothing in this minimal script seems to require bash. We often run these tests
on embedded devices where the only shell available is the busybox ash.

Signed-off-by: Rolf Eike Beer 
---
 tools/testing/selftests/bpf/test_kmod.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/test_kmod.sh 
b/tools/testing/selftests/bpf/test_kmod.sh
index 92e627a..6d58cca 100755
--- a/tools/testing/selftests/bpf/test_kmod.sh
+++ b/tools/testing/selftests/bpf/test_kmod.sh
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 SRC_TREE=../../../../
 
-- 
2.8.3


-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix – smart embedded open source



Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

2016-04-26 Thread Rolf Eike Beer
Arnd Bergmann wrote:
> The asm-generic/rtc.h header can now be included by
> architectures that provide their own set_rtc_time/get_rtc_time
> macros, letting us remove most of the common contents in
> the powerpc implementation.

parisc in this case.

Eike

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

2016-04-26 Thread Rolf Eike Beer
Arnd Bergmann wrote:
> The asm-generic/rtc.h header can now be included by
> architectures that provide their own set_rtc_time/get_rtc_time
> macros, letting us remove most of the common contents in
> the powerpc implementation.

parisc in this case.

Eike

signature.asc
Description: This is a digitally signed message part.


4.3.3: error when plugging in USB stick

2016-01-05 Thread Rolf Eike Beer
[199328.874819] [ cut here ]
[199328.874825] WARNING: CPU: 3 PID: 15727 at ../block/genhd.c:626 
add_disk+0x43e/0x480()
[199328.874827] Modules linked in: hid_cherry usb_storage cdc_phonet phonet 
hid_generic usbhid fuse ctr ccm af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 
nf_log_common xt_LOG xt_limit bnep ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_d
efrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter 
ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast 
nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack 
ip6table_filter ip6_tables x_tab
les drbg ansi_cprng dm_crypt nls_iso8859_1 nls_cp437 vfat fat btusb btintel 
btbcm btrtl bluetooth arc4 joydev rtsx_pci_ms memstick rtsx_pci_sdmmc mmc_core 
iTCO_wdt iTCO_vendor_support iwlmvm mac80211 pcspkr serio_raw iwlwifi cfg8021
1 snd_hda_codec_via rfkill snd_hda_codec_hdmi rtsx_pci snd_hda_codec_generic 
x86_pkg_temp_thermal intel_powerclamp
[199328.874868]  coretemp kvm_intel kvm lpc_ich crct10dif_pclmul crc32_pclmul 
crc32c_intel mfd_core i2c_i801 aesni_intel ablk_helper cryptd lrw gf128mul 
glue_helper aes_x86_64 shpchp wmi fjes xhci_pci xhci_hcd tpm_infineon tpm_tis t
pm snd_hda_intel snd_hda_codec mei_me snd_hda_core e1000e snd_hwdep mei ptp 
snd_pcm pps_core snd_seq snd_timer snd_seq_device snd soundcore sg battery ac 
efivarfs i915 drm_kms_helper ehci_pci ehci_hcd drm usbcore fb_sys_fops sysimgb
lt usb_common sysfillrect syscopyarea i2c_algo_bit thermal video button 
processor scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac raid456 
async_raid6_recov async_pq async_xor xor async_memcpy async_tx raid6_pq raid10 
raid1 raid0
 md_mod dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod
[199328.874916] CPU: 3 PID: 15727 Comm: kworker/u16:2 Not tainted 
4.3.3-2.gdb72752-default #1
[199328.874917] Hardware name: Notebook W740SU  
/W740SU  , BIOS 4.6.5 07/05/2013
[199328.874923] Workqueue: events_unbound async_run_entry_fn
[199328.874925]  81a75772 8800ae937d18 81376259 

[199328.874927]  8800ae937d50 8107afc2 88020d3a4000 
88020d3a4080
[199328.874930]  88020d3a400c 8802145bc9d0 8802172ef480 
8800ae937d60
[199328.874932] Call Trace:
[199328.874941]  [] try_stack_unwind+0x175/0x190
[199328.874948]  [] dump_trace+0x69/0x3a0
[199328.874951]  [] show_trace_log_lvl+0x4b/0x60
[199328.874954]  [] show_stack_log_lvl+0x10c/0x180
[199328.874957]  [] show_stack+0x25/0x50
[199328.874962]  [] dump_stack+0x4b/0x72
[199328.874967]  [] warn_slowpath_common+0x82/0xc0
[199328.874971]  [] warn_slowpath_null+0x1a/0x20
[199328.874973]  [] add_disk+0x43e/0x480
[199328.874980]  [] sd_probe_async+0x115/0x1d0
[199328.874984]  [] async_run_entry_fn+0x48/0x150
[199328.874990]  [] process_one_work+0x159/0x470
[199328.874993]  [] worker_thread+0x48/0x4a0
[199328.874996]  [] kthread+0xc9/0xe0
[199328.875001]  [] ret_from_fork+0x3f/0x70
[199328.876721] DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70

[199328.876722] Leftover inexact backtrace:

[199328.876725]  [] ? kthread_worker_fn+0x170/0x170
[199328.876727] ---[ end trace 0335892bcf3ba8c0 ]---


signature.asc
Description: This is a digitally signed message part.


4.3.3: error when plugging in USB stick

2016-01-05 Thread Rolf Eike Beer
[199328.874819] [ cut here ]
[199328.874825] WARNING: CPU: 3 PID: 15727 at ../block/genhd.c:626 
add_disk+0x43e/0x480()
[199328.874827] Modules linked in: hid_cherry usb_storage cdc_phonet phonet 
hid_generic usbhid fuse ctr ccm af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 
nf_log_common xt_LOG xt_limit bnep ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_d
efrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter 
ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast 
nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack 
ip6table_filter ip6_tables x_tab
les drbg ansi_cprng dm_crypt nls_iso8859_1 nls_cp437 vfat fat btusb btintel 
btbcm btrtl bluetooth arc4 joydev rtsx_pci_ms memstick rtsx_pci_sdmmc mmc_core 
iTCO_wdt iTCO_vendor_support iwlmvm mac80211 pcspkr serio_raw iwlwifi cfg8021
1 snd_hda_codec_via rfkill snd_hda_codec_hdmi rtsx_pci snd_hda_codec_generic 
x86_pkg_temp_thermal intel_powerclamp
[199328.874868]  coretemp kvm_intel kvm lpc_ich crct10dif_pclmul crc32_pclmul 
crc32c_intel mfd_core i2c_i801 aesni_intel ablk_helper cryptd lrw gf128mul 
glue_helper aes_x86_64 shpchp wmi fjes xhci_pci xhci_hcd tpm_infineon tpm_tis t
pm snd_hda_intel snd_hda_codec mei_me snd_hda_core e1000e snd_hwdep mei ptp 
snd_pcm pps_core snd_seq snd_timer snd_seq_device snd soundcore sg battery ac 
efivarfs i915 drm_kms_helper ehci_pci ehci_hcd drm usbcore fb_sys_fops sysimgb
lt usb_common sysfillrect syscopyarea i2c_algo_bit thermal video button 
processor scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac raid456 
async_raid6_recov async_pq async_xor xor async_memcpy async_tx raid6_pq raid10 
raid1 raid0
 md_mod dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod
[199328.874916] CPU: 3 PID: 15727 Comm: kworker/u16:2 Not tainted 
4.3.3-2.gdb72752-default #1
[199328.874917] Hardware name: Notebook W740SU  
/W740SU  , BIOS 4.6.5 07/05/2013
[199328.874923] Workqueue: events_unbound async_run_entry_fn
[199328.874925]  81a75772 8800ae937d18 81376259 

[199328.874927]  8800ae937d50 8107afc2 88020d3a4000 
88020d3a4080
[199328.874930]  88020d3a400c 8802145bc9d0 8802172ef480 
8800ae937d60
[199328.874932] Call Trace:
[199328.874941]  [] try_stack_unwind+0x175/0x190
[199328.874948]  [] dump_trace+0x69/0x3a0
[199328.874951]  [] show_trace_log_lvl+0x4b/0x60
[199328.874954]  [] show_stack_log_lvl+0x10c/0x180
[199328.874957]  [] show_stack+0x25/0x50
[199328.874962]  [] dump_stack+0x4b/0x72
[199328.874967]  [] warn_slowpath_common+0x82/0xc0
[199328.874971]  [] warn_slowpath_null+0x1a/0x20
[199328.874973]  [] add_disk+0x43e/0x480
[199328.874980]  [] sd_probe_async+0x115/0x1d0
[199328.874984]  [] async_run_entry_fn+0x48/0x150
[199328.874990]  [] process_one_work+0x159/0x470
[199328.874993]  [] worker_thread+0x48/0x4a0
[199328.874996]  [] kthread+0xc9/0xe0
[199328.875001]  [] ret_from_fork+0x3f/0x70
[199328.876721] DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70

[199328.876722] Leftover inexact backtrace:

[199328.876725]  [] ? kthread_worker_fn+0x170/0x170
[199328.876727] ---[ end trace 0335892bcf3ba8c0 ]---


signature.asc
Description: This is a digitally signed message part.


GPF after s2disk since 4.3 (inode_permission+0x1a/0x50)

2015-12-27 Thread Rolf Eike Beer
Hi all,

I see these backtraces whenever I wake up my laptop from s2disk. This has been 
no problem in 4.2.x. All relevant filesystems I have are ext4. I regularly do 
s2ram and have not seen any problems with that.

Any ideas?

Greetings,

Eike

general protection fault:  [#1] PREEMPT SMP 
Modules linked in: hid_generic usbhid uinput cdc_phonet phonet usb_storage 
rfcomm cmac ecb ctr ccm fuse af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 
nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 
nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter 
ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast 
nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack 
ip6table_filter ip6_tables x_tables bnep drbg ansi_cprng dm_crypt nls_iso8859_1 
nls_cp437 vfat fat arc4 iwlmvm mac80211 x86_pkg_temp_thermal intel_powerclamp 
coretemp btusb btintel btbcm btrtl bluetooth kvm_intel snd_hda_codec_hdmi 
iwlwifi rtsx_pci_ms snd_hda_codec_via rtsx_pci_sdmmc snd_hda_codec_generic 
iTCO_wdt mmc_core memstick iTCO_vendor_support cfg80211 rfkill rtsx_pci kvm 
snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq snd_timer 
lpc_ich snd_seq_device mfd_core shpchp snd fjes soundcore crct10dif_pclmul 
crc32_pclmul mei_me crc32c_intel mei aesni_intel joydev pcspkr ablk_helper 
cryptd lrw i2c_i801 gf128mul glue_helper aes_x86_64 e1000e ptp serio_raw 
pps_core xhci_pci xhci_hcd wmi tpm_infineon tpm_tis tpm battery ac sg efivarfs 
i915 ehci_pci ehci_hcd drm_kms_helper drm usbcore fb_sys_fops sysimgblt 
sysfillrect usb_common syscopyarea i2c_algo_bit thermal video button pr
ocessor scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac raid456 
async_raid6_recov async_pq async_xor xor async_memcpy async_tx raid6_pq raid10 
raid1 raid0 md_mod dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod
CPU: 7 PID: 12631 Comm: pm-powersave Not tainted 4.3.3-2.gdb72752-default #1
Hardware name: Notebook W740SU  
/W740SU  , BIOS 4.6.5 07/05/2013
task: 8800a8ea4080 ti: 88005819 task.ti: 88005819
RIP: 0010:[]  [] inode_permission+0x1a/0x50
RSP: 0018:880058193db0  EFLAGS: 00010202
RAX: 00d500d4 RBX: 8801fafbf080 RCX: 0005
RDX: 0004 RSI: 0002 RDI: 88003632bd88
RBP: 880058193db0 R08: 0001 R09: 8800c476f02a
R10: 8992c6d7 R11: 880034f2dd10 R12: 0001
R13: 880058193e4c R14: 88003632bd88 R15: 
FS:  7f06336a3700() GS:88021fbc() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f0632ad0790 CR3: 000201384000 CR4: 001406e0
Stack:
 880058193e00 8163df4f 0017 0800
 8800d945e0e0 880034f2dcd8 8801fafbf080 0017
 0800 7ffd01ba5050 880058193e78 8163e3f8
Call Trace:
 [] unix_find_other+0x4f/0x1f0
 [] unix_stream_connect+0xf8/0x470
 [] SYSC_connect+0xd9/0x110
 [] SyS_connect+0xe/0x10
 [] entry_SYSCALL_64_fastpath+0x16/0x75
DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x16/0x75

Leftover inexact backtrace:

Code: 4c 89 ef e8 59 4f 49 00 e9 74 ff ff ff 0f 1f 40 00 0f 1f 44 00 00 55 40 
f6 
c6 02 48 89 e5 75 07 e8 3c ff ff ff 5d c3 48 8b 47 28  40 50 01 74 ef 0f b7 
07 89 c2 66 81 e2 00 d0 66 81 fa 00 80 
RIP  [] inode_permission+0x1a/0x50
 RSP 
---[ end trace 634ddee63c66edbb ]---


signature.asc
Description: This is a digitally signed message part.


GPF after s2disk since 4.3 (inode_permission+0x1a/0x50)

2015-12-27 Thread Rolf Eike Beer
Hi all,

I see these backtraces whenever I wake up my laptop from s2disk. This has been 
no problem in 4.2.x. All relevant filesystems I have are ext4. I regularly do 
s2ram and have not seen any problems with that.

Any ideas?

Greetings,

Eike

general protection fault:  [#1] PREEMPT SMP 
Modules linked in: hid_generic usbhid uinput cdc_phonet phonet usb_storage 
rfcomm cmac ecb ctr ccm fuse af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 
nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 
nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter 
ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast 
nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack 
ip6table_filter ip6_tables x_tables bnep drbg ansi_cprng dm_crypt nls_iso8859_1 
nls_cp437 vfat fat arc4 iwlmvm mac80211 x86_pkg_temp_thermal intel_powerclamp 
coretemp btusb btintel btbcm btrtl bluetooth kvm_intel snd_hda_codec_hdmi 
iwlwifi rtsx_pci_ms snd_hda_codec_via rtsx_pci_sdmmc snd_hda_codec_generic 
iTCO_wdt mmc_core memstick iTCO_vendor_support cfg80211 rfkill rtsx_pci kvm 
snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq snd_timer 
lpc_ich snd_seq_device mfd_core shpchp snd fjes soundcore crct10dif_pclmul 
crc32_pclmul mei_me crc32c_intel mei aesni_intel joydev pcspkr ablk_helper 
cryptd lrw i2c_i801 gf128mul glue_helper aes_x86_64 e1000e ptp serio_raw 
pps_core xhci_pci xhci_hcd wmi tpm_infineon tpm_tis tpm battery ac sg efivarfs 
i915 ehci_pci ehci_hcd drm_kms_helper drm usbcore fb_sys_fops sysimgblt 
sysfillrect usb_common syscopyarea i2c_algo_bit thermal video button pr
ocessor scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac raid456 
async_raid6_recov async_pq async_xor xor async_memcpy async_tx raid6_pq raid10 
raid1 raid0 md_mod dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod
CPU: 7 PID: 12631 Comm: pm-powersave Not tainted 4.3.3-2.gdb72752-default #1
Hardware name: Notebook W740SU  
/W740SU  , BIOS 4.6.5 07/05/2013
task: 8800a8ea4080 ti: 88005819 task.ti: 88005819
RIP: 0010:[]  [] inode_permission+0x1a/0x50
RSP: 0018:880058193db0  EFLAGS: 00010202
RAX: 00d500d4 RBX: 8801fafbf080 RCX: 0005
RDX: 0004 RSI: 0002 RDI: 88003632bd88
RBP: 880058193db0 R08: 0001 R09: 8800c476f02a
R10: 8992c6d7 R11: 880034f2dd10 R12: 0001
R13: 880058193e4c R14: 88003632bd88 R15: 
FS:  7f06336a3700() GS:88021fbc() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f0632ad0790 CR3: 000201384000 CR4: 001406e0
Stack:
 880058193e00 8163df4f 0017 0800
 8800d945e0e0 880034f2dcd8 8801fafbf080 0017
 0800 7ffd01ba5050 880058193e78 8163e3f8
Call Trace:
 [] unix_find_other+0x4f/0x1f0
 [] unix_stream_connect+0xf8/0x470
 [] SYSC_connect+0xd9/0x110
 [] SyS_connect+0xe/0x10
 [] entry_SYSCALL_64_fastpath+0x16/0x75
DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x16/0x75

Leftover inexact backtrace:

Code: 4c 89 ef e8 59 4f 49 00 e9 74 ff ff ff 0f 1f 40 00 0f 1f 44 00 00 55 40 
f6 
c6 02 48 89 e5 75 07 e8 3c ff ff ff 5d c3 48 8b 47 28  40 50 01 74 ef 0f b7 
07 89 c2 66 81 e2 00 d0 66 81 fa 00 80 
RIP  [] inode_permission+0x1a/0x50
 RSP 
---[ end trace 634ddee63c66edbb ]---


signature.asc
Description: This is a digitally signed message part.


Kconfig: remove comment about scsi_wait_scan module

2015-09-04 Thread Rolf Eike Beer
This module has been removed in commit 6072609d9bb91ff54aee3ef29304bd5b4fc88aae
([SCSI] Remove scsi_wait_scan module), so this module is gone since 3.6.

Signed-off-by: Rolf Eike Beer 
---
 drivers/scsi/Kconfig | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 95f7a76..d2f480b 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -242,13 +242,6 @@ config SCSI_SCAN_ASYNC
  system continues booting, and even probe devices on different
  busses in parallel, leading to a significant speed-up.
 
- If you have built SCSI as modules, enabling this option can
- be a problem as the devices may not have been found by the
- time your system expects them to have been.  You can load the
- scsi_wait_scan module to ensure that all scans have completed.
- If you build your SCSI drivers into the kernel, then everything
- will work fine if you say Y here.
-
  You can override this choice by specifying "scsi_mod.scan=sync"
  or async on the kernel's command line.
 
-- 
2.5.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[Doc] class_find_device: fix reference to argument "match"

2015-09-04 Thread Rolf Eike Beer
There is no argument "fn".

Signed-off-by: Rolf Eike Beer 
---
 drivers/base/class.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/class.c b/drivers/base/class.c
index 6e81088..71059e3 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -406,7 +406,7 @@ EXPORT_SYMBOL_GPL(class_for_each_device);
  *
  * Note, you will need to drop the reference with put_device() after use.
  *
- * @fn is allowed to do anything including calling back into class
+ * @match is allowed to do anything including calling back into class
  * code.  There's no locking restriction.
  */
 struct device *class_find_device(struct class *class, struct device *start,
-- 
2.5.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[Doc] class_find_device: fix reference to argument "match"

2015-09-04 Thread Rolf Eike Beer
There is no argument "fn".

Signed-off-by: Rolf Eike Beer <eike-ker...@sf-tec.de>
---
 drivers/base/class.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/class.c b/drivers/base/class.c
index 6e81088..71059e3 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -406,7 +406,7 @@ EXPORT_SYMBOL_GPL(class_for_each_device);
  *
  * Note, you will need to drop the reference with put_device() after use.
  *
- * @fn is allowed to do anything including calling back into class
+ * @match is allowed to do anything including calling back into class
  * code.  There's no locking restriction.
  */
 struct device *class_find_device(struct class *class, struct device *start,
-- 
2.5.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Kconfig: remove comment about scsi_wait_scan module

2015-09-04 Thread Rolf Eike Beer
This module has been removed in commit 6072609d9bb91ff54aee3ef29304bd5b4fc88aae
([SCSI] Remove scsi_wait_scan module), so this module is gone since 3.6.

Signed-off-by: Rolf Eike Beer <eike-ker...@sf-tec.de>
---
 drivers/scsi/Kconfig | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 95f7a76..d2f480b 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -242,13 +242,6 @@ config SCSI_SCAN_ASYNC
  system continues booting, and even probe devices on different
  busses in parallel, leading to a significant speed-up.
 
- If you have built SCSI as modules, enabling this option can
- be a problem as the devices may not have been found by the
- time your system expects them to have been.  You can load the
- scsi_wait_scan module to ensure that all scans have completed.
- If you build your SCSI drivers into the kernel, then everything
- will work fine if you say Y here.
-
  You can override this choice by specifying "scsi_mod.scan=sync"
  or async on the kernel's command line.
 
-- 
2.5.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [3.18 regression]: machine hangs on s2ram

2015-01-12 Thread Rolf Eike Beer
> Since I upgraded to 3.18 my machine (W740SU based laptop) hangs when I do
> s2ram. For me it looks like the preparations work, but the machine is then
> not switched off. The only way to recover is a hard powercycle. Since the
> machine has no serial port I can't look what's happening then, but the logs
> do not contain anything suspicious until the point when the machine locks
> up.

Meanwhile I see this on a different machine (Core i7 desktop), too. I'll see 
if I can dig out any more information there.

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.


Re: [3.18 regression]: machine hangs on s2ram

2015-01-12 Thread Rolf Eike Beer
 Since I upgraded to 3.18 my machine (W740SU based laptop) hangs when I do
 s2ram. For me it looks like the preparations work, but the machine is then
 not switched off. The only way to recover is a hard powercycle. Since the
 machine has no serial port I can't look what's happening then, but the logs
 do not contain anything suspicious until the point when the machine locks
 up.

Meanwhile I see this on a different machine (Core i7 desktop), too. I'll see 
if I can dig out any more information there.

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.


[3.18 regression]: machine hangs on s2ram

2014-12-21 Thread Rolf Eike Beer
Since I upgraded to 3.18 my machine (W740SU based laptop) hangs when I do 
s2ram. For me it looks like the preparations work, but the machine is then not 
switched off. The only way to recover is a hard powercycle. Since the machine 
has no serial port I can't look what's happening then, but the logs do not 
contain anything suspicious until the point when the machine locks up.

Greetings,

Eike

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.18.1-1.g5f2f35e-desktop (geeko@buildhost) (gcc 
version 4.8.3 20141208 [gcc-4_8-branch revision 218481] (SUSE Linux) ) #1 SMP 
PREEMPT Wed Dec 17 18:20:30 UTC 2014 (5f2f35e)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.18.1-1.g5f2f35e-desktop 
root=/dev/md0 resume=/dev/system/swap splash=silent quiet acpi_osi=Linux 
acpi_backlight=vendor showopts
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcb65bfff] usable
[0.00] BIOS-e820: [mem 0xcb65c000-0xcb662fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcb663000-0xcbe26fff] usable
[0.00] BIOS-e820: [mem 0xcbe27000-0xcc0d6fff] reserved
[0.00] BIOS-e820: [mem 0xcc0d7000-0xdb4e2fff] usable
[0.00] BIOS-e820: [mem 0xdb4e3000-0xdb841fff] reserved
[0.00] BIOS-e820: [mem 0xdb842000-0xdb89efff] usable
[0.00] BIOS-e820: [mem 0xdb89f000-0xdb9d3fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdb9d4000-0xdbffefff] reserved
[0.00] BIOS-e820: [mem 0xdbfff000-0xdbff] usable
[0.00] BIOS-e820: [mem 0xdd00-0xdf1f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021fdf] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by American Megatrends
[0.00] efi:  ACPI 2.0=0xdb9a7000  ACPI=0xdb9a7000  SMBIOS=0xdbf88598 
[0.00] efi: mem00: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x-0x00058000) (0MB)
[0.00] efi: mem01: [Reserved   |   |  |  |  |   |WB|WT|WC|UC] 
range=[0x00058000-0x00059000) (0MB)
[0.00] efi: mem02: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x00059000-0x0009e000) (0MB)
[0.00] efi: mem03: [Reserved   |   |  |  |  |   |WB|WT|WC|UC] 
range=[0x0009e000-0x000a) (0MB)
[0.00] efi: mem04: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x0010-0x015be000) (20MB)
[0.00] efi: mem05: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x015be000-0x0200) (10MB)
[0.00] efi: mem06: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x0200-0x034be000) (20MB)
[0.00] efi: mem07: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x034be000-0x350dc000) (796MB)
[0.00] efi: mem08: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x350dc000-0x36866000) (23MB)
[0.00] efi: mem09: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x36866000-0x91f07000) (1462MB)
[0.00] efi: mem10: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x91f07000-0xc81f4000) (866MB)
[0.00] efi: mem11: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0xc81f4000-0xcb63e000) (52MB)
[0.00] efi: mem12: [Loader Code|   |  |  |  |   |WB|WT|WC|UC] 
range=[0xcb63e000-0xcb65c000) (0MB)
[0.00] efi: mem13: [ACPI Memory NVS|   |  |  |  |   |WB|WT|WC|UC] 
range=[0xcb65c000-0xcb663000) (0MB)
[0.00] efi: mem14: [Boot Data  |   |  |  |  |   |WB|WT|WC|UC] 
range=[0xcb663000-0xcb7b4000) (1MB)
[0.00] efi: mem15: [Boot Code  |   |  |  |  |   |WB|WT|WC|UC] 
range=[0xcb7b4000-0xcbde7000) 

[3.18 regression]: machine hangs on s2ram

2014-12-21 Thread Rolf Eike Beer
Since I upgraded to 3.18 my machine (W740SU based laptop) hangs when I do 
s2ram. For me it looks like the preparations work, but the machine is then not 
switched off. The only way to recover is a hard powercycle. Since the machine 
has no serial port I can't look what's happening then, but the logs do not 
contain anything suspicious until the point when the machine locks up.

Greetings,

Eike

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.18.1-1.g5f2f35e-desktop (geeko@buildhost) (gcc 
version 4.8.3 20141208 [gcc-4_8-branch revision 218481] (SUSE Linux) ) #1 SMP 
PREEMPT Wed Dec 17 18:20:30 UTC 2014 (5f2f35e)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.18.1-1.g5f2f35e-desktop 
root=/dev/md0 resume=/dev/system/swap splash=silent quiet acpi_osi=Linux 
acpi_backlight=vendor showopts
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcb65bfff] usable
[0.00] BIOS-e820: [mem 0xcb65c000-0xcb662fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcb663000-0xcbe26fff] usable
[0.00] BIOS-e820: [mem 0xcbe27000-0xcc0d6fff] reserved
[0.00] BIOS-e820: [mem 0xcc0d7000-0xdb4e2fff] usable
[0.00] BIOS-e820: [mem 0xdb4e3000-0xdb841fff] reserved
[0.00] BIOS-e820: [mem 0xdb842000-0xdb89efff] usable
[0.00] BIOS-e820: [mem 0xdb89f000-0xdb9d3fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdb9d4000-0xdbffefff] reserved
[0.00] BIOS-e820: [mem 0xdbfff000-0xdbff] usable
[0.00] BIOS-e820: [mem 0xdd00-0xdf1f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021fdf] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by American Megatrends
[0.00] efi:  ACPI 2.0=0xdb9a7000  ACPI=0xdb9a7000  SMBIOS=0xdbf88598 
[0.00] efi: mem00: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x-0x00058000) (0MB)
[0.00] efi: mem01: [Reserved   |   |  |  |  |   |WB|WT|WC|UC] 
range=[0x00058000-0x00059000) (0MB)
[0.00] efi: mem02: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x00059000-0x0009e000) (0MB)
[0.00] efi: mem03: [Reserved   |   |  |  |  |   |WB|WT|WC|UC] 
range=[0x0009e000-0x000a) (0MB)
[0.00] efi: mem04: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x0010-0x015be000) (20MB)
[0.00] efi: mem05: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x015be000-0x0200) (10MB)
[0.00] efi: mem06: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x0200-0x034be000) (20MB)
[0.00] efi: mem07: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x034be000-0x350dc000) (796MB)
[0.00] efi: mem08: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x350dc000-0x36866000) (23MB)
[0.00] efi: mem09: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x36866000-0x91f07000) (1462MB)
[0.00] efi: mem10: [Loader Data|   |  |  |  |   |WB|WT|WC|UC] 
range=[0x91f07000-0xc81f4000) (866MB)
[0.00] efi: mem11: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] 
range=[0xc81f4000-0xcb63e000) (52MB)
[0.00] efi: mem12: [Loader Code|   |  |  |  |   |WB|WT|WC|UC] 
range=[0xcb63e000-0xcb65c000) (0MB)
[0.00] efi: mem13: [ACPI Memory NVS|   |  |  |  |   |WB|WT|WC|UC] 
range=[0xcb65c000-0xcb663000) (0MB)
[0.00] efi: mem14: [Boot Data  |   |  |  |  |   |WB|WT|WC|UC] 
range=[0xcb663000-0xcb7b4000) (1MB)
[0.00] efi: mem15: [Boot Code  |   |  |  |  |   |WB|WT|WC|UC] 
range=[0xcb7b4000-0xcbde7000) 

Re: [PATCH -v5] random: introduce getrandom(2) system call

2014-07-30 Thread Rolf Eike Beer
Theodore Ts'o wrote:

It's me again, finding only one issue per cycle :/

>   EAGAIN  The requested entropy was not available, and
>   getentropy(2) would have blocked if GRND_BLOCK flag
>   was set.

"if GRND_NONBLOCK flag was not set"

Eike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH -v5] random: introduce getrandom(2) system call

2014-07-30 Thread Rolf Eike Beer
Theodore Ts'o wrote:

It's me again, finding only one issue per cycle :/

   EAGAIN  The requested entropy was not available, and
   getentropy(2) would have blocked if GRND_BLOCK flag
   was set.

if GRND_NONBLOCK flag was not set

Eike
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH -v4] random: introduce getrandom(2) system call

2014-07-22 Thread Rolf Eike Beer
>   EAGAIN  The requested entropy was not available, and the
>   getentropy(2) would have blocked if GRND_BLOCK flag
>   was set.

I think either "and the call to getentropy(2)" or "and getentropy(2)" here.

Greetings,

Eike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH -v4] random: introduce getrandom(2) system call

2014-07-22 Thread Rolf Eike Beer
   EAGAIN  The requested entropy was not available, and the
   getentropy(2) would have blocked if GRND_BLOCK flag
   was set.

I think either and the call to getentropy(2) or and getentropy(2) here.

Greetings,

Eike
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-18 Thread Rolf Eike Beer
Theodore Ts'o wrote:

> DESCRIPTION
> 
>   The system call getrandom() fills the buffer pointed to by buf
>   with up to buflen random bytes which can be used to seed user
>   space random number generators (i.e., DRBG's) or for other
>   cryptographic processes.  It should not be used Monte Carlo
>   simulations or for other probabilistic sampling applications.

The "for" looks misplaced, shouldn't this be "for Monte Carlo simulations or 
other ..."?

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-18 Thread Rolf Eike Beer
Theodore Ts'o wrote:

 DESCRIPTION
 
   The system call getrandom() fills the buffer pointed to by buf
   with up to buflen random bytes which can be used to seed user
   space random number generators (i.e., DRBG's) or for other
   cryptographic processes.  It should not be used Monte Carlo
   simulations or for other probabilistic sampling applications.

The for looks misplaced, shouldn't this be for Monte Carlo simulations or 
other ...?

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.


[3.15.0] Sun V240: soft lockup - CPU stuck

2014-06-13 Thread Rolf Eike Beer
I got this tonight while running a CMake dashboard build (that is where the
git command was invoked from). The machine has been running for weeks on
3.14 and I never saw this there. In case you need more information just ask.

Greetings,

Eike

[0.00] Linux version 3.15.0 (root@alrakis) (gcc version 4.7.3 (Gentoo 
4.7.3 p1.3) ) #1 SMP Tue Jun 10 11:26:55 CEST 2014
[…]
[242339.538940] git[1513]: segfault at f77d9b70 ip f78f6838 (rpc 
f7a3e0ac) sp f77d93e0 error 30001 in 
libc-2.17.so[f780+16a000]
[242360.548826] INFO: rcu_sched self-detected stall on CPU { 1}  (t=2101 
jiffies g=2435314 c=2435313 q=2249)
[242360.548847]   CPU[  0]: TSTATE[fa03] TPC[f7b4b0b4] 
TNPC[f7b4b0b8] TASK[openssl:26204]
[242360.548856]  TPC[f7b4b0b4] O7[0] I7[f7b49d44] RPC[f7b49d44]
[242360.548862] * CPU[  1]: TSTATE[11001600] TPC[004fb7c4] 
TNPC[004fb7c8] TASK[git:1513]
[242360.548896]  TPC[put_compound_page+0x4/0x260] 
O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x1bc/0x2a0] 
RPC[futex_wake+0x24/0x140]
[242361.678822] BUG: soft lockup - CPU#1 stuck for 22s! [git:1513]
[242361.756631] Modules linked in: ipv6 openpromfs libcrc32c multipath linear 
raid456 async_pq async_xor xor async_memcpy async_raid6_recov async_tx raid6_pq 
dm_snapshot dm_bufio dm_crypt dm_mirror dm_region_hash dm_log usb_storage sg
[242361.756678] CPU: 1 PID: 1513 Comm: git Not tainted 3.15.0 #1
[242361.756685] task: fc033a65cf00 ti: fc033c51c000 task.ti: 
fc033c51c000
[242361.756691] TSTATE: 004411001600 TPC: 004fb9a8 TNPC: 
004fb9ac Y: Not tainted
[242361.756699] TPC: 
[242361.756704] g0: 0001 g1:  g2: 0016 
g3: 
[242361.756709] g4: fc033a65cf00 g5: fc133c572000 g6: fc033c51c000 
g7: 00484048
[242361.756715] o0: 0016 o1: 01000275 o2: 0040 
o3: 0001
[242361.756720] o4: 01000275 o5: 00a8e080 sp: fc033c51ebe1 
ret_pc: 004fb95c
[242361.756727] RPC: 
[242361.756732] l0: ff80 l1: 0100 l2: fc033c360140 
l3: fc033c4c6008
[242361.756738] l4: f77da000 l5: fc033a0cef78 l6: f77da000 
l7: 0300
[242361.756743] i0: 01000275 i1: f77d9fff i2: 0001 
i3: 01000275001c
[242361.756749] i4:  i5: 01000275fb00 i6: fc033c51ec91 
i7: 004b519c
[242361.756755] I7: 
[242361.756759] Call Trace:
[242361.756765]  [004b519c] get_futex_key+0x1bc/0x2a0
[242361.756771]  [004b5f64] futex_wake+0x24/0x140
[242361.756777]  [004b7460] do_futex+0x100/0x9a0
[242361.756783]  [004b7d98] SyS_futex+0x98/0x1c0
[242361.756791]  [0045ee14] mm_release+0x74/0x100
[242361.756798]  [00462b78] do_exit+0xf8/0x920
[242361.756805]  [004634c8] do_group_exit+0x28/0xc0
[242361.756812]  [00471348] get_signal_to_deliver+0x128/0x520
[242361.756822]  [00448d94] do_signal32+0x14/0xae0
[242361.756832]  [0042ce3c] do_signal+0xdc/0x540
[242361.756838]  [0042daa0] do_notify_resume+0x40/0x60
[242361.756846]  [00404b04] __handle_signal+0xc/0x2c
[242423.588580] INFO: rcu_sched self-detected stall on CPU { 1}  (t=8405 
jiffies g=2435314 c=2435313 q=7340)
[242423.588597]   CPU[  0]: TSTATE[11001606] TPC[00493780] 
TNPC[00493784] TASK[eselect:1590]
[242423.588628]  TPC[task_tick_fair+0xc0/0x300] 
O7[task_tick_fair+0x38/0x300] I7[scheduler_tick+0x4c/0xc0] 
RPC[update_process_times+0x48/0x60]
[242423.588635] * CPU[  1]: TSTATE[004411001600] TPC[004539e8] 
TNPC[004539ec] TASK[git:1513]
[242423.588648]  TPC[get_user_pages_fast+0x1a8/0x360] 
O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x44/0x2a0] 
RPC[futex_wake+0x24/0x140]
[242486.628334] INFO: rcu_sched self-detected stall on CPU { 1}  (t=14709 
jiffies g=2435314 c=2435313 q=100069)
[242486.628350]   CPU[  0]: TSTATE[0044fa02] TPC[f79e2de0] 
TNPC[f79e2de4] TASK[ctest:2998]
[242486.628356]  TPC[f79e2de0] O7[f7caba24] I7[47ad64] RPC[478724]
[242486.628362] * CPU[  1]: TSTATE[004411001600] TPC[004539e8] 
TNPC[004539ec] TASK[git:1513]
[242486.628377]  TPC[get_user_pages_fast+0x1a8/0x360] 
O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x44/0x2a0] 
RPC[futex_wake+0x24/0x140]
[242519.442106] Crash[4150]: segfault at 0 ip 00010650 (rpc   
(null)) sp fffb7a60 error 30001 in Crash[1+2000]
[242549.668087] INFO: rcu_sched self-detected stall on CPU { 1}  (t=21013 
jiffies g=2435314 c=2435313 q=172509)
[242549.668103]   CPU[  0]: TSTATE[80001600] TPC[00659e90] 
TNPC[00659e94] TASK[rcu_sched:9]
[242549.668122]  TPC[cpumask_next_and+0x10/0x80] 

[3.15.0] Sun V240: soft lockup - CPU stuck

2014-06-13 Thread Rolf Eike Beer
I got this tonight while running a CMake dashboard build (that is where the
git command was invoked from). The machine has been running for weeks on
3.14 and I never saw this there. In case you need more information just ask.

Greetings,

Eike

[0.00] Linux version 3.15.0 (root@alrakis) (gcc version 4.7.3 (Gentoo 
4.7.3 p1.3) ) #1 SMP Tue Jun 10 11:26:55 CEST 2014
[…]
[242339.538940] git[1513]: segfault at f77d9b70 ip f78f6838 (rpc 
f7a3e0ac) sp f77d93e0 error 30001 in 
libc-2.17.so[f780+16a000]
[242360.548826] INFO: rcu_sched self-detected stall on CPU { 1}  (t=2101 
jiffies g=2435314 c=2435313 q=2249)
[242360.548847]   CPU[  0]: TSTATE[fa03] TPC[f7b4b0b4] 
TNPC[f7b4b0b8] TASK[openssl:26204]
[242360.548856]  TPC[f7b4b0b4] O7[0] I7[f7b49d44] RPC[f7b49d44]
[242360.548862] * CPU[  1]: TSTATE[11001600] TPC[004fb7c4] 
TNPC[004fb7c8] TASK[git:1513]
[242360.548896]  TPC[put_compound_page+0x4/0x260] 
O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x1bc/0x2a0] 
RPC[futex_wake+0x24/0x140]
[242361.678822] BUG: soft lockup - CPU#1 stuck for 22s! [git:1513]
[242361.756631] Modules linked in: ipv6 openpromfs libcrc32c multipath linear 
raid456 async_pq async_xor xor async_memcpy async_raid6_recov async_tx raid6_pq 
dm_snapshot dm_bufio dm_crypt dm_mirror dm_region_hash dm_log usb_storage sg
[242361.756678] CPU: 1 PID: 1513 Comm: git Not tainted 3.15.0 #1
[242361.756685] task: fc033a65cf00 ti: fc033c51c000 task.ti: 
fc033c51c000
[242361.756691] TSTATE: 004411001600 TPC: 004fb9a8 TNPC: 
004fb9ac Y: Not tainted
[242361.756699] TPC: put_compound_page+0x1e8/0x260
[242361.756704] g0: 0001 g1:  g2: 0016 
g3: 
[242361.756709] g4: fc033a65cf00 g5: fc133c572000 g6: fc033c51c000 
g7: 00484048
[242361.756715] o0: 0016 o1: 01000275 o2: 0040 
o3: 0001
[242361.756720] o4: 01000275 o5: 00a8e080 sp: fc033c51ebe1 
ret_pc: 004fb95c
[242361.756727] RPC: put_compound_page+0x19c/0x260
[242361.756732] l0: ff80 l1: 0100 l2: fc033c360140 
l3: fc033c4c6008
[242361.756738] l4: f77da000 l5: fc033a0cef78 l6: f77da000 
l7: 0300
[242361.756743] i0: 01000275 i1: f77d9fff i2: 0001 
i3: 01000275001c
[242361.756749] i4:  i5: 01000275fb00 i6: fc033c51ec91 
i7: 004b519c
[242361.756755] I7: get_futex_key+0x1bc/0x2a0
[242361.756759] Call Trace:
[242361.756765]  [004b519c] get_futex_key+0x1bc/0x2a0
[242361.756771]  [004b5f64] futex_wake+0x24/0x140
[242361.756777]  [004b7460] do_futex+0x100/0x9a0
[242361.756783]  [004b7d98] SyS_futex+0x98/0x1c0
[242361.756791]  [0045ee14] mm_release+0x74/0x100
[242361.756798]  [00462b78] do_exit+0xf8/0x920
[242361.756805]  [004634c8] do_group_exit+0x28/0xc0
[242361.756812]  [00471348] get_signal_to_deliver+0x128/0x520
[242361.756822]  [00448d94] do_signal32+0x14/0xae0
[242361.756832]  [0042ce3c] do_signal+0xdc/0x540
[242361.756838]  [0042daa0] do_notify_resume+0x40/0x60
[242361.756846]  [00404b04] __handle_signal+0xc/0x2c
[242423.588580] INFO: rcu_sched self-detected stall on CPU { 1}  (t=8405 
jiffies g=2435314 c=2435313 q=7340)
[242423.588597]   CPU[  0]: TSTATE[11001606] TPC[00493780] 
TNPC[00493784] TASK[eselect:1590]
[242423.588628]  TPC[task_tick_fair+0xc0/0x300] 
O7[task_tick_fair+0x38/0x300] I7[scheduler_tick+0x4c/0xc0] 
RPC[update_process_times+0x48/0x60]
[242423.588635] * CPU[  1]: TSTATE[004411001600] TPC[004539e8] 
TNPC[004539ec] TASK[git:1513]
[242423.588648]  TPC[get_user_pages_fast+0x1a8/0x360] 
O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x44/0x2a0] 
RPC[futex_wake+0x24/0x140]
[242486.628334] INFO: rcu_sched self-detected stall on CPU { 1}  (t=14709 
jiffies g=2435314 c=2435313 q=100069)
[242486.628350]   CPU[  0]: TSTATE[0044fa02] TPC[f79e2de0] 
TNPC[f79e2de4] TASK[ctest:2998]
[242486.628356]  TPC[f79e2de0] O7[f7caba24] I7[47ad64] RPC[478724]
[242486.628362] * CPU[  1]: TSTATE[004411001600] TPC[004539e8] 
TNPC[004539ec] TASK[git:1513]
[242486.628377]  TPC[get_user_pages_fast+0x1a8/0x360] 
O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x44/0x2a0] 
RPC[futex_wake+0x24/0x140]
[242519.442106] Crash[4150]: segfault at 0 ip 00010650 (rpc   
(null)) sp fffb7a60 error 30001 in Crash[1+2000]
[242549.668087] INFO: rcu_sched self-detected stall on CPU { 1}  (t=21013 
jiffies g=2435314 c=2435313 q=172509)
[242549.668103]   CPU[  0]: TSTATE[80001600] TPC[00659e90] 
TNPC[00659e94] TASK[rcu_sched:9]

Re: [Patch V2 0/9] I2C ACPI operation region handler support

2014-05-23 Thread Rolf Eike Beer
Lan Tianyu wrote:
> On 05/20/2014 10:17 PM, Rolf Eike Beer wrote:

> > It may be that I have taken the wrong ACPI files. This is the result of a
> > fresh run of acpidump, together with the most recent dmesg.log, just in
> > case I messed it up.
> 
>   I have check the log. I2C ACPI operation region targets to I2C 
> controller
> which has one ACPI node in the ACPI table and is associated with one I2C
> adapter. Graphic with one ACPI handle registers several I2C adapters. This
> causes attach data to the ACPI handle with the same handler several time.
> The ACPICA function will return ALREADY EXIST error code and causes the log
> you mentioned. There is no I2C ACPI operation region under graphic device
> node and so not break function. To avoid these noise logs, I make them only
> appear under dynamic debug mode in the my V3 patchset.

Hi,

thanks for the clarification.

Greetings,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source


signature.asc
Description: This is a digitally signed message part.


Re: [Patch V2 0/9] I2C ACPI operation region handler support

2014-05-23 Thread Rolf Eike Beer
Lan Tianyu wrote:
 On 05/20/2014 10:17 PM, Rolf Eike Beer wrote:

  It may be that I have taken the wrong ACPI files. This is the result of a
  fresh run of acpidump, together with the most recent dmesg.log, just in
  case I messed it up.
 
   I have check the log. I2C ACPI operation region targets to I2C 
 controller
 which has one ACPI node in the ACPI table and is associated with one I2C
 adapter. Graphic with one ACPI handle registers several I2C adapters. This
 causes attach data to the ACPI handle with the same handler several time.
 The ACPICA function will return ALREADY EXIST error code and causes the log
 you mentioned. There is no I2C ACPI operation region under graphic device
 node and so not break function. To avoid these noise logs, I make them only
 appear under dynamic debug mode in the my V3 patchset.

Hi,

thanks for the clarification.

Greetings,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source


signature.asc
Description: This is a digitally signed message part.


Re: [Patch V2 0/9] I2C ACPI operation region handler support

2014-05-13 Thread Rolf Eike Beer
Am Montag, 28. April 2014, 22:27:39 schrieb Lan Tianyu:
> ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation
> region. It allows ACPI aml code able to access such kind of devices to
> implement some ACPI standard method.
> 
> On the Asus T100TA, Bios use GenericSerialBus operation region to access
> i2c device to get battery info. So battery function depends on the I2C
> operation region support. Here is the bug link.
> https://bugzilla.kernel.org/show_bug.cgi?id=69011

Hi all,

I have tested this series and got some errors, but no additional functionality:

[0.607442] ACPI Error: Error attaching device[f60238a0] data
[0.607460]  (20140214/bus-143)
[0.607708] ACPI Error: Error attaching device[f60238a0] data
[0.607724]  (20140214/bus-143)
[0.607987] ACPI Error: Error attaching device[f60238a0] data
[0.608003]  (20140214/bus-143)
[0.608251] ACPI Error: Error attaching device[f60238a0] data
[0.608267]  (20140214/bus-143)
[0.608515] ACPI Error: Error attaching device[f60238a0] data
[0.608531]  (20140214/bus-143)

A bit more output, e.g. the error code if such is present or the device path,
could probably help when identifyint the device in question.

Also this still looks incomplete, as on other places one still gets those
warnings:

[0.314944] pnp 00:08: Plug and Play ACPI device, IDs INT33fc (active)
[0.316122] pnp 00:09: unknown resource type 19 in _CRS
[0.316136] pnp 00:09: can't evaluate _CRS: 1

I don't know if looking on them at this place has any value, maybe something
like this is correct?

commit 52e2822c4c8b09180e5eb3dd94e4e9aea0d25eff
Author: Rolf Eike Beer 
Date:   Tue Feb 18 11:11:10 2014 +0100

ACPI: ignore GPIO and SERIAL_BUS resources in PNP init code

diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
index 167f3d0..5b8459b 100644
--- a/drivers/pnp/pnpacpi/rsparser.c
+++ b/drivers/pnp/pnpacpi/rsparser.c
@@ -240,6 +240,8 @@ static acpi_status pnpacpi_allocated_resource(struct 
acpi_resource *res,
break;
 
case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
+   case ACPI_RESOURCE_TYPE_GPIO:
+   case ACPI_RESOURCE_TYPE_SERIAL_BUS:
break;
 
default:

Greetings,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source


signature.asc
Description: This is a digitally signed message part.


Re: [Patch V2 0/9] I2C ACPI operation region handler support

2014-05-13 Thread Rolf Eike Beer
Am Montag, 28. April 2014, 22:27:39 schrieb Lan Tianyu:
 ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation
 region. It allows ACPI aml code able to access such kind of devices to
 implement some ACPI standard method.
 
 On the Asus T100TA, Bios use GenericSerialBus operation region to access
 i2c device to get battery info. So battery function depends on the I2C
 operation region support. Here is the bug link.
 https://bugzilla.kernel.org/show_bug.cgi?id=69011

Hi all,

I have tested this series and got some errors, but no additional functionality:

[0.607442] ACPI Error: Error attaching device[f60238a0] data
[0.607460]  (20140214/bus-143)
[0.607708] ACPI Error: Error attaching device[f60238a0] data
[0.607724]  (20140214/bus-143)
[0.607987] ACPI Error: Error attaching device[f60238a0] data
[0.608003]  (20140214/bus-143)
[0.608251] ACPI Error: Error attaching device[f60238a0] data
[0.608267]  (20140214/bus-143)
[0.608515] ACPI Error: Error attaching device[f60238a0] data
[0.608531]  (20140214/bus-143)

A bit more output, e.g. the error code if such is present or the device path,
could probably help when identifyint the device in question.

Also this still looks incomplete, as on other places one still gets those
warnings:

[0.314944] pnp 00:08: Plug and Play ACPI device, IDs INT33fc (active)
[0.316122] pnp 00:09: unknown resource type 19 in _CRS
[0.316136] pnp 00:09: can't evaluate _CRS: 1

I don't know if looking on them at this place has any value, maybe something
like this is correct?

commit 52e2822c4c8b09180e5eb3dd94e4e9aea0d25eff
Author: Rolf Eike Beer e...@emlix.com
Date:   Tue Feb 18 11:11:10 2014 +0100

ACPI: ignore GPIO and SERIAL_BUS resources in PNP init code

diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
index 167f3d0..5b8459b 100644
--- a/drivers/pnp/pnpacpi/rsparser.c
+++ b/drivers/pnp/pnpacpi/rsparser.c
@@ -240,6 +240,8 @@ static acpi_status pnpacpi_allocated_resource(struct 
acpi_resource *res,
break;
 
case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
+   case ACPI_RESOURCE_TYPE_GPIO:
+   case ACPI_RESOURCE_TYPE_SERIAL_BUS:
break;
 
default:

Greetings,

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source


signature.asc
Description: This is a digitally signed message part.


Re: Lockup on Sun Fire V240 under load

2013-12-16 Thread Rolf Eike Beer
> I recompiled both binutils and gcc in parallel (independent of each other).
> Only minutes after I started this the machine locked up. The machine has
> 8GiB of RAM and was otherwise idle.

This time it was trying to generate a new OpenSSL cert (qmail-genrsacert from 
Gentoo):

[209482.600816] BUG: NMI Watchdog detected LOCKUP on CPU1, ip 0042f748, 
registers:
[209482.696963] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1
[209482.786173] task: f8033a019980 ti: f8033c4c4000 task.ti: 
f8033c4c4000
[209482.885679] TSTATE: 009911e01605 TPC: 0042f748 TNPC: 
0042f3c0 Y: Not tainted
[209483.016074] TPC: <__delay+0x28/0x60>
[209483.064099] g0: f8033c9c9458 g1: 0042f3c0 g2: 0002 
g3: 0001869e
[209483.179617] g4: f8033a019980 g5: f8133c59a000 g6: f8033c4c4000 
g7: 
[209483.295135] o0: 0006 o1: f8033c4c4400 o2: 0043d6fc 
o3: 
[209483.410651] o4:  o5: f7e58000 sp: f8033c4c70f1 
ret_pc: 0042f744
[209483.530745] RPC: <__delay+0x24/0x60>
[209483.578778] l0: 02494a37a682 l1: 009ce348 l2: 0043d6f8 
l3: 0400
[209483.694301] l4: 000e l5: 0001 l6:  
l7: 0008
[209483.809820] i0: 0018 i1:  i2: 0001 
i3: 
[209483.925338] i4:  i5: 0003 i6: f8033c4c71a1 
i7: 0043d704
[209484.040864] I7: 
[209484.106041] Call Trace:
[209484.139211]  [0043d704] cheetah_xcall_deliver+0x184/0x2a0
[209484.220418]  [0043d410] xcall_deliver+0x110/0x140
[209484.292478]  [004960fc] check_preempt_wakeup+0x11c/0x1e0
[209484.372534]  [0048db74] check_preempt_curr+0x94/0xc0
[209484.448023]  [00490548] wake_up_new_task+0x108/0x1a0
[209484.523512]  [004608e8] do_fork+0xa8/0x220
[209484.587557]  [0042ca88] sparc_do_fork+0x28/0x60
[209484.657328]  [00406174] linux_sparc_syscall32+0x34/0x40
[209484.736242] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1
[209484.825451] Call Trace:
[209484.858628]  [00878c28] perfctr_irq+0x2a8/0x360
[209484.928392]  [004209f4] tl0_irq15+0x14/0x20
[209484.993583]  [0042f748] __delay+0x28/0x60
[209485.056489]  [0043d704] cheetah_xcall_deliver+0x184/0x2a0
[209485.137693]  [0043d410] xcall_deliver+0x110/0x140
[209485.209750]  [004960fc] check_preempt_wakeup+0x11c/0x1e0
[209485.289809]  [0048db74] check_preempt_curr+0x94/0xc0
[209485.365297]  [00490548] wake_up_new_task+0x108/0x1a0
[209485.440782]  [004608e8] do_fork+0xa8/0x220
[209485.504831]  [0042ca88] sparc_do_fork+0x28/0x60
[209485.574601]  [00406174] linux_sparc_syscall32+0x34/0x40
[209485.653565] BUG: soft lockup - CPU#1 stuck for 33s! [qmail-genrsacer:4612]
[209485.745119] Modules linked in: ipv6 openpromfs libcrc32c multipath linear 
raid456 async_pq async_xor xor async_memcpy async_raid6_recov async_tx raid6_pq 
dm_snapshot dm_crypt dm_mirror dm_region_hash dm_log usb_storage sg
[209486.004746] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1
[209486.093959] task: f8033a019980 ti: f8033c4c4000 task.ti: 
f8033c4c4000
[209486.193469] TSTATE: 004480001607 TPC: 00878c7c TNPC: 
00878c80 Y: Not tainted
[209486.323858] TPC: 
[209486.378749] g0: 3f40 g1:  g2: 0001 
g3: feff
[209486.494271] g4: f8033a019980 g5: f8133c59a000 g6: f8033c4c4000 
g7: 0720
[209486.609787] o0: 0092ec00 o1: f8033c4c7ea0 o2: 0042f748 
o3: 0092b400
[209486.725304] o4: 0008 o5: f8033c4c7f40 sp: f8133fe97741 
ret_pc: 00878c54
[209486.845399] RPC: 
[209486.900292] l0: f8033c4c6ee1 l1: 0092ec00 l2:  
l3: f81339bca000
[209487.015813] l4: f8033a019980 l5:  l6: 0008 
l7: f7d5c000
[209487.131332] i0: 000f i1: f8033c4c7850 i2: f8033c4c7900 
i3: 
[209487.246848] i4: 004f i5: 0002 i6: f8033c4c6f91 
i7: 004209f4
[209487.362367] I7: 
[209487.411537] Call Trace:
[209487.444708]  [004209f4] tl0_irq15+0x14/0x20
[209487.509905]  [0042f748] __delay+0x28/0x60
[209487.572809]  [0043d704] cheetah_xcall_deliver+0x184/0x2a0
[209487.654013]  [0043d410] xcall_deliver+0x110/0x140
[209487.726070]  [004960fc] check_preempt_wakeup+0x11c/0x1e0
[209487.806130]  [0048db74] check_preempt_curr+0x94/0xc0
[209487.881616]  [00490548] wake_up_new_task+0x108/0x1a0
[209487.957102]  [004608e8] do_fork+0xa8/0x220
[209488.021151]  [0042ca88] sparc_do_fork+0x28/0x60
[209488.090920]  [00406174] 

Re: Lockup on Sun Fire V240 under load

2013-12-16 Thread Rolf Eike Beer
 I recompiled both binutils and gcc in parallel (independent of each other).
 Only minutes after I started this the machine locked up. The machine has
 8GiB of RAM and was otherwise idle.

This time it was trying to generate a new OpenSSL cert (qmail-genrsacert from 
Gentoo):

[209482.600816] BUG: NMI Watchdog detected LOCKUP on CPU1, ip 0042f748, 
registers:
[209482.696963] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1
[209482.786173] task: f8033a019980 ti: f8033c4c4000 task.ti: 
f8033c4c4000
[209482.885679] TSTATE: 009911e01605 TPC: 0042f748 TNPC: 
0042f3c0 Y: Not tainted
[209483.016074] TPC: __delay+0x28/0x60
[209483.064099] g0: f8033c9c9458 g1: 0042f3c0 g2: 0002 
g3: 0001869e
[209483.179617] g4: f8033a019980 g5: f8133c59a000 g6: f8033c4c4000 
g7: 
[209483.295135] o0: 0006 o1: f8033c4c4400 o2: 0043d6fc 
o3: 
[209483.410651] o4:  o5: f7e58000 sp: f8033c4c70f1 
ret_pc: 0042f744
[209483.530745] RPC: __delay+0x24/0x60
[209483.578778] l0: 02494a37a682 l1: 009ce348 l2: 0043d6f8 
l3: 0400
[209483.694301] l4: 000e l5: 0001 l6:  
l7: 0008
[209483.809820] i0: 0018 i1:  i2: 0001 
i3: 
[209483.925338] i4:  i5: 0003 i6: f8033c4c71a1 
i7: 0043d704
[209484.040864] I7: cheetah_xcall_deliver+0x184/0x2a0
[209484.106041] Call Trace:
[209484.139211]  [0043d704] cheetah_xcall_deliver+0x184/0x2a0
[209484.220418]  [0043d410] xcall_deliver+0x110/0x140
[209484.292478]  [004960fc] check_preempt_wakeup+0x11c/0x1e0
[209484.372534]  [0048db74] check_preempt_curr+0x94/0xc0
[209484.448023]  [00490548] wake_up_new_task+0x108/0x1a0
[209484.523512]  [004608e8] do_fork+0xa8/0x220
[209484.587557]  [0042ca88] sparc_do_fork+0x28/0x60
[209484.657328]  [00406174] linux_sparc_syscall32+0x34/0x40
[209484.736242] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1
[209484.825451] Call Trace:
[209484.858628]  [00878c28] perfctr_irq+0x2a8/0x360
[209484.928392]  [004209f4] tl0_irq15+0x14/0x20
[209484.993583]  [0042f748] __delay+0x28/0x60
[209485.056489]  [0043d704] cheetah_xcall_deliver+0x184/0x2a0
[209485.137693]  [0043d410] xcall_deliver+0x110/0x140
[209485.209750]  [004960fc] check_preempt_wakeup+0x11c/0x1e0
[209485.289809]  [0048db74] check_preempt_curr+0x94/0xc0
[209485.365297]  [00490548] wake_up_new_task+0x108/0x1a0
[209485.440782]  [004608e8] do_fork+0xa8/0x220
[209485.504831]  [0042ca88] sparc_do_fork+0x28/0x60
[209485.574601]  [00406174] linux_sparc_syscall32+0x34/0x40
[209485.653565] BUG: soft lockup - CPU#1 stuck for 33s! [qmail-genrsacer:4612]
[209485.745119] Modules linked in: ipv6 openpromfs libcrc32c multipath linear 
raid456 async_pq async_xor xor async_memcpy async_raid6_recov async_tx raid6_pq 
dm_snapshot dm_crypt dm_mirror dm_region_hash dm_log usb_storage sg
[209486.004746] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1
[209486.093959] task: f8033a019980 ti: f8033c4c4000 task.ti: 
f8033c4c4000
[209486.193469] TSTATE: 004480001607 TPC: 00878c7c TNPC: 
00878c80 Y: Not tainted
[209486.323858] TPC: perfctr_irq+0x2fc/0x360
[209486.378749] g0: 3f40 g1:  g2: 0001 
g3: feff
[209486.494271] g4: f8033a019980 g5: f8133c59a000 g6: f8033c4c4000 
g7: 0720
[209486.609787] o0: 0092ec00 o1: f8033c4c7ea0 o2: 0042f748 
o3: 0092b400
[209486.725304] o4: 0008 o5: f8033c4c7f40 sp: f8133fe97741 
ret_pc: 00878c54
[209486.845399] RPC: perfctr_irq+0x2d4/0x360
[209486.900292] l0: f8033c4c6ee1 l1: 0092ec00 l2:  
l3: f81339bca000
[209487.015813] l4: f8033a019980 l5:  l6: 0008 
l7: f7d5c000
[209487.131332] i0: 000f i1: f8033c4c7850 i2: f8033c4c7900 
i3: 
[209487.246848] i4: 004f i5: 0002 i6: f8033c4c6f91 
i7: 004209f4
[209487.362367] I7: tl0_irq15+0x14/0x20
[209487.411537] Call Trace:
[209487.444708]  [004209f4] tl0_irq15+0x14/0x20
[209487.509905]  [0042f748] __delay+0x28/0x60
[209487.572809]  [0043d704] cheetah_xcall_deliver+0x184/0x2a0
[209487.654013]  [0043d410] xcall_deliver+0x110/0x140
[209487.726070]  [004960fc] check_preempt_wakeup+0x11c/0x1e0
[209487.806130]  [0048db74] check_preempt_curr+0x94/0xc0
[209487.881616]  [00490548] wake_up_new_task+0x108/0x1a0
[209487.957102]  [004608e8] do_fork+0xa8/0x220
[209488.021151]  

Lockup on Sun Fire V240 under load

2013-11-28 Thread Rolf Eike Beer
I recompiled both binutils and gcc in parallel (independent of each other). 
Only minutes after I started this the machine locked up. The machine has 8GiB 
of RAM and was otherwise idle.

Greetings,

Eike

[233026.041133] BUG: NMI Watchdog detected LOCKUP on CPU1, ip 0043d6f8, 
registers:
[233026.137243] CPU: 1 PID: 362 Comm: khugepaged Not tainted 3.12.1 #3
[233026.219590] task: f8033a1e6000 ti: f8033a0a4000 task.ti: 
f8033a0a4000
[233026.319095] TSTATE: 004480e01602 TPC: 0043d6f8 TNPC: 
0043d6fc Y: Not tainted
[233026.449493] TPC: 
[233026.515814] g0:  g1: f8133c820008 g2: 0001 
g3: 0001869e
[233026.631333] g4: f8033a1e6000 g5: f8133c59e000 g6: f8033a0a4000 
g7: 
[233026.746850] o0: 0018 o1:  o2: 0001 
o3: 
[233026.862369] o4:  o5: 0003 sp: f8033a0a6821 
ret_pc: 0043d704
[233026.982462] RPC: 
[233027.048794] l0:  l1: 0001 l2: 0001 
l3: 0002
[233027.164314] l4:  l5: 0016 l6: f8133c820040 
l7: f8133c82
[233027.279836] i0: f8133c820010 i1: 0001 i2: 0002 
i3: 0040
[233027.395354] i4: 0050 i5: 0060 i6: f8033a0a68e1 
i7: 0043d410
[233027.510872] I7: 
[233027.566907] Call Trace:
[233027.600078]  [0043d410] xcall_deliver+0x110/0x140
[233027.672135]  [0043e5c0] smp_flush_tlb_page+0x40/0xa0
[233027.747624]  [00452d70] tlb_batch_add_one+0x90/0xc0
[233027.821968]  [00521c90] ptep_clear_flush+0x30/0x40
[233027.895162]  [0051c4d8] try_to_unmap_one+0x78/0x480
[233027.969505]  [0051d138] try_to_unmap_anon+0x78/0x140
[233028.044991]  [0051d290] try_to_unmap+0x50/0x80
[233028.113618]  [00537a64] migrate_pages+0x3c4/0x720
[233028.185674]  [0050cfd4] compact_zone+0x2b4/0x400
[233028.256582]  [0050d430] compact_zone_order+0x90/0xc0
[233028.332070]  [0050d524] try_to_compact_pages+0xc4/0x120
[233028.410989]  [004f3694] __alloc_pages_direct_compact+0x54/0x1c0
[233028.499053]  [004f3d48] __alloc_pages_nodemask+0x548/0x8a0
[233028.581410]  [00530810] alloc_pages_vma+0x50/0x120
[233028.654603]  [005396c0] khugepaged+0x620/0xf80
[233028.723232]  [00481d08] kthread+0x88/0xa0
[233028.786130] CPU: 1 PID: 362 Comm: khugepaged Not tainted 3.12.1 #3
[233028.868479] Call Trace:
[233028.901654]  [008780e8] perfctr_irq+0x2a8/0x360
[233028.971419]  [004209f4] tl0_irq15+0x14/0x20
[233029.036608]  [0043d6f8] cheetah_xcall_deliver+0x178/0x2a0
[233029.117815]  [0043d410] xcall_deliver+0x110/0x140
[233029.189870]  [0043e5c0] smp_flush_tlb_page+0x40/0xa0
[233029.265356]  [00452d70] tlb_batch_add_one+0x90/0xc0
[233029.339699]  [00521c90] ptep_clear_flush+0x30/0x40
[233029.412898]  [0051c4d8] try_to_unmap_one+0x78/0x480
[233029.487241]  [0051d138] try_to_unmap_anon+0x78/0x140
[233029.562726]  [0051d290] try_to_unmap+0x50/0x80
[233029.631350]  [00537a64] migrate_pages+0x3c4/0x720
[233029.703407]  [0050cfd4] compact_zone+0x2b4/0x400
[233029.774318]  [0050d430] compact_zone_order+0x90/0xc0
[233029.849806]  [0050d524] try_to_compact_pages+0xc4/0x120
[233029.928721]  [004f3694] __alloc_pages_direct_compact+0x54/0x1c0
[233030.016789]  [004f3d48] __alloc_pages_nodemask+0x548/0x8a0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Lockup on Sun Fire V240 under load

2013-11-28 Thread Rolf Eike Beer
I recompiled both binutils and gcc in parallel (independent of each other). 
Only minutes after I started this the machine locked up. The machine has 8GiB 
of RAM and was otherwise idle.

Greetings,

Eike

[233026.041133] BUG: NMI Watchdog detected LOCKUP on CPU1, ip 0043d6f8, 
registers:
[233026.137243] CPU: 1 PID: 362 Comm: khugepaged Not tainted 3.12.1 #3
[233026.219590] task: f8033a1e6000 ti: f8033a0a4000 task.ti: 
f8033a0a4000
[233026.319095] TSTATE: 004480e01602 TPC: 0043d6f8 TNPC: 
0043d6fc Y: Not tainted
[233026.449493] TPC: cheetah_xcall_deliver+0x178/0x2a0
[233026.515814] g0:  g1: f8133c820008 g2: 0001 
g3: 0001869e
[233026.631333] g4: f8033a1e6000 g5: f8133c59e000 g6: f8033a0a4000 
g7: 
[233026.746850] o0: 0018 o1:  o2: 0001 
o3: 
[233026.862369] o4:  o5: 0003 sp: f8033a0a6821 
ret_pc: 0043d704
[233026.982462] RPC: cheetah_xcall_deliver+0x184/0x2a0
[233027.048794] l0:  l1: 0001 l2: 0001 
l3: 0002
[233027.164314] l4:  l5: 0016 l6: f8133c820040 
l7: f8133c82
[233027.279836] i0: f8133c820010 i1: 0001 i2: 0002 
i3: 0040
[233027.395354] i4: 0050 i5: 0060 i6: f8033a0a68e1 
i7: 0043d410
[233027.510872] I7: xcall_deliver+0x110/0x140
[233027.566907] Call Trace:
[233027.600078]  [0043d410] xcall_deliver+0x110/0x140
[233027.672135]  [0043e5c0] smp_flush_tlb_page+0x40/0xa0
[233027.747624]  [00452d70] tlb_batch_add_one+0x90/0xc0
[233027.821968]  [00521c90] ptep_clear_flush+0x30/0x40
[233027.895162]  [0051c4d8] try_to_unmap_one+0x78/0x480
[233027.969505]  [0051d138] try_to_unmap_anon+0x78/0x140
[233028.044991]  [0051d290] try_to_unmap+0x50/0x80
[233028.113618]  [00537a64] migrate_pages+0x3c4/0x720
[233028.185674]  [0050cfd4] compact_zone+0x2b4/0x400
[233028.256582]  [0050d430] compact_zone_order+0x90/0xc0
[233028.332070]  [0050d524] try_to_compact_pages+0xc4/0x120
[233028.410989]  [004f3694] __alloc_pages_direct_compact+0x54/0x1c0
[233028.499053]  [004f3d48] __alloc_pages_nodemask+0x548/0x8a0
[233028.581410]  [00530810] alloc_pages_vma+0x50/0x120
[233028.654603]  [005396c0] khugepaged+0x620/0xf80
[233028.723232]  [00481d08] kthread+0x88/0xa0
[233028.786130] CPU: 1 PID: 362 Comm: khugepaged Not tainted 3.12.1 #3
[233028.868479] Call Trace:
[233028.901654]  [008780e8] perfctr_irq+0x2a8/0x360
[233028.971419]  [004209f4] tl0_irq15+0x14/0x20
[233029.036608]  [0043d6f8] cheetah_xcall_deliver+0x178/0x2a0
[233029.117815]  [0043d410] xcall_deliver+0x110/0x140
[233029.189870]  [0043e5c0] smp_flush_tlb_page+0x40/0xa0
[233029.265356]  [00452d70] tlb_batch_add_one+0x90/0xc0
[233029.339699]  [00521c90] ptep_clear_flush+0x30/0x40
[233029.412898]  [0051c4d8] try_to_unmap_one+0x78/0x480
[233029.487241]  [0051d138] try_to_unmap_anon+0x78/0x140
[233029.562726]  [0051d290] try_to_unmap+0x50/0x80
[233029.631350]  [00537a64] migrate_pages+0x3c4/0x720
[233029.703407]  [0050cfd4] compact_zone+0x2b4/0x400
[233029.774318]  [0050d430] compact_zone_order+0x90/0xc0
[233029.849806]  [0050d524] try_to_compact_pages+0xc4/0x120
[233029.928721]  [004f3694] __alloc_pages_direct_compact+0x54/0x1c0
[233030.016789]  [004f3d48] __alloc_pages_nodemask+0x548/0x8a0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Hard lockups using 3.10.0

2013-08-13 Thread Rolf Eike Beer

Borislav Petkov wrote:

On Sun, Aug 11, 2013 at 01:10:11PM +0200, Rolf Eike Beer wrote:

The RAM seems fine. It looks like it is the mainboard or a harddisk.
The issues have magically disappeared since 3 weeks, but I have not
done any suspend2disk since then anymore. Before that I had suspended
the machine on the evening and resumed when I came to work. So it's
possible that there was some corrupted stuff in the image.


Hmm, probably...


This is the smart output I got of one disk yesterday:

Vendor:   /0:0:0:0
Product:
User Capacity:600,332,565,813,390,450 bytes [600 PB]


Is this for real? 600 PB??

I wanna hdd like that :-)


We have problems getting such a disk again. Seems all available one 
have disappeared somewhere near Bluffdale.


I'm not sure how good ext4 can handle sector sizes of several hundred 
megabytes, so it may be not that fun ;)


Eike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Hard lockups using 3.10.0

2013-08-13 Thread Rolf Eike Beer

Borislav Petkov wrote:

On Sun, Aug 11, 2013 at 01:10:11PM +0200, Rolf Eike Beer wrote:

The RAM seems fine. It looks like it is the mainboard or a harddisk.
The issues have magically disappeared since 3 weeks, but I have not
done any suspend2disk since then anymore. Before that I had suspended
the machine on the evening and resumed when I came to work. So it's
possible that there was some corrupted stuff in the image.


Hmm, probably...


This is the smart output I got of one disk yesterday:

Vendor:   /0:0:0:0
Product:
User Capacity:600,332,565,813,390,450 bytes [600 PB]


Is this for real? 600 PB??

I wanna hdd like that :-)


We have problems getting such a disk again. Seems all available one 
have disappeared somewhere near Bluffdale.


I'm not sure how good ext4 can handle sector sizes of several hundred 
megabytes, so it may be not that fun ;)


Eike
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Hard lockups using 3.10.0

2013-08-11 Thread Rolf Eike Beer
Borislav Petkov wrote:
> On Sun, Aug 11, 2013 at 08:09:19AM +0200, Rolf Eike Beer wrote:
> > Meanwhile I found that there was a hardware defect on this machine.
> > So if it does not happen again I will assume that this was caused by
> > this.
> 
> What hardware defect exactly? DIMMs failing...? Probably, since it looks
> like the spinlock gets corrupted and the assertion fires... In any case,
> it would be interesting to know for future reference.

The RAM seems fine. It looks like it is the mainboard or a harddisk. The issues 
have magically disappeared since 3 weeks, but I have not done any suspend2disk 
since then anymore. Before that I had suspended the machine on the evening and 
resumed when I came to work. So it's possible that there was some corrupted 
stuff in the image.

This is the smart output I got of one disk yesterday:

Vendor:   /0:0:0:0
Product:  
User Capacity:600,332,565,813,390,450 bytes [600 PB]
Logical block size:   774843950 bytes
scsiModePageOffset: response length too short, resp_len=47 offset=50 bd_len=46
>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more '-T 
permissive' options.

Eike

signature.asc
Description: This is a digitally signed message part.


Re: Hard lockups using 3.10.0

2013-08-11 Thread Rolf Eike Beer
Peter Zijlstra wrote:
> On Thu, Jul 11, 2013 at 12:07:21PM +0200, Borislav Petkov wrote:
> > On Thu, Jul 11, 2013 at 11:38:37AM +0200, Rolf Eike Beer wrote:
> > > Hi,
> > > 
> > > I'm running 3.10.0 (from openSUSE packages) on an "Intel(R) Core(TM)
> > > i7-2600 CPU @ 3.40GHz". I got a hard lockup on one of my CPUs twice,
> > > once with backtrace (see attached image). Graphics is the builtin
> > > Intel, used with X 7.6 and KDE 4.10beta2 (basically current openSUSE
> > > 12.3+KDE).
> > > 
> > > I'm not aware that I had done anything special, just "normal" desktop
> > > and
> > > development usage, but no heavy compile work at the moment the lockups
> > > happened.
> > 
> > Hmm, I can see commit_creds() doing some rcu pointers assignment and rcu
> > calling into the scheduler which screams about a cpu runqueue of the
> > task we're about to reschedule not being locked. Let's add some more
> > people who should know better.
> 
> Ok, for the other people too lazy to bother finding the picture:
> 
>   http://marc.info/?l=linux-kernel=137353587012001=p3
> 
> So we bug at:
> 
> kernel/sched/core.c:519 assert_raw_spin_locked(_rq(p)->lock);
> 
> and get there through:
> 
>   resched_task()
>   check_preempt_wakeup()
>   check_preempt_curr()
>   try_to_wake_up()
>   autoremove_wake_function()
>   __call_rcu_nocb_enqueue()
>   __call_rcu()
>   commit_creds()
>   call_usermodehelper()
>   ret_from_fork()
> 
> That don't make much sense though. Since:
> 
>   try_to_wake_up()
> ttwu_queue()
>   raw_spin_lock(>lock)
>   ttwu_do_activate()
> ttwu_do_wakeup()
>   check_preempt_curr()
> check_preempt_wakeup()
>   resched_task(rq->curr)
> assert_raw_spin_locked(task_rq(p)->lock)
> 
> It would somehow mean that 'task_rq(rq->curr) != rq', that's completely
> bonkers, we do after all have rq->lock locked.
> 
> I must also say that I've _never_ seen this bug before.

Meanwhile I found that there was a hardware defect on this machine. So if it 
does not happen again I will assume that this was caused by this.

Thanks for looking into this.

Eike

signature.asc
Description: This is a digitally signed message part.


Re: Hard lockups using 3.10.0

2013-08-11 Thread Rolf Eike Beer
Peter Zijlstra wrote:
 On Thu, Jul 11, 2013 at 12:07:21PM +0200, Borislav Petkov wrote:
  On Thu, Jul 11, 2013 at 11:38:37AM +0200, Rolf Eike Beer wrote:
   Hi,
   
   I'm running 3.10.0 (from openSUSE packages) on an Intel(R) Core(TM)
   i7-2600 CPU @ 3.40GHz. I got a hard lockup on one of my CPUs twice,
   once with backtrace (see attached image). Graphics is the builtin
   Intel, used with X 7.6 and KDE 4.10beta2 (basically current openSUSE
   12.3+KDE).
   
   I'm not aware that I had done anything special, just normal desktop
   and
   development usage, but no heavy compile work at the moment the lockups
   happened.
  
  Hmm, I can see commit_creds() doing some rcu pointers assignment and rcu
  calling into the scheduler which screams about a cpu runqueue of the
  task we're about to reschedule not being locked. Let's add some more
  people who should know better.
 
 Ok, for the other people too lazy to bother finding the picture:
 
   http://marc.info/?l=linux-kernelm=137353587012001q=p3
 
 So we bug at:
 
 kernel/sched/core.c:519 assert_raw_spin_locked(task_rq(p)-lock);
 
 and get there through:
 
   resched_task()
   check_preempt_wakeup()
   check_preempt_curr()
   try_to_wake_up()
   autoremove_wake_function()
   __call_rcu_nocb_enqueue()
   __call_rcu()
   commit_creds()
   call_usermodehelper()
   ret_from_fork()
 
 That don't make much sense though. Since:
 
   try_to_wake_up()
 ttwu_queue()
   raw_spin_lock(rq-lock)
   ttwu_do_activate()
 ttwu_do_wakeup()
   check_preempt_curr()
 check_preempt_wakeup()
   resched_task(rq-curr)
 assert_raw_spin_locked(task_rq(p)-lock)
 
 It would somehow mean that 'task_rq(rq-curr) != rq', that's completely
 bonkers, we do after all have rq-lock locked.
 
 I must also say that I've _never_ seen this bug before.

Meanwhile I found that there was a hardware defect on this machine. So if it 
does not happen again I will assume that this was caused by this.

Thanks for looking into this.

Eike

signature.asc
Description: This is a digitally signed message part.


  1   2   3   4   >