[PATCH] kexec_file: do not add extra alignment to efi memmap

Chun-Yi reported a kernel warning message below: WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 early_iounmap+0x4f/0x12c() early_iounmap(ff200180, 0118) [0] size not consistent 0120 The problem is x86 kexec_file_load adds extra alignment to the efi memmap: in bzImage64_load()

[PATCH net-next v4 3/3] cxgb4: collect hardware dump in second kernel

Register callback to collect hardware/firmware dumps in second kernel before hardware/firmware is initialized. The dumps for each device will be available as elf notes in /proc/vmcore in second kernel. Signed-off-by: Rahul Lakkireddy Signed-off-by: Ganesh Goudar

[PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

On production servers running variety of workloads over time, kernel panic can happen sporadically after days or even months. It is important to collect as much debug logs as possible to root cause and fix the problem, that may not be easy to reproduce. Snapshot of underlying hardware/firmware

[PATCH net-next v4 1/3] vmcore: add API to collect hardware dump in second kernel

The sequence of actions done by device drivers to append their device specific hardware/firmware logs to /proc/vmcore are as follows: 1. During probe (before hardware is initialized), device drivers register to the vmcore module (via vmcore_add_device_dump()), with callback function, along with

[PATCH net-next v4 2/3] vmcore: append device dumps to vmcore as elf notes

Update read and mmap logic to append device dumps as additional notes before the other elf notes. We add device dumps before other elf notes because the other elf notes may not fill the elf notes buffer completely and we will end up with zero-filled data between the elf notes and the device dumps.

Re: kdump in upstream kexec-tools

On Tue, Apr 17, 2018 at 10:20:08AM +0530, Bhupesh Sharma wrote: > Hi, > > I was working on improving documentation/structure of the upstream > kexec-tools and I was wondering what is the purpose of the 'kdump' > directory inside the kexec-tools. > > This kdump utility seems to cause confusion

Re: kdump in upstream kexec-tools

On Tue, Apr 17, 2018 at 04:20:00PM +0530, Bhupesh Sharma wrote: > For e.g I use this tool on my arm64 board as follows: > > a. Read out the 'elfcorehdr' env variable passed to the crash kernel > and pass the same as an argument to the tool: > > Assuming that the 'elfcorehdr' spans the range -> >

Re: [PATCH v1 0/2] kexec: Remove "weak" annotations from headers

On Fri, Apr 13, 2018 at 11:08:20AM +0200, Philipp Rudo wrote: > Hi Bjorn, > > in recent patches AKASHI [1] and I [2] made some changes to the declarations > you are touching and already removed some of the weak statements. The patches > got accepted on linux-next and will (hopefully) be pulled

Re: [PATCH v1 0/2] kexec: Remove "weak" annotations from headers

On Fri, Apr 13, 2018 at 05:29:08PM +0800, Baoquan He wrote: > Hi Bjorn, > > There are changes I have made to solve 5-level conflict with > kexec/kdump and also interface unification task, they will involve x86 > 64 only changes on these functions, I don't think we need remove them if > without

Re: [PATCH v1 0/2] kexec: Remove "weak" annotations from headers

On 04/17/18 at 09:07am, Bjorn Helgaas wrote: > On Fri, Apr 13, 2018 at 05:29:08PM +0800, Baoquan He wrote: > > Hi Bjorn, > > > > There are changes I have made to solve 5-level conflict with > > kexec/kdump and also interface unification task, they will involve x86 > > 64 only changes on these

Re: kdump in upstream kexec-tools

On Tue, Apr 17, 2018 at 6:21 PM, Russell King wrote: > On Tue, Apr 17, 2018 at 04:20:00PM +0530, Bhupesh Sharma wrote: >> For e.g I use this tool on my arm64 board as follows: >> >> a. Read out the 'elfcorehdr' env variable passed to the crash kernel >> and pass the same as

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

On Mon, Apr 16, 2018 at 06:35:22PM -0600, Randy Wright wrote: > ... I will plan to run the same test tomorrow on > a build of the SuSE 4.4.120-94.17 kernel, on which I had also reported > the original bug. I carried out the test on the older kernel today. I found the version of