Re: [PATCH] printk: move dump stack related code to lib/dump_stack.c

On 02/09/18 at 04:51pm, Dave Young wrote: > On 02/09/18 at 05:42pm, Sergey Senozhatsky wrote: > > On (02/09/18 16:27), Dave Young wrote: > > > > Seems that those functions are still defined in printk header. > > > > Did you test !CONFIG_PRINTK build? > >

Re: [PATCH] printk: move dump stack related code to lib/dump_stack.c

On 02/09/18 at 04:51pm, Dave Young wrote: > On 02/09/18 at 05:42pm, Sergey Senozhatsky wrote: > > On (02/09/18 16:27), Dave Young wrote: > > > > Seems that those functions are still defined in printk header. > > > > Did you test !CONFIG_PRINTK build? > >

Re: [PATCH] printk: move dump stack related code to lib/dump_stack.c

On 02/09/18 at 05:42pm, Sergey Senozhatsky wrote: > On (02/09/18 16:27), Dave Young wrote: > > > Seems that those functions are still defined in printk header. > > > Did you test !CONFIG_PRINTK build? > > Apparently dump_stack(void) is also in printk.h > > exter

Re: [PATCH] printk: move dump stack related code to lib/dump_stack.c

On 02/09/18 at 05:42pm, Sergey Senozhatsky wrote: > On (02/09/18 16:27), Dave Young wrote: > > > Seems that those functions are still defined in printk header. > > > Did you test !CONFIG_PRINTK build? > > Apparently dump_stack(void) is also in printk.h > > exter

Re: [PATCH] printk: move dump stack related code to lib/dump_stack.c

On 02/09/18 at 05:16pm, Sergey Senozhatsky wrote: > Hi, > > On (02/09/18 16:06), Dave Young wrote: > [..] > > +void __init dump_stack_set_arch_desc(const char *fmt, ...) > .. > > +void dump_stack_print_info(const char *log_lvl) > .. > > +void show

Re: [PATCH] printk: move dump stack related code to lib/dump_stack.c

On 02/09/18 at 05:16pm, Sergey Senozhatsky wrote: > Hi, > > On (02/09/18 16:06), Dave Young wrote: > [..] > > +void __init dump_stack_set_arch_desc(const char *fmt, ...) > .. > > +void dump_stack_print_info(const char *log_lvl) > .. > > +void show

Re: [PATCH] printk: move dump stack related code to lib/dump_stack.c

On 02/09/18 at 05:16pm, Sergey Senozhatsky wrote: > Hi, > > On (02/09/18 16:06), Dave Young wrote: > [..] > > +void __init dump_stack_set_arch_desc(const char *fmt, ...) > .. > > +void dump_stack_print_info(const char *log_lvl) > .. > > +void show

Re: [PATCH] printk: move dump stack related code to lib/dump_stack.c

On 02/09/18 at 05:16pm, Sergey Senozhatsky wrote: > Hi, > > On (02/09/18 16:06), Dave Young wrote: > [..] > > +void __init dump_stack_set_arch_desc(const char *fmt, ...) > .. > > +void dump_stack_print_info(const char *log_lvl) > .. > > +void show

[PATCH] printk: move dump stack related code to lib/dump_stack.c

dump_stack related stuff should belong to lib/dump_stack.c thus move them there. Signed-off-by: Dave Young <dyo...@redhat.com> Suggested-by: Steven Rostedt <rost...@goodmis.org> Suggested-by: Sergey Senozhatsky <sergey.senozhatsky.w...@gmail.com> --- Note: dump stack etc st

[PATCH] printk: move dump stack related code to lib/dump_stack.c

dump_stack related stuff should belong to lib/dump_stack.c thus move them there. Signed-off-by: Dave Young Suggested-by: Steven Rostedt Suggested-by: Sergey Senozhatsky --- Note: dump stack etc still share printk.h as before, I would keep it as is since a lot of files need it. This patch

Re: [PATCH V2] print kdump kernel loaded status in stack dump

