Hi Jason & Michael,
Kindly ping... Any progress for the efa .shutdown implementing? Thanks
in advance!
Thanks,
Tao Liu
On Wed, Apr 3, 2024 at 11:44 PM Jason Gunthorpe wrote:
>
> On Mon, Apr 01, 2024 at 04:23:32PM +0300, Margolin, Michael wrote:
> > Jason
> >
> &
fa_main.c, the issue doesn't get reproduced. It looks to me
the issue can be solved by this code change, however according to
Jason, there might be problems. I'm not familiar with this, could you
please try to fix this issue? Thanks in advance!
Thanks,
Tao Liu
>
> Michael
>
> On 3/26/202
Hi Gal,
On Mon, Mar 25, 2024 at 4:06 PM Gal Pressman wrote:
>
> On 25/03/2024 4:10, Tao Liu wrote:
> > Hi,
> >
> > Recently I experienced a kernel panic which is related to efa module
> > when testing kexec -l && kexec -e to switch to a new kernel on AWS
&
emented either. Since I'm
not very familiar with the efa driver, could you please implement the
.shutdown method in drivers/infiniband/hw/efa/efa_main.c? Thanks in
advance!
[1]:
https://github.com/torvalds/linux/blob/master/drivers/infiniband/hw/efa/efa_main.c#
view. I would be glad for any feedback.
>
> Thomas, Ingo, Borislav, Dave,
>
> Any feedback?
>
> Is there anything else I can do to get the patchset moving?
>
I tested the patchset with Linux 6.8-rc6, no problem found. With the
patchset, a vmcore can be generated successfully in
Hi Jiri,
On Sun, Nov 26, 2023 at 5:22 AM Jiri Bohac wrote:
>
> Hi Tao,
>
> On Sat, Nov 25, 2023 at 09:51:54AM +0800, Tao Liu wrote:
> > Thanks for the idea of using CMA as part of memory for the 2nd kernel.
> > However I have a question:
> >
> > What
> reservation cannot be used.
>
Thanks for the idea of using CMA as part of memory for the 2nd kernel.
However I have a question:
What if there is on-going DMA/RDMA access on the CMA range when 1st
kernel crash? There might be data corruption when 2nd kernel and
DMA/RDMA write to the same
u support for kexec reboot?
>
> You would need a patched BIOS image. I've hacked one[1] for my testing.
> But it only works if kernel runs in 4-level paging mode (specify no5lvl in
> kernel command line).
>
> BIOS folks work on proper patch, but it is not ready yet.
>
> [1
Add kexec to the CC list so kexec people can know this.
On Thu, Aug 3, 2023 at 10:55 AM Tao Liu wrote:
>
> Previously no .shutdown() hook is implemented for iwlwifi driver, a
> ETIMEDOUT error will occur during the kexec kernel bootup. As a
> consequence, wifi is unusable
Hi Borislav,
On Sat, Jul 29, 2023 at 12:56 AM Borislav Petkov wrote:
>
> On Thu, Jul 27, 2023 at 07:03:26PM +0800, Tao Liu wrote:
> > Hi Borislav,
> >
> > Sorry for the late response. I spent some time retesting your patch
> > against 6.5.0-rc1 and 6.5.0-rc3, and
Hi Ard,
On Mon, Jul 17, 2023 at 11:11 PM Tao Liu wrote:
>
> On Mon, Jul 17, 2023 at 10:57 PM Ard Biesheuvel wrote:
> >
> > On Mon, 17 Jul 2023 at 15:53, Tao Liu wrote:
> > >
> > > Hi Borislav,
> > >
> > > On Thu, Jul 13, 2023 at 6:05 PM
Hi Borislav,
Sorry for the late response. I spent some time retesting your patch
against 6.5.0-rc1 and 6.5.0-rc3, and it is OK. So
Reported-and-tested-by: Tao Liu
And will we use this patch as a workaround or will we wait for a
better solution as proposed by Michael?
On Mon, Jul 17, 2023
On Mon, Jul 17, 2023 at 10:57 PM Ard Biesheuvel wrote:
>
> On Mon, 17 Jul 2023 at 15:53, Tao Liu wrote:
> >
> > Hi Borislav,
> >
> > On Thu, Jul 13, 2023 at 6:05 PM Borislav Petkov wrote:
> > >
> > > On Thu, Jun 01, 2023 at 03:20:44P
g code is up.
Yes, if we can defer the cc blob access, the issue can be resolved. I
don't know if it is doable from AMD's view...
>
> If this is problematic, we might instead disable SEV for kexec, and
> rely on the fact that SEV firmware enters with a complete 1:1 map (as
We still need
On Mon, Jul 17, 2023 at 10:14 PM Borislav Petkov wrote:
>
> On Mon, Jul 17, 2023 at 09:53:06PM +0800, Tao Liu wrote:
> > ...snip...
> > [ 21.360763] nvme0n1: p1 p2 p3
> > [ 21.364207] igc :03:00.0: PTM enabled, 4ns granularity
> > [ 21.421097]
Hi Borislav,
On Thu, Jul 13, 2023 at 6:05 PM Borislav Petkov wrote:
>
> On Thu, Jun 01, 2023 at 03:20:44PM +0800, Tao Liu wrote:
> > arch/x86/kernel/machine_kexec_64.c | 35 ++
> > 1 file changed, 31 insertions(+), 4 deletions(-)
>
> Ok, pls t
Hi Borislav,
Thanks for the patch review!
On Thu, Jul 6, 2023 at 1:34 AM Borislav Petkov wrote:
>
> On Thu, Jun 01, 2023 at 03:20:44PM +0800, Tao Liu wrote:
> > A kexec kernel bootup hang is observed on Intel Atom cpu due to unmapped
>
> s/cpu/CPU/g
>
> > EFI config t
,
Tao Liu
On Thu, Jun 1, 2023 at 4:25 PM Tao Liu wrote:
>
> Hi Baoquan,
>
> On Thu, Jun 1, 2023 at 4:13 PM Baoquan He wrote:
> >
> > On 06/01/23 at 03:20pm, Tao Liu wrote:
> > > A kexec kernel bootup hang is observed on Intel Atom cpu due to unmapped
> > &g
Hi Baoquan,
On Thu, Jun 1, 2023 at 4:13 PM Baoquan He wrote:
>
> On 06/01/23 at 03:20pm, Tao Liu wrote:
> > A kexec kernel bootup hang is observed on Intel Atom cpu due to unmapped
> > EFI config table.
> >
> > Currently EFI system table is identity-mapped
not be mapped into
due to 2 MB page size, thus a page fault hang is more likely to happen.
This patch will make sure the EFI config table is always mapped.
Signed-off-by: Tao Liu
---
Changes in v2:
- Rephrase the change log based on Baoquan's suggestion.
- Rename map_efi_sys_cfg_tab() to map_efi_
Hi Baoquan,
On Fri, May 26, 2023 at 12:08 PM Baoquan He wrote:
>
> Hi Tao,
>
> On 05/25/23 at 05:49pm, Tao Liu wrote:
> > A kexec kernel bootup hang is observed on Intel Atom cpu due to unmapped
> > EFI config table.
> >
> > Currently EFI system table is
not be mapped into
due to 2 MB page size, thus a page fault hang is more likely to happen.
In this patch, we will make sure the EFI config table is always mapped.
Signed-off-by: Tao Liu
---
arch/x86/kernel/machine_kexec_64.c | 35 ++
1 file changed, 31 insertions(+), 4 d
Hi Tom,
On Fri, Apr 29, 2022 at 08:08:28AM -0500, Tom Lendacky wrote:
> On 4/29/22 04:06, Tao Liu wrote:
> > On Thu, Jan 27, 2022 at 11:10:34AM +0100, Joerg Roedel wrote:
>
> >
> > Hi Joerg,
> >
> > I tried the patch set with 5.17.0-rc1 kernel, an
Young .
[1]: http://lists.infradead.org/pipermail/kexec/2018-April/020568.html
Signed-off-by: Tao Liu
---
v1 -> v2:
Modified commit log based on Baoquan's advice.
---
kernel/crash_core.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/kernel/crash_core.
.
This patch is a resend of [1] and rebased onto v5.19-rc2, and the
original credit goes to Dave Young .
[1]: http://lists.infradead.org/pipermail/kexec/2018-April/020568.html
Signed-off-by: Tao Liu
---
kernel/crash_core.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git
to
/sysroot/var/crash/127.0.0.1-2022-04-18-05:58:50/
[2.804355] kdump[555]: saving vmcore-dmesg.txt complete
[2.806915] kdump[557]: saving vmcore
^ vmcore can still be generated
...
[7.068981] reboot: Restarting system
[7.069340] reboot: machine
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
, Loading zstd initrd will cause an error(what error? who
prints the error?) ZSTD-data is corrupt error on qemu(how do you know
the data is corrupt? what attempts did you make?).
Please note upstream is not responsible for the distribution specific issues.
Thanks,
Tao Liu
On Wed, Mar 16, 2022 at 10:33
produce it.
Thanks,
Tao Liu
> Am Mi., 16. März 2022 um 14:58 Uhr schrieb Tao Liu :
> >
> > Hi Baoquan,
> >
> > On Wed, Mar 16, 2022 at 7:38 PM Baoquan He wrote:
> > >
> > > Cc Tao,
> > >
> > > On 03/16/22 at 11:57am, Tobias Powalows
my project:
> > Loading zstd initrd will cause an error:
> > ZSTD-data is corrupt error on qemu.
> > Is there a fix or workaround for this issue?
>
> Hi Tao,
>
> Did you ever met this when you introduce zstd to kexec/kdump?
>
No, I haven't encountered this issue
4534 5327454123
> > > > > > zstd-1 459.066807 5748037931
> > > > > > zstd0 561.687525 4680009013
> > > > > > zstd1 547.248917 4706358547
> > > > > >
Hi Kazu,
Thanks for reviewing the patchset!
On Tue, Sep 14, 2021 at 07:04:24AM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Tao Liu,
>
> Thanks for the patchset!
>
> -Original Message-
> > This patch set adds ZSTD compression support to makedumpfile. With ZSTD
> &
Signed-off-by: Tao Liu
Signed-off-by: Coiby Xu
---
makedumpfile.8 | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/makedumpfile.8 b/makedumpfile.8
index f782e5f..3022d9c 100644
--- a/makedumpfile.8
+++ b/makedumpfile.8
@@ -132,10 +132,11 @@ configuration, you need
Signed-off-by: Tao Liu
Signed-off-by: Coiby Xu
---
README | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/README b/README
index 6629440..0b17cf1 100644
--- a/README
+++ b/README
@@ -49,7 +49,10 @@
7.Build with snappy support:
# make USESNAPPY=on ; make install
Signed-off-by: Tao Liu
Signed-off-by: Coiby Xu
---
print_info.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/print_info.c b/print_info.c
index 8b28554..e4bfefc 100644
--- a/print_info.c
+++ b/print_info.c
@@ -38,6 +38,11 @@ show_version
Signed-off-by: Tao Liu
---
makedumpfile.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index e70d882..2514eb6 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -919,7 +919,7 @@ readpage_kdump_compressed_parallel(int fd_memory
Signed-off-by: Tao Liu
Signed-off-by: Coiby Xu
---
makedumpfile.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index af21a84..e70d882 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -832,7 +832,7 @@ readpage_kdump_compressed
Signed-off-by: Tao Liu
Signed-off-by: Coiby Xu
---
makedumpfile.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/makedumpfile.c b/makedumpfile.c
index 100b407..f3bf297 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -4171,6 +4171,15 @@ initial(void)
}
#endif
Signed-off-by: Tao Liu
Signed-off-by: Coiby Xu
---
makedumpfile.c | 41 -
makedumpfile.h | 3 +++
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index f3bf297..76a7a77 100644
--- a/makedumpfile.c
+++ b
Signed-off-by: Tao Liu
Signed-off-by: Coiby Xu
---
makedumpfile.c | 5 -
makedumpfile.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index 157..100b407 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -11656,7 +11656,7 @@ main
Signed-off-by: Tao Liu
Signed-off-by: Coiby Xu
---
diskdump_mod.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/diskdump_mod.h b/diskdump_mod.h
index 3733953..e4bce5c 100644
--- a/diskdump_mod.h
+++ b/diskdump_mod.h
@@ -98,6 +98,7 @@ struct kdump_sub_header {
#define
Signed-off-by: Tao Liu
---
makedumpfile.c | 26 ++
makedumpfile.h | 6 ++
2 files changed, 32 insertions(+)
diff --git a/makedumpfile.c b/makedumpfile.c
index 76a7a77..af21a84 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -3892,6 +3892,12
Signed-off-by: Tao Liu
Signed-off-by: Coiby Xu
---
Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/Makefile b/Makefile
index 5d61a69..725c186 100644
--- a/Makefile
+++ b/Makefile
@@ -68,6 +68,11 @@ endif
CFLAGS += -DUSESNAPPY
endif
+ifeq ($(USEZSTD), on)
+LIBS := -lzstd
For zstd2/zlib/lzo/snappy, zstd2 has the smallest vmcore size, also
the best time consumption and vmcore dump size balance.
Tao Liu (11):
Add dump header for zstd.
Add command-line processing for zstd
Add zstd build support
Notify zstd unsupporting when disabled
Add single thr
contains PT_LOAD program headers which have
physaddr(). With -E option, makedumpfile will try to convert
the physaddr to an offset and fails.
In this patch, let's skip the PT_LOAD program headers which have such physaddr.
Signed-off-by: Tao Liu
---
makedumpfile.c | 3 +++
1 file
Hello Eric,
I have the patch tested in the following cases:
x86_64, kernel 5.11.11, KASLR off;
x86_64, kernel 5.11.11, KASLR on;
x86_64, kernel 5.12.0-rc7, KASLR off;
x86_64, kernel 5.12.0-rc7, KASLR on;
All cases are good to me, I can dump the vmcores and
get them analyzed in cras
46 matches
Mail list logo
