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

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

[PATCH] typo: kthead -> kthread

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

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

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

[PATCH] Kconfig: fix help text of TRACEPOINT_BENCHMARK

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

[PATCH] simplify copy_mm()

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

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

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

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

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 li

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

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

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

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

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

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ührun

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

_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 Pl

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

>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-con

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

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? No

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

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 loc

[PATCH v5] 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 | 10 -- 1 file changed, 8 insertions(+), 2

Re: [PATCH] kbuild: improve libelf detection

> 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 p

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

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

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

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

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

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

fix typos in "compress" variants

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

binfmt_elf: simplify error handling in load_elf_phdrs()

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

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

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

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

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 > > Oth

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

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

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

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

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

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 Fo

[PATCH v3][RESEND] 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 --- scripts/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions

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

ts 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 Goth

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

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 > > > > > >

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

> 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. Whil

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

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

riscv: remove unused barrier defines

>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 af

[PATCH RESEND] H8300: remove unused barrier defines

>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 af

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

lias(#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, German

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

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

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

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: > > > > >

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

>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-con

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

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 libcryp

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

>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-con

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

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 "run

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

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 >

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

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, Germ

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

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

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

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

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

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 > &

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

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

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

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. >

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

ly! 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

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

ly! 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

[PATCH v2] 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 --- scripts/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions

[PATCH v2] 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 --- scripts/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions

[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 --- scripts/Makefile | 7 +-- 1 file changed, 5 insertions(+), 2 deletions

[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 --- scripts/Makefile | 7 +-- 1 file changed, 5 insertions(+), 2 deletions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>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

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

>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 embed

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

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

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

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

4.3.3: error when plugging in USB stick

[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

4.3.3: error when plugging in USB stick

[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

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

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

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

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

Kconfig: remove comment about scsi_wait_scan module

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

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

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 @@ -40

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

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 ++

Kconfig: remove comment about scsi_wait_scan module

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

Re: [3.18 regression]: machine hangs on s2ram

> 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

Re: [3.18 regression]: machine hangs on s2ram

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

[3.18 regression]: machine hangs on s2ram

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

[3.18 regression]: machine hangs on s2ram

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

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

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 --

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

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

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

> 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

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

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

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

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

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

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

[3.15.0] Sun V240: soft lockup - CPU stuck

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)

[3.15.0] Sun V240: soft lockup - CPU stuck

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)

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

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

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

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

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

: 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 co

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

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

Re: Lockup on Sun Fire V240 under load

> 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]

Re: Lockup on Sun Fire V240 under load

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:

Lockup on Sun Fire V240 under load

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:

Lockup on Sun Fire V240 under load

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:

Re: Hard lockups using 3.10.0

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

Re: Hard lockups using 3.10.0

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

Re: Hard lockups using 3.10.0

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 de

Re: Hard lockups using 3.10.0

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) > >

Re: Hard lockups using 3.10.0

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

  1   2   3   4   >