On 01/30/18 at 05:50pm, Sergey Senozhatsky wrote: > On (01/27/18 12:11), Dave Young wrote: > > It is useful to print kdump kernel loaded status in dump_stack() > > especially when panic happens so that we can differenciate > > kdump kernel early hang and a normal

Re: [PATCH V2] print kdump kernel loaded status in stack dump

On 01/30/18 at 05:50pm, Sergey Senozhatsky wrote: > On (01/27/18 12:11), Dave Young wrote: > > It is useful to print kdump kernel loaded status in dump_stack() > > especially when panic happens so that we can differenciate > > kdump kernel early hang and a normal

[PATCH V2] print kdump kernel loaded status in stack dump

It is useful to print kdump kernel loaded status in dump_stack() especially when panic happens so that we can differenciate kdump kernel early hang and a normal panic in a bug report. Signed-off-by: Dave Young <dyo...@redhat.com> --- [v1 -> v2] merge the status in other line as A

[PATCH V2] print kdump kernel loaded status in stack dump

It is useful to print kdump kernel loaded status in dump_stack() especially when panic happens so that we can differenciate kdump kernel early hang and a normal panic in a bug report. Signed-off-by: Dave Young --- [v1 -> v2] merge the status in other line as Andi Kleen suggested kernel/pri

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/26/18 at 01:17pm, Petr Mladek wrote: > On Fri 2018-01-26 15:37:24, Dave Young wrote: > > On 01/19/18 at 12:47pm, Dave Young wrote: > > > On 01/18/18 at 01:57pm, Steven Rostedt wrote: > > > > On Thu, 18 Jan 2018 10:02:17 -0800 > > > &g

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/26/18 at 01:17pm, Petr Mladek wrote: > On Fri 2018-01-26 15:37:24, Dave Young wrote: > > On 01/19/18 at 12:47pm, Dave Young wrote: > > > On 01/18/18 at 01:57pm, Steven Rostedt wrote: > > > > On Thu, 18 Jan 2018 10:02:17 -0800 > > > > Andi Kleen wr

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/19/18 at 12:47pm, Dave Young wrote: > On 01/18/18 at 01:57pm, Steven Rostedt wrote: > > On Thu, 18 Jan 2018 10:02:17 -0800 > > Andi Kleen <a...@linux.intel.com> wrote: > > > > > Dave Young <dyo...@redhat.com> writes: > > &

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/19/18 at 12:47pm, Dave Young wrote: > On 01/18/18 at 01:57pm, Steven Rostedt wrote: > > On Thu, 18 Jan 2018 10:02:17 -0800 > > Andi Kleen wrote: > > > > > Dave Young writes: > > > > printk("%sHardware name

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/19/18 at 05:28pm, Sergey Senozhatsky wrote: > On (01/19/18 16:16), Dave Young wrote: > > On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote: > > > On (01/18/18 10:02), Andi Kleen wrote: > > > > Dave Young <dyo...@redhat.com> writes: > > > &g

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/19/18 at 05:28pm, Sergey Senozhatsky wrote: > On (01/19/18 16:16), Dave Young wrote: > > On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote: > > > On (01/18/18 10:02), Andi Kleen wrote: > > > > Dave Young writes: > > > > >

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote: > On (01/18/18 10:02), Andi Kleen wrote: > > Dave Young <dyo...@redhat.com> writes: > > > printk("%sHardware name: %s\n", > > > log_lvl, dump_stack_arch_desc_str); > > >

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote: > On (01/18/18 10:02), Andi Kleen wrote: > > Dave Young writes: > > > printk("%sHardware name: %s\n", > > > log_lvl, dump_stack_arch_desc_str); > > > + if (kexec_crash_lo

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/18/18 at 01:57pm, Steven Rostedt wrote: > On Thu, 18 Jan 2018 10:02:17 -0800 > Andi Kleen <a...@linux.intel.com> wrote: > > > Dave Young <dyo...@redhat.com> writes: > > > printk("%sHardware name: %s\n", > >

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/18/18 at 01:57pm, Steven Rostedt wrote: > On Thu, 18 Jan 2018 10:02:17 -0800 > Andi Kleen wrote: > > > Dave Young writes: > > > printk("%sHardware name: %s\n", > > > log_lvl, dump_stack_arch_desc_str); > > >

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/18/18 at 11:04am, Dave Young wrote: > On 01/17/18 at 07:00pm, Linus Torvalds wrote: > > On Wed, Jan 17, 2018 at 6:57 PM, Dave Young <dyo...@redhat.com> wrote: > > > > > > Could you say more about how to check this? My .config disabled > > &

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/18/18 at 11:04am, Dave Young wrote: > On 01/17/18 at 07:00pm, Linus Torvalds wrote: > > On Wed, Jan 17, 2018 at 6:57 PM, Dave Young wrote: > > > > > > Could you say more about how to check this? My .config disabled > > > CONFIG_X86_MCE, should this be

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 07:00pm, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 6:57 PM, Dave Young <dyo...@redhat.com> wrote: > > > > Could you say more about how to check this? My .config disabled > > CONFIG_X86_MCE, should this be enabled? > > By all means, try it

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 07:00pm, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 6:57 PM, Dave Young wrote: > > > > Could you say more about how to check this? My .config disabled > > CONFIG_X86_MCE, should this be enabled? > > By all means, try it. > > Some pending mac

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 06:53pm, Arjan van de Ven wrote: > > > > Does anybody have any other ideas? > > wbinvd is thankfully not common, but also not rare (MTRR setup and a bunch of > other cases) > and in some other operating systems it happens even more than on Linux.. it's > generally not totally

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 06:53pm, Arjan van de Ven wrote: > > > > Does anybody have any other ideas? > > wbinvd is thankfully not common, but also not rare (MTRR setup and a bunch of > other cases) > and in some other operating systems it happens even more than on Linux.. it's > generally not totally

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 06:14pm, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 5:47 PM, Dave Young <dyo...@redhat.com> wrote: > > > > It does not work with just once wbinvd(), and it only works with > > removing the wbinvd() for me. Tom's new post works for me as well >

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 06:14pm, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 5:47 PM, Dave Young wrote: > > > > It does not work with just once wbinvd(), and it only works with > > removing the wbinvd() for me. Tom's new post works for me as well > > since my cpu is an Inte

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 06:14pm, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 5:47 PM, Dave Young <dyo...@redhat.com> wrote: > > > > It does not work with just once wbinvd(), and it only works with > > removing the wbinvd() for me. Tom's new post works for me as well >

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 06:14pm, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 5:47 PM, Dave Young wrote: > > > > It does not work with just once wbinvd(), and it only works with > > removing the wbinvd() for me. Tom's new post works for me as well > > since my cpu is an Inte

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/17/18 at 02:42pm, Petr Mladek wrote: > On Wed 2018-01-17 20:32:44, Dave Young wrote: > > Hi, > > > > Thanks for your comments. > > On 01/17/18 at 09:57am, Petr Mladek wrote: > > > On Wed 2018-01-17 12:50:57, Dave Young wrote: > > > >

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/17/18 at 02:42pm, Petr Mladek wrote: > On Wed 2018-01-17 20:32:44, Dave Young wrote: > > Hi, > > > > Thanks for your comments. > > On 01/17/18 at 09:57am, Petr Mladek wrote: > > > On Wed 2018-01-17 12:50:57, Dave Young wrote: > > > >

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 09:06am, Tom Lendacky wrote: > On 1/17/2018 1:22 AM, Dave Young wrote: > > [Modify the subject since this is a new problem, original io vector > > issue has been fixed with one commit from Thomas] > > > > Add more cc according to below old discussion: >

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 09:06am, Tom Lendacky wrote: > On 1/17/2018 1:22 AM, Dave Young wrote: > > [Modify the subject since this is a new problem, original io vector > > issue has been fixed with one commit from Thomas] > > > > Add more cc according to below old discussion: >

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 11:42am, Linus Torvalds wrote: > On Tue, Jan 16, 2018 at 11:22 PM, Dave Young <dyo...@redhat.com> wrote: > > > > For the kexec reboot hang, if I remove the wbinvd in stop_this_cpu() > > then kexec works fine. like this: > > Honestly, I think we s

Re: kexec reboot fails with extra wbinvd introduced for AME SME

On 01/17/18 at 11:42am, Linus Torvalds wrote: > On Tue, Jan 16, 2018 at 11:22 PM, Dave Young wrote: > > > > For the kexec reboot hang, if I remove the wbinvd in stop_this_cpu() > > then kexec works fine. like this: > > Honestly, I think we should apply that patch reg

Re: [PATCH] x86/mm: Rework wbinvd, hlt operation in stop_this_cpu()

ative_halt() call. > > > > Cc: <sta...@vger.kernel.org> # 4.14.x > > Fixes: bba4ed011a52 ("x86/mm, kexec: Allow kexec to be used with SME") > > Reported-by: Dave Young <dyo...@redhat.com> > > Dave, > > Can you test this and see if i

Re: [PATCH] x86/mm: Rework wbinvd, hlt operation in stop_this_cpu()

ative_halt() call. > > > > Cc: # 4.14.x > > Fixes: bba4ed011a52 ("x86/mm, kexec: Allow kexec to be used with SME") > > Reported-by: Dave Young > > Dave, > > Can you test this and see if it resolves your issue? It works for me,

Re: [PATCH] print kdump kernel loaded status in stack dump

Hi, Thanks for your comments. On 01/17/18 at 09:57am, Petr Mladek wrote: > On Wed 2018-01-17 12:50:57, Dave Young wrote: > > It is useful to print kdump kernel loaded status in dump_stack() > > especially when panic happens so that we can differenciate > > kdump kernel ea

Re: [PATCH] print kdump kernel loaded status in stack dump

Hi, Thanks for your comments. On 01/17/18 at 09:57am, Petr Mladek wrote: > On Wed 2018-01-17 12:50:57, Dave Young wrote: > > It is useful to print kdump kernel loaded status in dump_stack() > > especially when panic happens so that we can differenciate > > kdump kernel ea

kexec reboot fails with extra wbinvd introduced for AME SME

Young wrote: > On 12/14/17 at 05:24pm, Dave Young wrote: > > On 12/13/17 at 11:57pm, Yu Chen wrote: > > > On Wed, Dec 13, 2017 at 10:52:56AM +0800, Dave Young wrote: > > > > Hi, > > > > > > > > Kexec reboot and kdump has broken on my

kexec reboot fails with extra wbinvd introduced for AME SME

Young wrote: > On 12/14/17 at 05:24pm, Dave Young wrote: > > On 12/13/17 at 11:57pm, Yu Chen wrote: > > > On Wed, Dec 13, 2017 at 10:52:56AM +0800, Dave Young wrote: > > > > Hi, > > > > > > > > Kexec reboot and kdump has broken on my

[PATCH] print kdump kernel loaded status in stack dump

It is useful to print kdump kernel loaded status in dump_stack() especially when panic happens so that we can differenciate kdump kernel early hang and a normal panic in a bug report. Signed-off-by: Dave Young <dyo...@redhat.com> --- kernel/printk/printk.c |3 +++ 1 file chan

[PATCH] print kdump kernel loaded status in stack dump

It is useful to print kdump kernel loaded status in dump_stack() especially when panic happens so that we can differenciate kdump kernel early hang and a normal panic in a bug report. Signed-off-by: Dave Young --- kernel/printk/printk.c |3 +++ 1 file changed, 3 insertions(+) --- linux

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 01/10/18 at 02:16pm, Kirill A. Shutemov wrote: > On Wed, Jan 10, 2018 at 03:08:04AM +0000, Dave Young wrote: > > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > > > On 01/09/1

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 01/10/18 at 02:16pm, Kirill A. Shutemov wrote: > On Wed, Jan 10, 2018 at 03:08:04AM +0000, Dave Young wrote: > > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > > > On 01/09/1

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > As for the mac

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > As for the mac

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 01/09/18 at 01:41pm, Baoquan He wrote: > On 01/09/18 at 09:09am, Dave Young wrote: > > On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > > > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > > > On Mon, Jan 08, 2018 at 04:04

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 01/09/18 at 01:41pm, Baoquan He wrote: > On 01/09/18 at 09:09am, Dave Young wrote: > > On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > > > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > > > On Mon, Jan 08, 2018 at 04:04

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > hi Kirill, > > > > > > As Mike reported it below, your 5-level paging related upstream commit > >

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > hi Kirill, > > > > > > As Mike reported it below, your 5-level paging related upstream commit > >

Re: Regression: kexec/kdump boot hangs with x86/vector commits

On 12/14/17 at 05:24pm, Dave Young wrote: > On 12/13/17 at 11:57pm, Yu Chen wrote: > > On Wed, Dec 13, 2017 at 10:52:56AM +0800, Dave Young wrote: > > > Hi, > > > > > > Kexec reboot and kdump has broken on my laptop for long time with > > > 4.15.0-rc1+

Re: Regression: kexec/kdump boot hangs with x86/vector commits

On 12/14/17 at 05:24pm, Dave Young wrote: > On 12/13/17 at 11:57pm, Yu Chen wrote: > > On Wed, Dec 13, 2017 at 10:52:56AM +0800, Dave Young wrote: > > > Hi, > > > > > > Kexec reboot and kdump has broken on my laptop for long time with > > > 4.15.0-rc1+

[tip:efi/core] x86/efi: Fix kernel param add_efi_memmap regression

Commit-ID: 835bcec5fdf3f9e880111b482177e7e70e3596da Gitweb: https://git.kernel.org/tip/835bcec5fdf3f9e880111b482177e7e70e3596da Author: Dave Young <dyo...@redhat.com> AuthorDate: Tue, 2 Jan 2018 17:21:09 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 3 Jan 2

[tip:efi/core] x86/efi: Fix kernel param add_efi_memmap regression

Commit-ID: 835bcec5fdf3f9e880111b482177e7e70e3596da Gitweb: https://git.kernel.org/tip/835bcec5fdf3f9e880111b482177e7e70e3596da Author: Dave Young AuthorDate: Tue, 2 Jan 2018 17:21:09 + Committer: Ingo Molnar CommitDate: Wed, 3 Jan 2018 13:54:31 +0100 x86/efi: Fix kernel param

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

Fix the kexec list address. On 12/18/17 at 01:40pm, Dave Young wrote: > On 12/15/17 at 05:59pm, AKASHI Takahiro wrote: > > On Wed, Dec 13, 2017 at 12:17:22PM +, Ard Biesheuvel wrote: > > > On 13 December 2017 at 12:16, AKASHI Takahiro > > > <takahiro.aka...@lin

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

Fix the kexec list address. On 12/18/17 at 01:40pm, Dave Young wrote: > On 12/15/17 at 05:59pm, AKASHI Takahiro wrote: > > On Wed, Dec 13, 2017 at 12:17:22PM +, Ard Biesheuvel wrote: > > > On 13 December 2017 at 12:16, AKASHI Takahiro > > > wrote: > > >

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

kexec@fedoraproject... is for Fedora kexec scripts discussion, changed it to ke...@lists.infradead.org Also add linux-acpi list On 12/18/17 at 02:31am, Bhupesh Sharma wrote: > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel > wrote: > > On 15 December 2017 at 09:59,

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

kexec@fedoraproject... is for Fedora kexec scripts discussion, changed it to ke...@lists.infradead.org Also add linux-acpi list On 12/18/17 at 02:31am, Bhupesh Sharma wrote: > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel > wrote: > > On 15 December 2017 at 09:59, AKASHI Takahiro > > wrote: >

[PATCH V2] x86/efi: fix kernel param add_efi_memmap regression

efi_memblock_x86_reserve_range() after parse_early_param() to fix it. Signed-off-by: Dave Young <dyo...@redhat.com> --- arch/x86/kernel/setup.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- linux-x86.orig/arch/x86/kernel/setup.c +++ linux-x86/arch/x86/kernel/setup.c @@ -906,9 +906,6 @@ void

[PATCH V2] x86/efi: fix kernel param add_efi_memmap regression

efi_memblock_x86_reserve_range() after parse_early_param() to fix it. Signed-off-by: Dave Young --- arch/x86/kernel/setup.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- linux-x86.orig/arch/x86/kernel/setup.c +++ linux-x86/arch/x86/kernel/setup.c @@ -906,9 +906,6 @@ void __init setup_arch(char

Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap

On 11/30/17 at 01:23pm, Dave Young wrote: > 'add_efi_memmap' is an early param, but do_add_efi_memmap() has no > chance to run because the code path is before parse_early_param(). > I believe it worked when the param was introduced but probably later > some other changes caused the

Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap

On 11/30/17 at 01:23pm, Dave Young wrote: > 'add_efi_memmap' is an early param, but do_add_efi_memmap() has no > chance to run because the code path is before parse_early_param(). > I believe it worked when the param was introduced but probably later > some other changes caused the

Re: [PATCH] certs: always use secondary keyring first if possible

On 11/18/17 at 12:47pm, Dave Young wrote: > Commit d3bfe84129f6 introduced secondary_trusted_keys keyring, current > users of verify_pkcs7_signature are below: > net/wireless/reg.c : uses its own trusted_keys > kernel/module_signing.c : pass NULL trusted_keys > crypto/

Re: [PATCH] certs: always use secondary keyring first if possible

On 11/18/17 at 12:47pm, Dave Young wrote: > Commit d3bfe84129f6 introduced secondary_trusted_keys keyring, current > users of verify_pkcs7_signature are below: > net/wireless/reg.c : uses its own trusted_keys > kernel/module_signing.c : pass NULL trusted_keys > crypto/

Re: Regression: kexec/kdump boot hangs with x86/vector commits

On 12/13/17 at 11:57pm, Yu Chen wrote: > On Wed, Dec 13, 2017 at 10:52:56AM +0800, Dave Young wrote: > > Hi, > > > > Kexec reboot and kdump has broken on my laptop for long time with > > 4.15.0-rc1+ kernels. With the patch below an early panic been fixed: > > h

Re: Regression: kexec/kdump boot hangs with x86/vector commits

On 12/13/17 at 11:57pm, Yu Chen wrote: > On Wed, Dec 13, 2017 at 10:52:56AM +0800, Dave Young wrote: > > Hi, > > > > Kexec reboot and kdump has broken on my laptop for long time with > > 4.15.0-rc1+ kernels. With the patch below an early panic been fixed: > > h

Regression: kexec/kdump boot hangs with x86/vector commits

Hi, Kexec reboot and kdump has broken on my laptop for long time with 4.15.0-rc1+ kernels. With the patch below an early panic been fixed: https://patchwork.kernel.org/patch/10084289/ But still can not get a successful reboot, it looked like graphic issue, but after bisecting the kernel, I got

Regression: kexec/kdump boot hangs with x86/vector commits

Hi, Kexec reboot and kdump has broken on my laptop for long time with 4.15.0-rc1+ kernels. With the patch below an early panic been fixed: https://patchwork.kernel.org/patch/10084289/ But still can not get a successful reboot, it looked like graphic issue, but after bisecting the kernel, I got

[tip:core/urgent] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep

Commit-ID: 7f6f60a1ba52538c16f26930bfbcfe193d9d746a Gitweb: https://git.kernel.org/tip/7f6f60a1ba52538c16f26930bfbcfe193d9d746a Author: Dave Young <dyo...@redhat.com> AuthorDate: Sat, 9 Dec 2017 12:16:10 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon, 11 De

[tip:core/urgent] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep

Commit-ID: 7f6f60a1ba52538c16f26930bfbcfe193d9d746a Gitweb: https://git.kernel.org/tip/7f6f60a1ba52538c16f26930bfbcfe193d9d746a Author: Dave Young AuthorDate: Sat, 9 Dec 2017 12:16:10 +0800 Committer: Ingo Molnar CommitDate: Mon, 11 Dec 2017 14:54:44 +0100 mm/early_ioremap: Fix boot

[PATCH resend] fix boot hang with earlyprintk=efi,keep

;init: Introduce SYSTEM_SCHEDULING state") early_ioremap is fine in both SYSTEM_BOOTING and SYSTEM_SCHEDULING states, original condition should be updated accordingly. Signed-off-by: Dave Young <dyo...@redhat.com> --- v1->v2: update patch log correct some typos mm/early_ioremap.

[PATCH resend] fix boot hang with earlyprintk=efi,keep

;init: Introduce SYSTEM_SCHEDULING state") early_ioremap is fine in both SYSTEM_BOOTING and SYSTEM_SCHEDULING states, original condition should be updated accordingly. Signed-off-by: Dave Young --- v1->v2: update patch log correct some typos mm/early_ioremap.c |2 +- 1 file changed

Re: [PATCH V2] mm: check pfn_valid first in zero_resv_unavail

On 12/05/17 at 10:46am, Michal Hocko wrote: > On Fri 01-12-17 17:50:48, Dave Young wrote: > > With latest kernel I get below bug while testing kdump: > > [0.00] BUG: unable to handle kernel paging request at > > ea00034b1040 > > [0.00] IP: z

Re: [PATCH V2] mm: check pfn_valid first in zero_resv_unavail

On 12/05/17 at 10:46am, Michal Hocko wrote: > On Fri 01-12-17 17:50:48, Dave Young wrote: > > With latest kernel I get below bug while testing kdump: > > [0.00] BUG: unable to handle kernel paging request at > > ea00034b1040 > > [0.00] IP: z

[tip:efi/urgent] efi: Add comment to avoid future expanding of sysfs systab

Commit-ID: 0b02e448a2ebb46eb9be4f1bdfc87112bd420cbf Gitweb: https://git.kernel.org/tip/0b02e448a2ebb46eb9be4f1bdfc87112bd420cbf Author: Dave Young <dyo...@redhat.com> AuthorDate: Wed, 6 Dec 2017 09:50:10 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 6 Dec 2

[tip:efi/urgent] efi: Add comment to avoid future expanding of sysfs systab

Commit-ID: 0b02e448a2ebb46eb9be4f1bdfc87112bd420cbf Gitweb: https://git.kernel.org/tip/0b02e448a2ebb46eb9be4f1bdfc87112bd420cbf Author: Dave Young AuthorDate: Wed, 6 Dec 2017 09:50:10 + Committer: Ingo Molnar CommitDate: Wed, 6 Dec 2017 19:32:23 +0100 efi: Add comment to avoid

[PATCH] efi: add comment to avoid future expanding of sysfs systab

/sys/firmware/efi/systab shows several different values, it breaks sysfs one file one value design. But since there are already userspace tools depend on it eg. kexec-tools so add code comment to alert future expanding of this file. Signed-off-by: Dave Young <dyo...@redhat.com> --- d

[PATCH] efi: add comment to avoid future expanding of sysfs systab

/sys/firmware/efi/systab shows several different values, it breaks sysfs one file one value design. But since there are already userspace tools depend on it eg. kexec-tools so add code comment to alert future expanding of this file. Signed-off-by: Dave Young --- drivers/firmware/efi/efi.c

Re: [GIT PULL] hash addresses printed with %p

On 12/05/17 at 09:52am, Greg Kroah-Hartman wrote: > On Tue, Dec 05, 2017 at 04:45:37PM +0800, Dave Young wrote: > > On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote: > > > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote: > > > > On 12/04/17 at 03:

Re: [GIT PULL] hash addresses printed with %p

On 12/05/17 at 09:52am, Greg Kroah-Hartman wrote: > On Tue, Dec 05, 2017 at 04:45:37PM +0800, Dave Young wrote: > > On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote: > > > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote: > > > > On 12/04/17 at 03:

Re: [GIT PULL] hash addresses printed with %p

On 12/05/17 at 04:45pm, Dave Young wrote: > On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote: > > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote: > > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote: > > > > On Mon, Dec 04, 2017 at 12:51:13PM +, Davi

Re: [GIT PULL] hash addresses printed with %p

On 12/05/17 at 04:45pm, Dave Young wrote: > On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote: > > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote: > > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote: > > > > On Mon, Dec 04, 2017 at 12:51:13PM +, Davi

Re: [GIT PULL] hash addresses printed with %p

On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote: > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote: > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote: > > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote: > > > > From: Ard Biesheuvel >

Re: [GIT PULL] hash addresses printed with %p

On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote: > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote: > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote: > > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote: > > > > From: Ard Biesheuvel >

Re: [GIT PULL] hash addresses printed with %p

On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote: > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote: > > From: Ard Biesheuvel > > > Sent: 04 December 2017 10:03 > > ... > > > and uses __ATTR_RO() to emit initializers for it. __ATTR() initializes > > > the .store member as well, which

Re: [GIT PULL] hash addresses printed with %p

On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote: > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote: > > From: Ard Biesheuvel > > > Sent: 04 December 2017 10:03 > > ... > > > and uses __ATTR_RO() to emit initializers for it. __ATTR() initializes > > > the .store member as well, which

Re: [GIT PULL] hash addresses printed with %p

On 12/04/17 at 08:36am, Greg Kroah-Hartman wrote: > On Mon, Dec 04, 2017 at 10:02:16AM +0800, Dave Young wrote: > > +#define __ATTR_IRUSR(_name) { > > \ > > + .attr = { .name = __stringify(_name), .mode = S_IRUSR }, \ &g

Re: [GIT PULL] hash addresses printed with %p

On 12/04/17 at 08:36am, Greg Kroah-Hartman wrote: > On Mon, Dec 04, 2017 at 10:02:16AM +0800, Dave Young wrote: > > +#define __ATTR_IRUSR(_name) { > > \ > > + .attr = { .name = __stringify(_name), .mode = S_IRUSR }, \ &g

Re: [GIT PULL] hash addresses printed with %p

On 12/03/17 at 06:33pm, Joe Perches wrote: > On Mon, 2017-12-04 at 10:02 +0800, Dave Young wrote: > > I think 0400 is good enough for this issue. > > > > Greg, would you like to agree add an extra macro like below? > [] > > -static struct map_attribute map_type_attr

Re: [GIT PULL] hash addresses printed with %p

On 12/03/17 at 06:33pm, Joe Perches wrote: > On Mon, 2017-12-04 at 10:02 +0800, Dave Young wrote: > > I think 0400 is good enough for this issue. > > > > Greg, would you like to agree add an extra macro like below? > [] > > -static struct map_attribute map_type_attr

Re: [GIT PULL] hash addresses printed with %p

On 12/02/17 at 10:22pm, Matt Fleming wrote: > (Cc'ing Dave since this is used for kexec on EFI) > > On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote: > > On 1 December 2017 at 09:48, Greg Kroah-Hartman > > wrote: > > > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard

Re: [GIT PULL] hash addresses printed with %p

On 12/02/17 at 10:22pm, Matt Fleming wrote: > (Cc'ing Dave since this is used for kexec on EFI) > > On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote: > > On 1 December 2017 at 09:48, Greg Kroah-Hartman > > wrote: > > > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote: > > >> On

Re: [GIT PULL] hash addresses printed with %p

On 12/02/17 at 10:22pm, Matt Fleming wrote: > (Cc'ing Dave since this is used for kexec on EFI) > > On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote: > > On 1 December 2017 at 09:48, Greg Kroah-Hartman > > wrote: > > > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard

Re: [GIT PULL] hash addresses printed with %p

On 12/02/17 at 10:22pm, Matt Fleming wrote: > (Cc'ing Dave since this is used for kexec on EFI) > > On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote: > > On 1 December 2017 at 09:48, Greg Kroah-Hartman > > wrote: > > > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote: > > >> On

<    1   2   3   4   5   6   7   8   9   10   >