Le 10/12/2021 à 17:59, Andrew Morton a écrit :
> On Fri, 10 Dec 2021 21:36:00 +0800 Tiezhu Yang wrote:
>
>> In arch/*/kernel/crash_dump*.c, there exist similar code about
>> copy_oldmem_page(), move copy_to() from vmcore.c to uaccess.h,
>> and then we can use copy_to() to simplify the related c
In arch/*/kernel/crash_dump*.c, there exist many similar code
about copy_oldmem_page(), remove copy_to() in fs/proc/vmcore.c
and add copy_to_user_or_kernel() in lib/usercopy.c, then we can
use copy_to_user_or_kernel() to simplify the related code.
Signed-off-by: Tiezhu Yang
---
fs/proc/vmcore.c
Use copy_to_user_or_kernel() to simplify the related code about
copy_oldmem_page() in arch/*/kernel/crash_dump*.c files.
Signed-off-by: Tiezhu Yang
---
arch/arm/kernel/crash_dump.c | 12 +++-
arch/arm64/kernel/crash_dump.c | 12 +++-
arch/ia64/kernel/crash_dump.c| 12 ++
v2:
-- add copy_to_user_or_kernel() in lib/usercopy.c
-- define userbuf as bool type
Tiezhu Yang (2):
kdump: vmcore: remove copy_to() and add copy_to_user_or_kernel()
kdump: crashdump: use copy_to_user_or_kernel() to simplify code
arch/arm/kernel/crash_dump.c | 12 +++-
arch/
On 2021-12-10 10:13 a.m., Christian König wrote:
Am 10.12.21 um 15:25 schrieb Guilherme G. Piccoli:
On 10/12/2021 11:16, Alex Deucher wrote:> [...]
Why not just reload the driver after kexec?
Alex
Because the original issue is the kdump case, and we want a very very
tiny kernel - also, the
On 12/11/2021 12:59 AM, Andrew Morton wrote:
On Fri, 10 Dec 2021 21:36:00 +0800 Tiezhu Yang wrote:
In arch/*/kernel/crash_dump*.c, there exist similar code about
copy_oldmem_page(), move copy_to() from vmcore.c to uaccess.h,
and then we can use copy_to() to simplify the related code.
...
---
On 12/8/21 11:13 AM, Catalin Marinas wrote:
On Tue, Nov 23, 2021 at 08:46:35PM +0800, Zhen Lei wrote:
Chen Zhou (10):
x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN
x86: kdump: make the lower bound of crash kernel reservation
consistent
x86: kdump: use macro CR
On Fri, Dec 10, 2021 at 10:24 AM Guilherme G. Piccoli
wrote:
>
> On 10/12/2021 12:13, Christian König wrote:
> > [...]
> > How about issuing a PCIe reset and re-initializing the ASIC with just
> > the VBIOS?
> >
> > That should be pretty straightforward I think.
> >
> > Christian.
>
>
> Thanks Chr
On Fri, Dec 10, 2021 at 9:25 AM Guilherme G. Piccoli
wrote:
>
> On 10/12/2021 11:16, Alex Deucher wrote:> [...]
> > Why not just reload the driver after kexec?
> >
> > Alex
>
> Because the original issue is the kdump case, and we want a very very
> tiny kernel - also, the crash originally could ha
On Fri, 10 Dec 2021 21:36:00 +0800 Tiezhu Yang wrote:
> In arch/*/kernel/crash_dump*.c, there exist similar code about
> copy_oldmem_page(), move copy_to() from vmcore.c to uaccess.h,
> and then we can use copy_to() to simplify the related code.
>
> ...
>
> --- a/fs/proc/vmcore.c
> +++ b/fs/proc
On Fri, 10 Dec 2021 14:55:32 +0800, Zhen Lei wrote:
> From: Chen Zhou
>
> When reserving crashkernel in high memory, some low memory is reserved
> for crash dump kernel devices and never mapped by the first kernel.
> This memory range is advertised to crash dump kernel via DT property
> under /ch
On Fri, 10 Dec 2021 14:55:31 +0800, Zhen Lei wrote:
> Currently, we parse the "linux,usable-memory-range" property in
> early_init_dt_scan_chosen(), to obtain the specified memory range of the
> crash kernel. We then reserve the required memory after
> early_init_dt_scan_memory() has identified all
Am 10.12.21 um 16:24 schrieb Guilherme G. Piccoli:
On 10/12/2021 12:13, Christian König wrote:
[...]
How about issuing a PCIe reset and re-initializing the ASIC with just
the VBIOS?
That should be pretty straightforward I think.
Christian.
Thanks Christian, that'd be perfect! Is it feasible?
On 10/12/2021 12:13, Christian König wrote:
> [...]
> How about issuing a PCIe reset and re-initializing the ASIC with just
> the VBIOS?
>
> That should be pretty straightforward I think.
>
> Christian.
Thanks Christian, that'd be perfect! Is it feasible? Per Alex comment,
we'd need to run ato
Am 10.12.21 um 15:25 schrieb Guilherme G. Piccoli:
On 10/12/2021 11:16, Alex Deucher wrote:> [...]
Why not just reload the driver after kexec?
Alex
Because the original issue is the kdump case, and we want a very very
tiny kernel - also, the crash originally could have been caused by
amdgpu
On 10/12/2021 11:16, Alex Deucher wrote:> [...]
> Why not just reload the driver after kexec?
>
> Alex
Because the original issue is the kdump case, and we want a very very
tiny kernel - also, the crash originally could have been caused by
amdgpu itself, so if it's a GPU issue, we don't want to m
On Fri, Dec 10, 2021 at 9:09 AM Guilherme G. Piccoli
wrote:
>
> Thanks a lot Alex / Gerd and Thomas, very informative stuff! I'm glad
> there are projects to collect/save the data and reuse after a kdump,
> this is very useful.
>
> I'll continue my study on the atombios thing of AMD and QXL, maybe
Thanks a lot Alex / Gerd and Thomas, very informative stuff! I'm glad
there are projects to collect/save the data and reuse after a kdump,
this is very useful.
I'll continue my study on the atombios thing of AMD and QXL, maybe at
least we can make it work in qemu, that'd be great (like a small
ini
Use copy_to() to simplify the related code about copy_oldmem_page()
in arch/*/kernel/crash_dump*.c files.
Signed-off-by: Tiezhu Yang
---
arch/arm/kernel/crash_dump.c | 10 ++
arch/arm64/kernel/crash_dump.c | 10 ++
arch/ia64/kernel/crash_dump.c| 10 --
arch/mips
Tiezhu Yang (2):
kdump: vmcore: move copy_to() from vmcore.c to uaccess.h
kdump: crashdump: use copy_to() to simplify the related code
arch/arm/kernel/crash_dump.c | 10 ++
arch/arm64/kernel/crash_dump.c | 10 ++
arch/ia64/kernel/crash_dump.c| 10 --
arch/mip
In arch/*/kernel/crash_dump*.c, there exist similar code about
copy_oldmem_page(), move copy_to() from vmcore.c to uaccess.h,
and then we can use copy_to() to simplify the related code.
Signed-off-by: Tiezhu Yang
---
fs/proc/vmcore.c| 14 --
include/linux/uaccess.h | 14 +
21 matches
Mail list logo
