On 12/02/17 at 11:34am, Dave Young wrote:
> Since below commit earlyprintk=efi,keep does not work any more with a warning
> in mm/early_ioremap.c: WARN_ON(system_state >= SYSTEM_RUNNING):
Should be WARN_ON(system_state != SYSTEM_BOOTING) in original code, copy
paste wrongly, if need
On 12/02/17 at 11:34am, Dave Young wrote:
> Since below commit earlyprintk=efi,keep does not work any more with a warning
> in mm/early_ioremap.c: WARN_ON(system_state >= SYSTEM_RUNNING):
Should be WARN_ON(system_state != SYSTEM_BOOTING) in original code, copy
paste wrongly, if need
system_state < SYSTEM_RUNNING. But with commit 69a78ff226fe it is not true
any more. Change the WARN_ON to check system_state >= SYSTEM_RUNNING instead.
Signed-off-by: Dave Young <dyo...@redhat.com>
---
mm/early_ioremap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-x8
system_state < SYSTEM_RUNNING. But with commit 69a78ff226fe it is not true
any more. Change the WARN_ON to check system_state >= SYSTEM_RUNNING instead.
Signed-off-by: Dave Young
---
mm/early_ioremap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-x86.orig/mm/early_ioremap
Mouse as
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
[ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse
[PixArt HP USB Optical Mouse] on usb-:00:14.0-2/input0
Signed-off-by: Dave Young <dyo...@redhat.com>
Cc: sta...@vger.kern
Mouse as
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
[ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse
[PixArt HP USB Optical Mouse] on usb-:00:14.0-2/input0
Signed-off-by: Dave Young
Cc: sta...@vger.kernel.org
---
v1->v2: reb
7.ga3...@dhcp-128-65.nay.redhat.com
In zero_resv_unavail it would be better to check pfn_valid first before zero
the page struct. This fixes the problem and potential other similar problems.
Also as Pavel Tatashin suggested checks pfn_valid at the beginning of the
section.
Signed-off-by: Dave Young <dyo...
7.ga3...@dhcp-128-65.nay.redhat.com
In zero_resv_unavail it would be better to check pfn_valid first before zero
the page struct. This fixes the problem and potential other similar problems.
Also as Pavel Tatashin suggested checks pfn_valid at the beginning of the
section.
Signed-off-by: Dave Young
---
v1->
On 12/01/17 at 10:42am, Michal Hocko wrote:
> On Fri 01-12-17 17:29:51, Dave Young wrote:
> > On 12/01/17 at 10:19am, Michal Hocko wrote:
> > > On Fri 01-12-17 16:56:57, Dave Young wrote:
> > > > On 11/30/17 at 10:35am, Michal Hocko wrote:
> > > [...]
&
On 12/01/17 at 10:42am, Michal Hocko wrote:
> On Fri 01-12-17 17:29:51, Dave Young wrote:
> > On 12/01/17 at 10:19am, Michal Hocko wrote:
> > > On Fri 01-12-17 16:56:57, Dave Young wrote:
> > > > On 11/30/17 at 10:35am, Michal Hocko wrote:
> > > [...]
&
On 12/01/17 at 10:19am, Michal Hocko wrote:
> On Fri 01-12-17 16:56:57, Dave Young wrote:
> > On 11/30/17 at 10:35am, Michal Hocko wrote:
> [...]
> > > Can we exclude that range from the memblock allocator instead? E.g. what
> > > happens if somebody allocates from th
On 12/01/17 at 10:19am, Michal Hocko wrote:
> On Fri 01-12-17 16:56:57, Dave Young wrote:
> > On 11/30/17 at 10:35am, Michal Hocko wrote:
> [...]
> > > Can we exclude that range from the memblock allocator instead? E.g. what
> > > happens if somebody allocates from th
On 11/30/17 at 12:25pm, Pavel Tatashin wrote:
> Hi Dave,
>
> Because unavailable memory can be in the middle of a section, I think
> a proper fix would be to do pfn_valid() check only at the beginning of
> section. Otherwise, we might miss zeroing a struct page is in the
> middle of a section
On 11/30/17 at 10:35am, Michal Hocko wrote:
> On Thu 30-11-17 14:04:31, 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]
On 11/30/17 at 12:25pm, Pavel Tatashin wrote:
> Hi Dave,
>
> Because unavailable memory can be in the middle of a section, I think
> a proper fix would be to do pfn_valid() check only at the beginning of
> section. Otherwise, we might miss zeroing a struct page is in the
> middle of a section
On 11/30/17 at 10:35am, Michal Hocko wrote:
> On Thu 30-11-17 14:04:31, 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]
)
Use "add_efi_memmap" can workaround the problem with another fix:
https://lkml.org/lkml/2017/11/30/5
In zero_resv_unavail it would be better to check pfn_valid first before zero
the page struct. This fixes the problem and potential other similar problems.
Signed-off-by: Dave Young &l
" can workaround the problem with another fix:
https://lkml.org/lkml/2017/11/30/5
In zero_resv_unavail it would be better to check pfn_valid first before zero
the page struct. This fixes the problem and potential other similar problems.
Signed-off-by: Dave Young
---
mm/page_alloc.c |2 ++
1 fi
efi_memblock_x86_reserve_range to fix
this.
Signed-off-by: Dave Young <dyo...@redhat.com>
---
arch/x86/kernel/setup.c | 55
1 file changed, 28 insertions(+), 27 deletions(-)
--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/ar
efi_memblock_x86_reserve_range to fix
this.
Signed-off-by: Dave Young
---
arch/x86/kernel/setup.c | 55
1 file changed, 28 insertions(+), 27 deletions(-)
--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -897,6
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/
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/
On 11/27/17 at 09:49am, Benjamin Tissoires wrote:
> On Nov 27 2017 or thereabouts, Greg KH wrote:
> > On Mon, Nov 27, 2017 at 09:16:31AM +0100, Benjamin Tissoires wrote:
> > > On Nov 25 2017 or thereabouts, Dave Young wrote:
> > > > This mouse keep disconnectin
On 11/27/17 at 09:49am, Benjamin Tissoires wrote:
> On Nov 27 2017 or thereabouts, Greg KH wrote:
> > On Mon, Nov 27, 2017 at 09:16:31AM +0100, Benjamin Tissoires wrote:
> > > On Nov 25 2017 or thereabouts, Dave Young wrote:
> > > > This mouse keep disconnectin
Mouse as
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
[ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse
[PixArt HP USB Optical Mouse] on usb-:00:14.0-2/input0
Signed-off-by: Dave Young <dyo...@redhat.com>
---
drivers/hid/hid
Mouse as
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
[ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse
[PixArt HP USB Optical Mouse] on usb-:00:14.0-2/input0
Signed-off-by: Dave Young
---
drivers/hid/hid-ids.h |1
that pefile verification can use
secondary keyring as well.
Signed-off-by: Dave Young <dyo...@redhat.com>
---
certs/system_keyring.c |2 --
1 file changed, 2 deletions(-)
--- linux-x86.orig/certs/system_keyring.c
+++ linux-x86/certs/system_keyring.c
@@ -229,8 +229,6 @@ int verify_pkcs7_signature
that pefile verification can use
secondary keyring as well.
Signed-off-by: Dave Young
---
certs/system_keyring.c |2 --
1 file changed, 2 deletions(-)
--- linux-x86.orig/certs/system_keyring.c
+++ linux-x86/certs/system_keyring.c
@@ -229,8 +229,6 @@ int verify_pkcs7_signature(const void *d
On 11/15/17 at 01:47pm, Baoquan He wrote:
> Hi Dave,
>
> Thanks for your effort to push this into upstream. While I have one
> concern, please see the inline comments.
>
> On 10/24/17 at 01:31pm, Dave Young wrote:
> > Now crashkernel=X will fail if there's not eno
On 11/15/17 at 01:47pm, Baoquan He wrote:
> Hi Dave,
>
> Thanks for your effort to push this into upstream. While I have one
> concern, please see the inline comments.
>
> On 10/24/17 at 01:31pm, Dave Young wrote:
> > Now crashkernel=X will fail if there's not eno
-4G:128M, size will be 0 in case system
memory is less than 2G.
Signed-off-by: Dave Young <dyo...@redhat.com>
---
[v1 -> v2]: bhsharma: pr_warn looks confusing because of return 0
kernel/crash_core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-x86.orig/kernel/cra
-4G:128M, size will be 0 in case system
memory is less than 2G.
Signed-off-by: Dave Young
---
[v1 -> v2]: bhsharma: pr_warn looks confusing because of return 0
kernel/crash_core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-x86.orig/kernel/crash_core.c
+++ linux-
ton <a...@linux-foundation.org>
> CC: Baoquan He <b...@redhat.com>
> CC: Dave Young <dyo...@redhat.com>
> CC: Dave Young <dyo...@redhat.com>
> CC: Hari Bathini <hbath...@linux.vnet.ibm.com>
> CC: Tony Luck <tony.l...@intel.com>
> CC: Vivek Goyal
> CC: Baoquan He
> CC: Dave Young
> CC: Dave Young
> CC: Hari Bathini
> CC: Tony Luck
> CC: Vivek Goyal
> Signed-off-by: Marc-André Lureau
> Acked-by: Gabriel Somlo
> ---
> kernel/crash_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --g
On 10/24/17 at 01:31pm, Dave Young wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size. One can use
> crashkernel=xM,high to reserve it at high region (>4G) but it is more
> convinient to improv
On 10/24/17 at 01:31pm, Dave Young wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size. One can use
> crashkernel=xM,high to reserve it at high region (>4G) but it is more
> convinient to improv
dmi/smbios to get physical memory size, but it's not
reliable as well. According to Prarit hardware vendors sometimes screw this up.
Thus round up total size to 128M to workaround this problem.
Signed-off-by: Dave Young <dyo...@redhat.com>
---
Changes from previous version of 3/3:
1. i
dmi/smbios to get physical memory size, but it's not
reliable as well. According to Prarit hardware vendors sometimes screw this up.
Thus round up total size to 128M to workaround this problem.
Signed-off-by: Dave Young
---
Changes from previous version of 3/3:
1. improve changelog: add examples
Hi Baoquan,
On 10/24/17 at 01:57pm, Baoquan He wrote:
> Hi Dave,
>
> On 10/24/17 at 01:31pm, Dave Young wrote:
> > The total memory size we get in kernel is usually slightly less than 2G
> > with a
> > 2G memory module machine. The main reason is bios
Hi Baoquan,
On 10/24/17 at 01:57pm, Baoquan He wrote:
> Hi Dave,
>
> On 10/24/17 at 01:31pm, Dave Young wrote:
> > The total memory size we get in kernel is usually slightly less than 2G
> > with a
> > 2G memory module machine. The main reason is bios
Hi Baoquan,
On 10/24/17 at 02:00pm, Baoquan He wrote:
> On 10/24/17 at 01:31pm, Dave Young wrote:
> > crashkernel=range:size syntax allows to reserve specified size for system
> > with total memory fall into the specified range. For example:
> > crashkernel=2G-3G:128M,3
Hi Baoquan,
On 10/24/17 at 02:00pm, Baoquan He wrote:
> On 10/24/17 at 01:31pm, Dave Young wrote:
> > crashkernel=range:size syntax allows to reserve specified size for system
> > with total memory fall into the specified range. For example:
> > crashkernel=2G-3G:128M,3
On 10/20/17 at 01:52pm, Dave Young wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size. One can use
> crashkernel=xM,high to reserve it at high region (>4G) but it is more
> convinient to improv
On 10/20/17 at 01:52pm, Dave Young wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size. One can use
> crashkernel=xM,high to reserve it at high region (>4G) but it is more
> convinient to improv
On 10/21/17 at 12:20am, Yinghai Lu wrote:
> On Thu, Oct 19, 2017 at 10:52 PM, Dave Young <dyo...@redhat.com> wrote:
> > Now crashkernel=X will fail if there's not enough memory at low region
> > (below 896M) when trying to reserve large memory size. One can use
> > cra
On 10/21/17 at 12:20am, Yinghai Lu wrote:
> On Thu, Oct 19, 2017 at 10:52 PM, Dave Young wrote:
> > Now crashkernel=X will fail if there's not enough memory at low region
> > (below 896M) when trying to reserve large memory size. One can use
> > crashkernel=xM,high to rese
ot; parameter to the kernel
Then try loading kdump kernel
crashkernel: 896M-4G:
# cat /proc/iomem|grep Crash
9600-cdef : Crash kernel
# ./kexec -p /boot/vmlinuz-4.14.0-rc4+
ELF core (kcore) parse failed
Cannot load /boot/vmlinuz-4.14.0-rc4+
Signed-off-by: Dave Young <dyo...@redhat.com>
-
ot; parameter to the kernel
Then try loading kdump kernel
crashkernel: 896M-4G:
# cat /proc/iomem|grep Crash
9600-cdef : Crash kernel
# ./kexec -p /boot/vmlinuz-4.14.0-rc4+
ELF core (kcore) parse failed
Cannot load /boot/vmlinuz-4.14.0-rc4+
Signed-off-by: Dave Young
---
arch/x86/kernel/s
On 09/25/17 at 04:03pm, Dave Young wrote:
> HI AKASHI,
> On 09/22/17 at 04:58pm, AKASHI Takahiro wrote:
> > Hi Dave,
> >
> [snip]
>
> > > > /*
> > > > * Apply purgatory relocations.
> > > > *
> > > > diff --git a/
On 09/25/17 at 04:03pm, Dave Young wrote:
> HI AKASHI,
> On 09/22/17 at 04:58pm, AKASHI Takahiro wrote:
> > Hi Dave,
> >
> [snip]
>
> > > > /*
> > > > * Apply purgatory relocations.
> > > > *
> > > > diff --git a/
HI AKASHI,
On 09/22/17 at 04:58pm, AKASHI Takahiro wrote:
> Hi Dave,
>
[snip]
> > > /*
> > > * Apply purgatory relocations.
> > > *
> > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > > index dd056fab9e35..4a2b24d94e04 100644
> > > --- a/include/linux/kexec.h
> > > +++
HI AKASHI,
On 09/22/17 at 04:58pm, AKASHI Takahiro wrote:
> Hi Dave,
>
[snip]
> > > /*
> > > * Apply purgatory relocations.
> > > *
> > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > > index dd056fab9e35..4a2b24d94e04 100644
> > > --- a/include/linux/kexec.h
> > > +++
Hi AKASHI,
On 09/15/17 at 07:59pm, AKASHI Takahiro wrote:
> arch_kexec_kernel_*() and arch_kimage_file_post_load_cleanup can now be
> duplicated among some architectures, so let's factor them out.
>
> Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
> Cc: Dave You
Hi AKASHI,
On 09/15/17 at 07:59pm, AKASHI Takahiro wrote:
> arch_kexec_kernel_*() and arch_kimage_file_post_load_cleanup can now be
> duplicated among some architectures, so let's factor them out.
>
> Signed-off-by: AKASHI Takahiro
> Cc: Dave Young
> Cc: Vivek Goyal
>
Missed a comma in cc list in last reply, readd linux-efi list in cc.
On 09/14/17 at 04:08pm, Baoquan He wrote:
> On 09/14/17 at 03:49pm, Dave Young wrote:
> > > > diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
> > > > index b5a322
Missed a comma in cc list in last reply, readd linux-efi list in cc.
On 09/14/17 at 04:08pm, Baoquan He wrote:
> On 09/14/17 at 03:49pm, Dave Young wrote:
> > > > diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
> > > > index b5a322
Cc linux-efi list
On 09/14/17 at 04:08pm, Baoquan He wrote:
> On 09/14/17 at 03:49pm, Dave Young wrote:
> > > > diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
> > > > index b5a32231abd8..93d7ad8763ba 100644
> > > > --- a/arch/x86/inc
Cc linux-efi list
On 09/14/17 at 04:08pm, Baoquan He wrote:
> On 09/14/17 at 03:49pm, Dave Young wrote:
> > > > diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
> > > > index b5a32231abd8..93d7ad8763ba 100644
> > > > --- a/arch/x86/inc
On 09/14/17 at 03:29pm, Baoquan He wrote:
> Add Dave to the CC list, he may have concerns about the code change.
Baoquan, thanks for cc me
>
> On 09/07/17 at 03:42pm, Baoquan He wrote:
> > The BIOS on SGI UV system will report a UV system table which describes
> > specific firmware capabilities
On 09/14/17 at 03:29pm, Baoquan He wrote:
> Add Dave to the CC list, he may have concerns about the code change.
Baoquan, thanks for cc me
>
> On 09/07/17 at 03:42pm, Baoquan He wrote:
> > The BIOS on SGI UV system will report a UV system table which describes
> > specific firmware capabilities
Hi,
On 09/08/17 at 12:16pm, AKASHI Takahiro wrote:
[snip]
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -162,6 +162,25 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> int (*func)(u64, u64, void *));
> extern int kexec_add_buffer(struct
Hi,
On 09/08/17 at 12:16pm, AKASHI Takahiro wrote:
[snip]
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -162,6 +162,25 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> int (*func)(u64, u64, void *));
> extern int kexec_add_buffer(struct
> > +int arch_kimage_file_post_load_cleanup(struct kimage *image)
> > +{
> > + vfree(image->arch.dtb_buf);
> > + image->arch.dtb_buf = NULL;
> > +
> > + vfree(image->arch.elf_headers);
> > + image->arch.elf_headers = NULL;
> > + image->arch.elf_headers_sz = 0;
> > +
> > + if
> > +int arch_kimage_file_post_load_cleanup(struct kimage *image)
> > +{
> > + vfree(image->arch.dtb_buf);
> > + image->arch.dtb_buf = NULL;
> > +
> > + vfree(image->arch.elf_headers);
> > + image->arch.elf_headers = NULL;
> > + image->arch.elf_headers_sz = 0;
> > +
> > + if
Hi,
On 09/08/17 at 12:16pm, AKASHI Takahiro wrote:
> load_other_segments() sets up and adds all the memory segments necessary
> other than kernel, including initrd, device-tree blob and purgatory.
> Most of the code was borrowed from kexec-tools' counterpart.
>
> In addition,
Hi,
On 09/08/17 at 12:16pm, AKASHI Takahiro wrote:
> load_other_segments() sets up and adds all the memory segments necessary
> other than kernel, including initrd, device-tree blob and purgatory.
> Most of the code was borrowed from kexec-tools' counterpart.
>
> In addition,
On 08/25/17 at 11:03am, AKASHI Takahiro wrote:
> On Thu, Aug 24, 2017 at 06:30:50PM +0100, Mark Rutland wrote:
> > On Thu, Aug 24, 2017 at 05:18:11PM +0900, AKASHI Takahiro wrote:
> > > The first PT_LOAD segment, which is assumed to be "text" code, in vmlinux
> > > will be loaded at the offset of
On 08/25/17 at 11:03am, AKASHI Takahiro wrote:
> On Thu, Aug 24, 2017 at 06:30:50PM +0100, Mark Rutland wrote:
> > On Thu, Aug 24, 2017 at 05:18:11PM +0900, AKASHI Takahiro wrote:
> > > The first PT_LOAD segment, which is assumed to be "text" code, in vmlinux
> > > will be loaded at the offset of
On 08/24/17 at 05:18pm, AKASHI Takahiro wrote:
> prepare_elf_headers() can also be useful for other architectures,
> including arm64. So let it factored out.
>
> Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
> Cc: Dave Young <dyo...@redhat.com>
> Cc:
On 08/24/17 at 05:18pm, AKASHI Takahiro wrote:
> prepare_elf_headers() can also be useful for other architectures,
> including arm64. So let it factored out.
>
> Signed-off-by: AKASHI Takahiro
> Cc: Dave Young
> Cc: Vivek Goyal
> Cc: Baoquan He
> ---
> ar
On 06/27/17 at 08:39pm, Baoquan He wrote:
> People complained that crashkernel high doesn't work when kaslr code
> compiled in but add 'nokaslr' to diable it. Kexec has the same
> phenomenon.
This is a regression, with 4.12* kernel kexec reboot fails always on
my desktop pc now without kaslr
On 06/27/17 at 08:39pm, Baoquan He wrote:
> People complained that crashkernel high doesn't work when kaslr code
> compiled in but add 'nokaslr' to diable it. Kexec has the same
> phenomenon.
This is a regression, with 4.12* kernel kexec reboot fails always on
my desktop pc now without kaslr
Commit-ID: 792ef14df5c585c19b2831673a077504a09e5203
Gitweb: http://git.kernel.org/tip/792ef14df5c585c19b2831673a077504a09e5203
Author: Dave Young <dyo...@redhat.com>
AuthorDate: Fri, 9 Jun 2017 08:45:58 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Fri, 9 Jun 2
Commit-ID: 792ef14df5c585c19b2831673a077504a09e5203
Gitweb: http://git.kernel.org/tip/792ef14df5c585c19b2831673a077504a09e5203
Author: Dave Young
AuthorDate: Fri, 9 Jun 2017 08:45:58 +
Committer: Ingo Molnar
CommitDate: Fri, 9 Jun 2017 14:50:11 +0200
efi: Fix boot panic because
Kernel panic - not syncing: Attempted to kill the idle
task!
Fixes: 7b0a911 efi/x86: Move the EFI BGRT init code to early init code
Reported-by: Maniaxx <tripleshift...@gmail.com>
Signed-off-by: Dave Young <dyo...@redhat.com>
---
v1->v2: Ard: move EFI_MEMMAP checking out and improve the
o kill the idle
task!
Fixes: 7b0a911 efi/x86: Move the EFI BGRT init code to early init code
Reported-by: Maniaxx
Signed-off-by: Dave Young
---
v1->v2: Ard: move EFI_MEMMAP checking out and improve the patchlog.
drivers/firmware/efi/efi-bgrt.c | 26 +-
1 file ch
On 06/09/17 at 10:29am, Dave Young wrote:
> On 06/09/17 at 10:17am, Xunlei Pang wrote:
> > S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which
> > is now defined as follows:
> > typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4];
> > It was changed by th
On 06/09/17 at 10:29am, Dave Young wrote:
> On 06/09/17 at 10:17am, Xunlei Pang wrote:
> > S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which
> > is now defined as follows:
> > typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4];
> > It was changed by th
On 06/08/17 at 03:51pm, Ard Biesheuvel wrote:
> On 8 June 2017 at 05:32, Dave Young <dyo...@redhat.com> wrote:
> > Maniaxx <tripleshift...@gmail.com> reported kernel boot panic similar to
> > below:
> > (emulated the panic with using same invalid phys addr in a
On 06/08/17 at 03:51pm, Ard Biesheuvel wrote:
> On 8 June 2017 at 05:32, Dave Young wrote:
> > Maniaxx reported kernel boot panic similar to
> > below:
> > (emulated the panic with using same invalid phys addr in a uefi vm)
> > There are also a bug in bug
rid of all the old KEXEC_NOTE_BYTES stuff, and
> renames KEXEC_NOTE_BYTES to CRASH_CORE_NOTE_BYTES for S390.
>
> Fixes: 692f66f26a4c ("crash: move crashkernel parsing and vmcore related code
> under CONFIG_CRASH_CORE")
> Cc: Dave Young <dyo...@redhat.com>
> Cc: Dave Ande
rid of all the old KEXEC_NOTE_BYTES stuff, and
> renames KEXEC_NOTE_BYTES to CRASH_CORE_NOTE_BYTES for S390.
>
> Fixes: 692f66f26a4c ("crash: move crashkernel parsing and vmcore related code
> under CONFIG_CRASH_CORE")
> Cc: Dave Young
> Cc: Dave Anderson
> Cc: Hari Bathini
&
On 06/08/17 at 10:02am, Ard Biesheuvel wrote:
> On 8 June 2017 at 05:32, Dave Young <dyo...@redhat.com> wrote:
> > Maniaxx <tripleshift...@gmail.com> reported kernel boot panic similar to
> > below:
> > (emulated the panic with using same invalid phys addr in a
On 06/08/17 at 10:02am, Ard Biesheuvel wrote:
> On 8 June 2017 at 05:32, Dave Young wrote:
> > Maniaxx reported kernel boot panic similar to
> > below:
> > (emulated the panic with using same invalid phys addr in a uefi vm)
> > There are also a bug in bug
, Dave Young wrote:
> Maniaxx <tripleshift...@gmail.com> reported kernel boot panic similar to
> below:
> (emulated the panic with using same invalid phys addr in a uefi vm)
> There are also a bug in bugzilla.kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=195633
&g
, Dave Young wrote:
> Maniaxx reported kernel boot panic similar to
> below:
> (emulated the panic with using same invalid phys addr in a uefi vm)
> There are also a bug in bugzilla.kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=195633
>
> This happens after below
xes: 7b0a911 efi/x86: Move the EFI BGRT init code to early init code
Reported-by: Maniaxx <tripleshift...@gmail.com>
Signed-off-by: Dave Young <dyo...@redhat.com>
---
drivers/firmware/efi/efi-bgrt.c | 29 +
1 file changed, 29 insertions(+)
--- linux.orig/
I BGRT init code to early init code
Reported-by: Maniaxx
Signed-off-by: Dave Young
---
drivers/firmware/efi/efi-bgrt.c | 29 +
1 file changed, 29 insertions(+)
--- linux.orig/drivers/firmware/efi/efi-bgrt.c
+++ linux/drivers/firmware/efi/efi-bgrt.c
@@ -27,6 +27,31 @@
Commit-ID: 7425826f4f7ac60f2538b06a7f0a5d1006405159
Gitweb: http://git.kernel.org/tip/7425826f4f7ac60f2538b06a7f0a5d1006405159
Author: Dave Young <dyo...@redhat.com>
AuthorDate: Fri, 26 May 2017 12:36:51 +0100
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sun, 28 Ma
Commit-ID: 7425826f4f7ac60f2538b06a7f0a5d1006405159
Gitweb: http://git.kernel.org/tip/7425826f4f7ac60f2538b06a7f0a5d1006405159
Author: Dave Young
AuthorDate: Fri, 26 May 2017 12:36:51 +0100
Committer: Ingo Molnar
CommitDate: Sun, 28 May 2017 11:06:17 +0200
efi/bgrt: Skip efi_bgrt_init
On 05/26/17 at 12:17pm, Xunlei Pang wrote:
> On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
> > Provide support so that kexec can be used to boot a kernel when SME is
> > enabled.
> >
> > Support is needed to allocate pages for kexec without encryption. This
> > is needed in order to be able to
On 05/26/17 at 12:17pm, Xunlei Pang wrote:
> On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
> > Provide support so that kexec can be used to boot a kernel when SME is
> > enabled.
> >
> > Support is needed to allocate pages for kexec without encryption. This
> > is needed in order to be able to
Ccing Xunlei he is reading the patches see what need to be done for
kdump. There should still be several places to handle to make kdump work.
On 05/18/17 at 07:01pm, Borislav Petkov wrote:
> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
> > Add sysfs support for SME so that
Ccing Xunlei he is reading the patches see what need to be done for
kdump. There should still be several places to handle to make kdump work.
On 05/18/17 at 07:01pm, Borislav Petkov wrote:
> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
> > Add sysfs support for SME so that
o build ident mapping, instead need copy pud entry
> one by one from direct mapping.
>
> Fix it.
>
> Signed-off-by: Baoquan He <b...@redhat.com>
> Signed-off-by: Dave Young <dyo...@redhat.com>
Although I put some effort on debugging the problem, the patch should
be your credi
o build ident mapping, instead need copy pud entry
> one by one from direct mapping.
>
> Fix it.
>
> Signed-off-by: Baoquan He
> Signed-off-by: Dave Young
Although I put some effort on debugging the problem, the patch should
be your credit, also I'm not familiar with the pgtable wa
Add Takahiro and Pratyush, they should be able to review the arm64 part.
On 05/18/17 at 11:03am, Bharat Bhushan wrote:
> This patch have minor updates in Documentation for arm64i as
> relocatable kernel.
> Also this patch updates documentation for using uncompressed
> image "Image" which is used
Add Takahiro and Pratyush, they should be able to review the arm64 part.
On 05/18/17 at 11:03am, Bharat Bhushan wrote:
> This patch have minor updates in Documentation for arm64i as
> relocatable kernel.
> Also this patch updates documentation for using uncompressed
> image "Image" which is used
o build ident mapping, instead need copy pud entry
> one by one from direct mapping.
>
> Fix it.
>
> Signed-off-by: Baoquan He <b...@redhat.com>
> Signed-off-by: Dave Young <dyo...@redhat.com>
> Cc: Matt Fleming <m...@codeblueprint.co.uk>
> Cc: Ard Biesheuve
o build ident mapping, instead need copy pud entry
> one by one from direct mapping.
>
> Fix it.
>
> Signed-off-by: Baoquan He
> Signed-off-by: Dave Young
> Cc: Matt Fleming
> Cc: Ard Biesheuvel
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin&q
401 - 500 of 2643 matches
Mail list logo
