Convert kdump documentation to ReST and add it to the
user faced manual, as the documents are mainly focused on
sysadmins that would be enabling kdump.
Note: the vmcoreinfo.rst has one very long title for
sub-sections. I opted to break this one, in order to make it
easier to display in html.
This series convert lots of files to be properly parsed by Sphinx
as ReST files.
As it touches on lot of stuff, the series is based on linux-next.
I have a separate patch series with do the actual rename and
adjustment of references. I opted to submit this first, as it
sounds easier to merge
Hi Mike,
On 2019/4/16 3:09, Mike Rapoport wrote:
> Hi,
>
> On Mon, Apr 15, 2019 at 06:57:23PM +0800, Chen Zhou wrote:
>> The memblock_cap_memory_range() removes all the memory except the
>> range passed to it. Extend this function to receive memblock_type
>> with the regions that should be kept.
On 4/16/19 8:00 AM, Junichi Nomura wrote:
> On 4/15/19 7:25 PM, Borislav Petkov wrote:
>> On Mon, Apr 15, 2019 at 11:07:17AM +0200, Borislav Petkov wrote:
>>> On Mon, Apr 15, 2019 at 07:01:54AM +, Junichi Nomura wrote:
OK. Then I'll go back to v3 and make sure to hang when
something
On 4/15/19 7:25 PM, Borislav Petkov wrote:
> On Mon, Apr 15, 2019 at 11:07:17AM +0200, Borislav Petkov wrote:
>> On Mon, Apr 15, 2019 at 07:01:54AM +, Junichi Nomura wrote:
>>> OK. Then I'll go back to v3 and make sure to hang when
>>> something is wrong during kexec boot on EFI system.
>>
>>
Hi,
On Mon, Apr 15, 2019 at 06:57:23PM +0800, Chen Zhou wrote:
> The memblock_cap_memory_range() removes all the memory except the
> range passed to it. Extend this function to receive memblock_type
> with the regions that should be kept.
>
> Enable this function in arm64 for reservation of
在 2019年04月02日 20:43, Borislav Petkov 写道:
> On Tue, Apr 02, 2019 at 08:02:04PM +0800, lijiang wrote:
>> These regions(E820_TYPE_{RESERVED_KERN,RAM,UNUSABLE}) are still marked as
>> IORES_DESC_NONE and should not be mapped encrypted when using ioremap().
>
> Seems to me like we're going in circles.
After commit (arm64: kdump: support reserving crashkernel above 4G),
there may be two crash kernel regions, one is below 4G, the other is
above 4G. Use memblock_cap_memory_ranges() to support multiple crash
kernel regions.
Crash dump kernel reads more than one crash kernel regions via a dtb
Now we support crashkernel=X,[high,low] on arm64, update the
Documentation.
Signed-off-by: Chen Zhou
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
When crashkernel is reserved above 4G in memory, kernel should
reserve some amount of low memory for swiotlb and some DMA buffers.
Kernel would try to allocate at least 256M below 4G automatically
as x86_64 if crashkernel is above 4G. Meanwhile, support
crashkernel=X,[high,low] in arm64.
The memblock_cap_memory_range() removes all the memory except the
range passed to it. Extend this function to receive memblock_type
with the regions that should be kept.
Enable this function in arm64 for reservation of multiple regions
for the crash kernel.
Signed-off-by: Chen Zhou
In preparation for supporting more than one crash kernel regions
in arm64 as x86_64 does, move reserve_crashkernel_low() into
kexec/kexec_core.c.
Signed-off-by: Chen Zhou
---
arch/x86/include/asm/kexec.h | 3 ++
arch/x86/kernel/setup.c | 66 +---
When crashkernel is reserved above 4G in memory, kernel should reserve
some amount of low memory for swiotlb and some DMA buffers. So there may
be two crash kernel regions, one is below 4G, the other is above 4G.
Crash dump kernel reads more than one crash kernel regions via a dtb
property under
On Mon, Apr 15, 2019 at 11:07:17AM +0200, Borislav Petkov wrote:
> On Mon, Apr 15, 2019 at 07:01:54AM +, Junichi Nomura wrote:
> > OK. Then I'll go back to v3 and make sure to hang when
> > something is wrong during kexec boot on EFI system.
>
> No need - I have it here locally. I'll clean it
On Mon, Apr 15, 2019 at 07:01:54AM +, Junichi Nomura wrote:
> OK. Then I'll go back to v3 and make sure to hang when
> something is wrong during kexec boot on EFI system.
No need - I have it here locally. I'll clean it up and post it for
review.
--
Regards/Gruss,
Boris.
Good mailing
On 04/12/19 at 08:23am, Baoquan He wrote:
> On 04/11/19 at 09:14am, Junichi Nomura wrote:
> > On 4/11/19 5:42 PM, Baoquan He wrote:
> > > On 04/11/19 at 08:16am, Junichi Nomura wrote:
> > >> kexec_get_rsdp_addr() might fail on kexec-booted kernel, e.g. if the
> > >> setup_data was invalid. In such
On 4/12/19 10:35 PM, Borislav Petkov wrote:
> On Fri, Apr 12, 2019 at 10:49:56AM +0200, Borislav Petkov wrote:
>> Now I need to go figure out whether there's a reliable way to know in
>> the kexec kernel that it *is* a kexec kernel.
>
> Actually, thinking about this more, we don't need to know
17 matches
Mail list logo
