Re: [PATCH v7 0/4] kexec: Fix kexec_file_load for llvm16 with PGO
Hi Song On Fri, 8 Sept 2023 at 23:48, Song Liu wrote: > > Hi Ricardo, > > Thanks for your kind reply. > > On Fri, Sep 8, 2023 at 2:18 PM Ricardo Ribalda wrote: > > > > Hi Song > > > > On Fri, 8 Sept 2023 at 01:08, Song Liu wrote: > > > > > > Hi Ricardo and folks, > > > > > > On Fri, May 19, 2023 at 7:48 AM Ricardo Ribalda > > > wrote: > > > > > > > > When upreving llvm I realised that kexec stopped working on my test > > > > platform. > > > > > > > > The reason seems to be that due to PGO there are multiple .text sections > > > > on the purgatory, and kexec does not supports that. > > > > > > > > Signed-off-by: Ricardo Ribalda > > > > > > We are seeing WARNINGs like the following while kexec'ing a PGO and > > > LTO enabled kernel: > > > > > > WARNING: CPU: 26 PID: 110894 at kernel/kexec_file.c:919 > > > kexec_load_purgatory+0x37f/0x390 > > > > > > AFAICT, the warning was added by this set, and it was triggered when > > > we have many .text sections > > > in purgatory.ro. The kexec was actually successful. So I wonder > > > whether we really need the > > > WARNING here. If we disable LTO (PGO is still enabled), we don't see > > > the WARNING any more. > > > > > > I also tested an older kernel (5.19 based), where we also see many > > > .text sections with LTO. It > > > kexec()'ed fine. (It doesn't have the WARN_ON() in > > > kexec_purgatory_setup_sechdrs). > > > > You have been "lucky" that the code has chosen the correct start > > address, you need to modify the linker script of your kernel to > > disable PGO. > > You need to backport a patch like this: > > https://lore.kernel.org/lkml/CAPhsuW5_qAvV0N3o+hOiAnb1=buj1plzqyw9d+bwft6hxjv...@mail.gmail.com/T/#md68b7f832216b0c56bbec0c9b07332e180b9ba2b > > We already have this commit in our branch. AFAICT, the issue was > triggered by LTO. So something like the following seems fixes it > (I haven't finished the end-to-end test yet). Does this change make > sense to you? if the end-to-end works, please send it as a patch to the mailing list. Thanks! :) > > Thanks again, > Song > > diff --git i/arch/x86/purgatory/Makefile w/arch/x86/purgatory/Makefile > index 8f71aaa04cc2..dc306fa7197d 100644 > --- i/arch/x86/purgatory/Makefile > +++ w/arch/x86/purgatory/Makefile > @@ -19,6 +19,10 @@ CFLAGS_sha256.o := -D__DISABLE_EXPORTS > # optimization flags. > KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=% > -fprofile-use=%,$(KBUILD_CFLAGS)) > > +# When LTO is enabled, llvm emits many text sections, which is not supported > +# by kexec. Remove -flto=* flags. > +KBUILD_CFLAGS := $(filter-out -flto=%,$(KBUILD_CFLAGS)) > + > # When linking purgatory.ro with -r unresolved symbols are not checked, > # also link a purgatory.chk binary without -r to check for unresolved > symbols. > PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib -- Ricardo Ribalda
Re: [PATCH v7 0/4] kexec: Fix kexec_file_load for llvm16 with PGO
Hi Song On Fri, 8 Sept 2023 at 01:08, Song Liu wrote: > > Hi Ricardo and folks, > > On Fri, May 19, 2023 at 7:48 AM Ricardo Ribalda wrote: > > > > When upreving llvm I realised that kexec stopped working on my test > > platform. > > > > The reason seems to be that due to PGO there are multiple .text sections > > on the purgatory, and kexec does not supports that. > > > > Signed-off-by: Ricardo Ribalda > > We are seeing WARNINGs like the following while kexec'ing a PGO and > LTO enabled kernel: > > WARNING: CPU: 26 PID: 110894 at kernel/kexec_file.c:919 > kexec_load_purgatory+0x37f/0x390 > > AFAICT, the warning was added by this set, and it was triggered when > we have many .text sections > in purgatory.ro. The kexec was actually successful. So I wonder > whether we really need the > WARNING here. If we disable LTO (PGO is still enabled), we don't see > the WARNING any more. > > I also tested an older kernel (5.19 based), where we also see many > .text sections with LTO. It > kexec()'ed fine. (It doesn't have the WARN_ON() in > kexec_purgatory_setup_sechdrs). You have been "lucky" that the code has chosen the correct start address, you need to modify the linker script of your kernel to disable PGO. You need to backport a patch like this: https://lore.kernel.org/lkml/CAPhsuW5_qAvV0N3o+hOiAnb1=buj1plzqyw9d+bwft6hxjv...@mail.gmail.com/T/#md68b7f832216b0c56bbec0c9b07332e180b9ba2b (assuming x86) Regards > > Please help us fix this properly (as I really don't know much about kexec). > > Thanks in advance, > Song > > > Here is readelf -S output on purgatory.ro. > > With LTO: > > readelf -W -S purgatory.ro > There are 48 section headers, starting at offset 0x4a10: > > Section Headers: > [Nr] Name TypeAddress OffSize > ES Flg Lk Inf Al > [ 0] NULL 00 > 00 00 0 0 0 > [ 1] .text PROGBITS 40 > d0 00 AX 0 0 16 > [ 2] .data PROGBITS 001000 > 001000 00 WA 0 0 4096 > [ 3] .rela.textRELA 003788 > 000228 18 I 45 1 8 > [ 4] .rodata PROGBITS 002000 > e0 00 A 0 0 16 > [ 5] .rela.rodata RELA 0039b0 > 30 18 I 45 4 8 > [ 6] .bss NOBITS 0020e0 > 001000 00 WA 0 0 4096 > [ 7] .text.purgatory PROGBITS 0020e0 > df 00 AX 0 0 16 > [ 8] .rela.text.purgatory RELA 0039e0 > 60 18 I 45 7 8 > [ 9] .text.warnPROGBITS 0021c0 > 01 00 AX 0 0 16 > [10] .kexec-purgatory PROGBITS 0021d0 > 000120 00 WA 0 0 16 > [11] .comment PROGBITS 003a40 > 46 01 MS 0 0 1 > [12] .llvm_addrsig LOOS+0xfff4c03 003a86 > 05 00 E 0 0 1 > [13] .text.sha256_update PROGBITS 0022f0 > 0008eb 00 AX 0 0 16 > [14] .rela.text.sha256_update RELA > 003a90 60 18 I 45 13 8 > [15] .text.sha224_update PROGBITS 002be0 > 0c 00 AX 0 0 16 > [16] .rela.text.sha224_update RELA > 003af0 18 18 I 45 15 8 > [17] .text.sha256_final PROGBITS 002bf0 > cd 00 AX 0 0 16 > [18] .rela.text.sha256_final RELA 003b08 > 30 18 I 45 17 8 > [19] .text.sha224_final PROGBITS 002cc0 > bd 00 AX 0 0 16 > [20] .rela.text.sha224_final RELA 003b38 > 30 18 I 45 19 8 > [21] .text.sha256 PROGBITS 002d80 > 00011d 00 AX 0 0 16 > [22] .rela.text.sha256 RELA 003b68 > 30 18 I 45 21 8 > [23] .modinfo PROGBITS 002e9d > 39 00 A 0 0 1 > [24] .rodata.SHA256_K PROGBITS 002ee0 > 000100 00 A 0 0 16 > [25] .rodata.__sha256_final.padding PROGBITS > 002fe0 40 00 A 0 0 16 > [26] .text.memcmp PROGBITS 003020 > 0b 00 AX 0 0 16 > [27] .text.bcmpPROGBITS 003030 > 0b 00 AX 0 0 16 > [28] .text.strcmp PROGBITS 003040 > 41 00 AX 0 0 16 > [29] .text.strncmp PROGBITS 003090 > 3a 00 AX 0 0
[PATCH v7 4/4] riscv/purgatory: Remove PGO flags
If profile-guided optimization is enabled, the purgatory ends up with
multiple .text sections.
This is not supported by kexec and crashes the system.
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Acked-by: Palmer Dabbelt
Signed-off-by: Ricardo Ribalda
---
arch/riscv/purgatory/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/purgatory/Makefile b/arch/riscv/purgatory/Makefile
index 5730797a6b40..bd2e27f82532 100644
--- a/arch/riscv/purgatory/Makefile
+++ b/arch/riscv/purgatory/Makefile
@@ -35,6 +35,11 @@ CFLAGS_sha256.o := -D__DISABLE_EXPORTS
CFLAGS_string.o := -D__DISABLE_EXPORTS
CFLAGS_ctype.o := -D__DISABLE_EXPORTS
+# When profile-guided optimization is enabled, llvm emits two different
+# overlapping text sections, which is not supported by kexec. Remove profile
+# optimization flags.
+KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
-fprofile-use=%,$(KBUILD_CFLAGS))
+
# When linking purgatory.ro with -r unresolved symbols are not checked,
# also link a purgatory.chk binary without -r to check for unresolved symbols.
PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib
--
2.40.1.698.g37aff9b760-goog
[PATCH v7 3/4] powerpc/purgatory: Remove PGO flags
If profile-guided optimization is enabled, the purgatory ends up with
multiple .text sections.
This is not supported by kexec and crashes the system.
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Signed-off-by: Ricardo Ribalda
---
arch/powerpc/purgatory/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/purgatory/Makefile b/arch/powerpc/purgatory/Makefile
index 6f5e2727963c..78473d69cd2b 100644
--- a/arch/powerpc/purgatory/Makefile
+++ b/arch/powerpc/purgatory/Makefile
@@ -5,6 +5,11 @@ KCSAN_SANITIZE := n
targets += trampoline_$(BITS).o purgatory.ro
+# When profile-guided optimization is enabled, llvm emits two different
+# overlapping text sections, which is not supported by kexec. Remove profile
+# optimization flags.
+KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
-fprofile-use=%,$(KBUILD_CFLAGS))
+
LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined
$(obj)/purgatory.ro: $(obj)/trampoline_$(BITS).o FORCE
--
2.40.1.698.g37aff9b760-goog
[PATCH v7 2/4] x86/purgatory: Remove PGO flags
If profile-guided optimization is enabled, the purgatory ends up with
multiple .text sections.
This is not supported by kexec and crashes the system.
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Signed-off-by: Ricardo Ribalda
---
arch/x86/purgatory/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 82fec66d46d2..42abd6af1198 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -14,6 +14,11 @@ $(obj)/sha256.o: $(srctree)/lib/crypto/sha256.c FORCE
CFLAGS_sha256.o := -D__DISABLE_EXPORTS
+# When profile-guided optimization is enabled, llvm emits two different
+# overlapping text sections, which is not supported by kexec. Remove profile
+# optimization flags.
+KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
-fprofile-use=%,$(KBUILD_CFLAGS))
+
# When linking purgatory.ro with -r unresolved symbols are not checked,
# also link a purgatory.chk binary without -r to check for unresolved symbols.
PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib
--
2.40.1.698.g37aff9b760-goog
[PATCH v7 1/4] kexec: Support purgatories with .text.hot sections
Clang16 links the purgatory text in two sections when PGO is in use:
[ 1] .text PROGBITS 0040
11a1 AX 0 0 16
[ 2] .rela.textRELA 3498
0648 0018 I 24 1 8
...
[17] .text.hot.PROGBITS 3220
020b AX 0 0 1
[18] .rela.text.hot. RELA 4428
0078 0018 I 2417 8
And both of them have their range [sh_addr ... sh_addr+sh_size] on the
area pointed by `e_entry`.
This causes that image->start is calculated twice, once for .text and
another time for .text.hot. The second calculation leaves image->start
in a random location.
Because of this, the system crashes immediately after:
kexec_core: Starting new kernel
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Reviewed-by: Ross Zwisler
Reviewed-by: Steven Rostedt (Google)
Reviewed-by: Philipp Rudo
Signed-off-by: Ricardo Ribalda
---
kernel/kexec_file.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index f989f5f1933b..69ee4a29136f 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -901,10 +901,22 @@ static int kexec_purgatory_setup_sechdrs(struct
purgatory_info *pi,
}
offset = ALIGN(offset, align);
+
+ /*
+* Check if the segment contains the entry point, if so,
+* calculate the value of image->start based on it.
+* If the compiler has produced more than one .text section
+* (Eg: .text.hot), they are generally after the main .text
+* section, and they shall not be used to calculate
+* image->start. So do not re-calculate image->start if it
+* is not set to the initial value, and warn the user so they
+* have a chance to fix their purgatory's linker script.
+*/
if (sechdrs[i].sh_flags & SHF_EXECINSTR &&
pi->ehdr->e_entry >= sechdrs[i].sh_addr &&
pi->ehdr->e_entry < (sechdrs[i].sh_addr
-+ sechdrs[i].sh_size)) {
++ sechdrs[i].sh_size) &&
+ !WARN_ON(kbuf->image->start != pi->ehdr->e_entry)) {
kbuf->image->start -= sechdrs[i].sh_addr;
kbuf->image->start += kbuf->mem + offset;
}
--
2.40.1.698.g37aff9b760-goog
[PATCH v7 0/4] kexec: Fix kexec_file_load for llvm16 with PGO
When upreving llvm I realised that kexec stopped working on my test platform. The reason seems to be that due to PGO there are multiple .text sections on the purgatory, and kexec does not supports that. Signed-off-by: Ricardo Ribalda --- Changes in v7: - Fix $SUBJECT of riscv patch - Rename PGO as Profile-guided optimization - Link to v6: https://lore.kernel.org/r/20230321-kexec_clang16-v6-0-a2255e81a...@chromium.org Changes in v6: - Replace linker script with Makefile rule. Thanks Nick - Link to v5: https://lore.kernel.org/r/20230321-kexec_clang16-v5-0-5563bf7c4...@chromium.org Changes in v5: - Add warning when multiple text sections are found. Thanks Simon! - Add Fixes tag. - Link to v4: https://lore.kernel.org/r/20230321-kexec_clang16-v4-0-1340518f9...@chromium.org Changes in v4: - Add Cc: stable - Add linker script for x86 - Add a warning when the kernel image has overlapping sections. - Link to v3: https://lore.kernel.org/r/20230321-kexec_clang16-v3-0-5f016c8d0...@chromium.org Changes in v3: - Fix initial value. Thanks Ross! - Link to v2: https://lore.kernel.org/r/20230321-kexec_clang16-v2-0-d10e5d517...@chromium.org Changes in v2: - Fix if condition. Thanks Steven!. - Update Philipp email. Thanks Baoquan. - Link to v1: https://lore.kernel.org/r/20230321-kexec_clang16-v1-0-a768fc2c7...@chromium.org --- Ricardo Ribalda (4): kexec: Support purgatories with .text.hot sections x86/purgatory: Remove PGO flags powerpc/purgatory: Remove PGO flags riscv/purgatory: Remove PGO flags arch/powerpc/purgatory/Makefile | 5 + arch/riscv/purgatory/Makefile | 5 + arch/x86/purgatory/Makefile | 5 + kernel/kexec_file.c | 14 +- 4 files changed, 28 insertions(+), 1 deletion(-) --- base-commit: 58390c8ce1bddb6c623f62e7ed36383e7fa5c02f change-id: 20230321-kexec_clang16-4510c23d129c Best regards, -- Ricardo Ribalda Delgado
Re: [PATCH v6 4/4] risc/purgatory: Add linker script
Hi Conor
On Mon, 1 May 2023 at 19:41, Conor Dooley wrote:
>
> Hey Ricardo,
>
> On Mon, May 01, 2023 at 02:38:22PM +0200, Ricardo Ribalda wrote:
> > If PGO is enabled, the purgatory ends up with multiple .text sections.
> > This is not supported by kexec and crashes the system.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
> > Signed-off-by: Ricardo Ribalda
> > ---
> > arch/riscv/purgatory/Makefile | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/riscv/purgatory/Makefile b/arch/riscv/purgatory/Makefile
> > index 5730797a6b40..cf3a44121a90 100644
> > --- a/arch/riscv/purgatory/Makefile
> > +++ b/arch/riscv/purgatory/Makefile
> > @@ -35,6 +35,11 @@ CFLAGS_sha256.o := -D__DISABLE_EXPORTS
> > CFLAGS_string.o := -D__DISABLE_EXPORTS
> > CFLAGS_ctype.o := -D__DISABLE_EXPORTS
> >
> > +# When profile optimization is enabled, llvm emits two different
> > overlapping
> > +# text sections, which is not supported by kexec. Remove profile
> > optimization
> > +# flags.
> > +KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
> > -fprofile-use=%,$(KBUILD_CFLAGS))
>
> With the caveat of not being au fait with the workings of either PGO or
> of purgatory, how come you modify KBUILD_CFLAGS here rather than the
> purgatory specific PURGATORY_CFLAGS that are used later in the file?
Definitely, not a Makefile expert here, but when I tried this:
@@ -35,6 +40,7 @@ PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
PURGATORY_CFLAGS := -mcmodel=large -ffreestanding
-fno-zero-initialized-in-bss -g0
PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN) -DDISABLE_BRANCH_PROFILING
PURGATORY_CFLAGS += -fno-stack-protector
+PURGATORY_CFLAGS := $(filter-out -fprofile-sample-use=%
-fprofile-use=%,$(KBUILD_CFLAGS))
It did not work.
Fixes: bde971a83bbf ("KVM: arm64: nvhe: Fix build with profile optimization")
does this approach, so this is what I tried and worked.
Thanks!
>
> Cheers,
> Conor.
>
> > +
> > # When linking purgatory.ro with -r unresolved symbols are not checked,
> > # also link a purgatory.chk binary without -r to check for unresolved
> > symbols.
> > PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib
> >
> > --
> > 2.40.1.495.gc816e09b53d-goog
> >
> >
> > ___
> > linux-riscv mailing list
> > linux-ri...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Ricardo Ribalda
Re: [PATCH v6 4/4] risc/purgatory: Add linker script
Hi Conor
Fixed on my branch
https://git.kernel.org/pub/scm/linux/kernel/git/ribalda/linux.git/commit/?h=b4/kexec_clang16=1e9cda9fa638cc72581986f60b490cc069a38f75
Will submit a new version after a while :)
Thanks!
On Mon, 1 May 2023 at 19:28, Conor Dooley wrote:
>
> On Mon, May 01, 2023 at 07:18:12PM +0200, Ricardo Ribalda wrote:
> > On Mon, 1 May 2023 at 18:19, Nick Desaulniers
> > wrote:
> > >
> > > On Mon, May 1, 2023 at 5:39 AM Ricardo Ribalda
> > > wrote:
> > > >
> > > > If PGO is enabled, the purgatory ends up with multiple .text sections.
> > > > This is not supported by kexec and crashes the system.
> > > >
> > > > Cc: sta...@vger.kernel.org
> > > > Fixes: 930457057abe ("kernel/kexec_file.c: split up
> > > > __kexec_load_puragory")
> > > > Signed-off-by: Ricardo Ribalda
> > >
> > > Hi Ricardo,
> > > Thanks for the series. Does this patch 4/4 need a new online commit
> > > description? It's not adding a linker script (maybe an earlier version
> > > was).
>
> > Thanks for catching this. It should have said
> >
> > risc/purgatory: Remove profile optimization flags
> ^^
> Perhaps with the omitted v added too?
>
> Also while playing the $subject nitpicking game, is it not called
> "profile**-guided** optimisation" (and ditto in the comments)?
>
> Cheers,
> Conor.
>
> > Will fix it on my local branch in case there is a next version of the
> > series. Otherwise, please the maintainer fix the subject.
>
> > > > ---
> > > > arch/riscv/purgatory/Makefile | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/arch/riscv/purgatory/Makefile
> > > > b/arch/riscv/purgatory/Makefile
> > > > index 5730797a6b40..cf3a44121a90 100644
> > > > --- a/arch/riscv/purgatory/Makefile
> > > > +++ b/arch/riscv/purgatory/Makefile
> > > > @@ -35,6 +35,11 @@ CFLAGS_sha256.o := -D__DISABLE_EXPORTS
> > > > CFLAGS_string.o := -D__DISABLE_EXPORTS
> > > > CFLAGS_ctype.o := -D__DISABLE_EXPORTS
> > > >
> > > > +# When profile optimization is enabled, llvm emits two different
> > > > overlapping
> > > > +# text sections, which is not supported by kexec. Remove profile
> > > > optimization
> > > > +# flags.
> > > > +KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
> > > > -fprofile-use=%,$(KBUILD_CFLAGS))
> > > > +
> > > > # When linking purgatory.ro with -r unresolved symbols are not checked,
> > > > # also link a purgatory.chk binary without -r to check for unresolved
> > > > symbols.
> > > > PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib
> > > >
> > > > --
> > > > 2.40.1.495.gc816e09b53d-goog
> > > >
> > >
> > >
> > > --
> > > Thanks,
> > > ~Nick Desaulniers
> >
> >
> >
> > --
> > Ricardo Ribalda
> >
> > ___
> > linux-riscv mailing list
> > linux-ri...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Ricardo Ribalda
Re: [PATCH v6 4/4] risc/purgatory: Add linker script
Hi Nick
Thanks for catching this. It should have said
risc/purgatory: Remove profile optimization flags
Will fix it on my local branch in case there is a next version of the
series. Otherwise, please the maintainer fix the subject.
Thanks!
On Mon, 1 May 2023 at 18:19, Nick Desaulniers wrote:
>
> On Mon, May 1, 2023 at 5:39 AM Ricardo Ribalda wrote:
> >
> > If PGO is enabled, the purgatory ends up with multiple .text sections.
> > This is not supported by kexec and crashes the system.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
> > Signed-off-by: Ricardo Ribalda
>
> Hi Ricardo,
> Thanks for the series. Does this patch 4/4 need a new online commit
> description? It's not adding a linker script (maybe an earlier version
> was).
>
> > ---
> > arch/riscv/purgatory/Makefile | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/riscv/purgatory/Makefile b/arch/riscv/purgatory/Makefile
> > index 5730797a6b40..cf3a44121a90 100644
> > --- a/arch/riscv/purgatory/Makefile
> > +++ b/arch/riscv/purgatory/Makefile
> > @@ -35,6 +35,11 @@ CFLAGS_sha256.o := -D__DISABLE_EXPORTS
> > CFLAGS_string.o := -D__DISABLE_EXPORTS
> > CFLAGS_ctype.o := -D__DISABLE_EXPORTS
> >
> > +# When profile optimization is enabled, llvm emits two different
> > overlapping
> > +# text sections, which is not supported by kexec. Remove profile
> > optimization
> > +# flags.
> > +KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
> > -fprofile-use=%,$(KBUILD_CFLAGS))
> > +
> > # When linking purgatory.ro with -r unresolved symbols are not checked,
> > # also link a purgatory.chk binary without -r to check for unresolved
> > symbols.
> > PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib
> >
> > --
> > 2.40.1.495.gc816e09b53d-goog
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
--
Ricardo Ribalda
[PATCH v6 4/4] risc/purgatory: Add linker script
If PGO is enabled, the purgatory ends up with multiple .text sections.
This is not supported by kexec and crashes the system.
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Signed-off-by: Ricardo Ribalda
---
arch/riscv/purgatory/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/purgatory/Makefile b/arch/riscv/purgatory/Makefile
index 5730797a6b40..cf3a44121a90 100644
--- a/arch/riscv/purgatory/Makefile
+++ b/arch/riscv/purgatory/Makefile
@@ -35,6 +35,11 @@ CFLAGS_sha256.o := -D__DISABLE_EXPORTS
CFLAGS_string.o := -D__DISABLE_EXPORTS
CFLAGS_ctype.o := -D__DISABLE_EXPORTS
+# When profile optimization is enabled, llvm emits two different overlapping
+# text sections, which is not supported by kexec. Remove profile optimization
+# flags.
+KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
-fprofile-use=%,$(KBUILD_CFLAGS))
+
# When linking purgatory.ro with -r unresolved symbols are not checked,
# also link a purgatory.chk binary without -r to check for unresolved symbols.
PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib
--
2.40.1.495.gc816e09b53d-goog
[PATCH v6 3/4] powerpc/purgatory: Remove profile optimization flags
If PGO is enabled, the purgatory ends up with multiple .text sections.
This is not supported by kexec and crashes the system.
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Signed-off-by: Ricardo Ribalda
---
arch/powerpc/purgatory/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/purgatory/Makefile b/arch/powerpc/purgatory/Makefile
index 6f5e2727963c..5efb164330b2 100644
--- a/arch/powerpc/purgatory/Makefile
+++ b/arch/powerpc/purgatory/Makefile
@@ -5,6 +5,11 @@ KCSAN_SANITIZE := n
targets += trampoline_$(BITS).o purgatory.ro
+# When profile optimization is enabled, llvm emits two different overlapping
+# text sections, which is not supported by kexec. Remove profile optimization
+# flags.
+KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
-fprofile-use=%,$(KBUILD_CFLAGS))
+
LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined
$(obj)/purgatory.ro: $(obj)/trampoline_$(BITS).o FORCE
--
2.40.1.495.gc816e09b53d-goog
[PATCH v6 2/4] x86/purgatory: Remove profile optimization flags
If PGO is enabled, the purgatory ends up with multiple .text sections.
This is not supported by kexec and crashes the system.
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Signed-off-by: Ricardo Ribalda
---
arch/x86/purgatory/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 82fec66d46d2..7a7a4901ed41 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -14,6 +14,11 @@ $(obj)/sha256.o: $(srctree)/lib/crypto/sha256.c FORCE
CFLAGS_sha256.o := -D__DISABLE_EXPORTS
+# When profile optimization is enabled, llvm emits two different overlapping
+# text sections, which is not supported by kexec. Remove profile optimization
+# flags.
+KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
-fprofile-use=%,$(KBUILD_CFLAGS))
+
# When linking purgatory.ro with -r unresolved symbols are not checked,
# also link a purgatory.chk binary without -r to check for unresolved symbols.
PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib
--
2.40.1.495.gc816e09b53d-goog
[PATCH v6 0/4] kexec: Fix kexec_file_load for llvm16 with PGO
When upreving llvm I realised that kexec stopped working on my test platform. The reason seems to be that due to PGO there are multiple .text sections on the purgatory, and kexec does not supports that. Signed-off-by: Ricardo Ribalda --- Changes in v6: - Replace linker script with Makefile rule. Thanks Nick - Link to v5: https://lore.kernel.org/r/20230321-kexec_clang16-v5-0-5563bf7c4...@chromium.org Changes in v5: - Add warning when multiple text sections are found. Thanks Simon! - Add Fixes tag. - Link to v4: https://lore.kernel.org/r/20230321-kexec_clang16-v4-0-1340518f9...@chromium.org Changes in v4: - Add Cc: stable - Add linker script for x86 - Add a warning when the kernel image has overlapping sections. - Link to v3: https://lore.kernel.org/r/20230321-kexec_clang16-v3-0-5f016c8d0...@chromium.org Changes in v3: - Fix initial value. Thanks Ross! - Link to v2: https://lore.kernel.org/r/20230321-kexec_clang16-v2-0-d10e5d517...@chromium.org Changes in v2: - Fix if condition. Thanks Steven!. - Update Philipp email. Thanks Baoquan. - Link to v1: https://lore.kernel.org/r/20230321-kexec_clang16-v1-0-a768fc2c7...@chromium.org --- Ricardo Ribalda (4): kexec: Support purgatories with .text.hot sections x86/purgatory: Remove profile optimization flags powerpc/purgatory: Remove profile optimization flags risc/purgatory: Add linker script arch/powerpc/purgatory/Makefile | 5 + arch/riscv/purgatory/Makefile | 5 + arch/x86/purgatory/Makefile | 5 + kernel/kexec_file.c | 14 +- 4 files changed, 28 insertions(+), 1 deletion(-) --- base-commit: 58390c8ce1bddb6c623f62e7ed36383e7fa5c02f change-id: 20230321-kexec_clang16-4510c23d129c Best regards, -- Ricardo Ribalda
[PATCH v6 1/4] kexec: Support purgatories with .text.hot sections
Clang16 links the purgatory text in two sections when PGO is in use:
[ 1] .text PROGBITS 0040
11a1 AX 0 0 16
[ 2] .rela.textRELA 3498
0648 0018 I 24 1 8
...
[17] .text.hot.PROGBITS 3220
020b AX 0 0 1
[18] .rela.text.hot. RELA 4428
0078 0018 I 2417 8
And both of them have their range [sh_addr ... sh_addr+sh_size] on the
area pointed by `e_entry`.
This causes that image->start is calculated twice, once for .text and
another time for .text.hot. The second calculation leaves image->start
in a random location.
Because of this, the system crashes immediately after:
kexec_core: Starting new kernel
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Reviewed-by: Ross Zwisler
Reviewed-by: Steven Rostedt (Google)
Reviewed-by: Philipp Rudo
Signed-off-by: Ricardo Ribalda
---
kernel/kexec_file.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index f989f5f1933b..69ee4a29136f 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -901,10 +901,22 @@ static int kexec_purgatory_setup_sechdrs(struct
purgatory_info *pi,
}
offset = ALIGN(offset, align);
+
+ /*
+* Check if the segment contains the entry point, if so,
+* calculate the value of image->start based on it.
+* If the compiler has produced more than one .text section
+* (Eg: .text.hot), they are generally after the main .text
+* section, and they shall not be used to calculate
+* image->start. So do not re-calculate image->start if it
+* is not set to the initial value, and warn the user so they
+* have a chance to fix their purgatory's linker script.
+*/
if (sechdrs[i].sh_flags & SHF_EXECINSTR &&
pi->ehdr->e_entry >= sechdrs[i].sh_addr &&
pi->ehdr->e_entry < (sechdrs[i].sh_addr
-+ sechdrs[i].sh_size)) {
++ sechdrs[i].sh_size) &&
+ !WARN_ON(kbuf->image->start != pi->ehdr->e_entry)) {
kbuf->image->start -= sechdrs[i].sh_addr;
kbuf->image->start += kbuf->mem + offset;
}
--
2.40.1.495.gc816e09b53d-goog
Re: [PATCH v8 2/3] freezer: refactor pm_freezing into a function.
Hi Rafael
On Fri, 2 Dec 2022 at 18:48, Rafael J. Wysocki wrote:
>
> On Thu, Dec 1, 2022 at 12:08 PM Ricardo Ribalda wrote:
> >
> > Add a way to let the drivers know if the processes are frozen.
> >
> > This is needed by drivers that are waiting for processes to end on their
> > shutdown path.
> >
> > Convert pm_freezing into a function and export it, so it can be used by
> > drivers that are either built-in or modules.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine
> > drivers in .shutdown")
> > Signed-off-by: Ricardo Ribalda
>
> Why can't you export the original pm_freezing variable and why is this
> fixing anything?
Because then any module will be able to modify the content of the variable.
The Fixes: is because the last patch on the set is doing a real fix.
If you only cherry-pick the last patch on a stable branch, the build
will fail. (Also, the zero-day builder complains)
Anyway, I think we can hold this patch for a bit. The snd people are
discussing if this the way to handle it, or if we should handle
.shutdown in a different way.
Thanks!
>
> > ---
> > include/linux/freezer.h | 3 ++-
> > kernel/freezer.c| 3 +--
> > kernel/power/process.c | 24
> > 3 files changed, 23 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> > index b303472255be..3413c869d68b 100644
> > --- a/include/linux/freezer.h
> > +++ b/include/linux/freezer.h
> > @@ -13,7 +13,7 @@
> > #ifdef CONFIG_FREEZER
> > DECLARE_STATIC_KEY_FALSE(freezer_active);
> >
> > -extern bool pm_freezing; /* PM freezing in effect */
> > +bool pm_freezing(void);
> > extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
> >
> > /*
> > @@ -80,6 +80,7 @@ static inline int freeze_processes(void) { return
> > -ENOSYS; }
> > static inline int freeze_kernel_threads(void) { return -ENOSYS; }
> > static inline void thaw_processes(void) {}
> > static inline void thaw_kernel_threads(void) {}
> > +static inline bool pm_freezing(void) { return false; }
> >
> > static inline bool try_to_freeze(void) { return false; }
> >
> > diff --git a/kernel/freezer.c b/kernel/freezer.c
> > index 4fad0e6fca64..2d3530ebdb7e 100644
> > --- a/kernel/freezer.c
> > +++ b/kernel/freezer.c
> > @@ -20,7 +20,6 @@ EXPORT_SYMBOL(freezer_active);
> > * indicate whether PM freezing is in effect, protected by
> > * system_transition_mutex
> > */
> > -bool pm_freezing;
> > bool pm_nosig_freezing;
> >
> > /* protects freezing and frozen transitions */
> > @@ -46,7 +45,7 @@ bool freezing_slow_path(struct task_struct *p)
> > if (pm_nosig_freezing || cgroup_freezing(p))
> > return true;
> >
> > - if (pm_freezing && !(p->flags & PF_KTHREAD))
> > + if (pm_freezing() && !(p->flags & PF_KTHREAD))
> > return true;
> >
> > return false;
> > diff --git a/kernel/power/process.c b/kernel/power/process.c
> > index ddd9988327fe..8a4d0e2c8c20 100644
> > --- a/kernel/power/process.c
> > +++ b/kernel/power/process.c
> > @@ -108,6 +108,22 @@ static int try_to_freeze_tasks(bool user_only)
> > return todo ? -EBUSY : 0;
> > }
> >
> > +/*
> > + * Indicate whether PM freezing is in effect, protected by
> > + * system_transition_mutex.
> > + */
> > +static bool pm_freezing_internal;
> > +
> > +/**
> > + * pm_freezing - indicate whether PM freezing is in effect.
> > + *
> > + */
> > +bool pm_freezing(void)
> > +{
> > + return pm_freezing_internal;
> > +}
> > +EXPORT_SYMBOL(pm_freezing);
>
> Use EXPORT_SYMBOL_GPL() instead, please.
>
> > +
> > /**
> > * freeze_processes - Signal user space processes to enter the
> > refrigerator.
> > * The current thread will not be frozen. The same process that calls
> > @@ -126,12 +142,12 @@ int freeze_processes(void)
> > /* Make sure this task doesn't get frozen */
> > current->flags |= PF_SUSPEND_TASK;
> >
> > - if (!pm_freezing)
> > + if (!pm_freezing())
> > static_branch_inc(_active);
> >
> > pm_wakeup_clear(0);
> > pr_info("Freezing user space processes ... ");
> > - pm_freezing = true;
> > + pm_freezing_internal = true;
> > er
Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
Hi Oliver
On Thu, 1 Dec 2022 at 14:22, 'Oliver Neukum' via Chromeos Kdump
wrote:
>
> On 01.12.22 14:03, Ricardo Ribalda wrote:
>
> Hi,
>
> > This patchset does not modify this behaviour. It simply fixes the
> > stall for kexec().
> >
> > The patch that introduced the stall:
> > 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
> > in .shutdown")
>
> That patch is problematic. I would go as far as saying that
> it needs to be reverted.
>
It fixes a real issue. We have not had any complaints until we tried
to kexec in the platform.
I wont recommend reverting it until we have an alternative implementation.
kexec is far less common than suspend/reboot.
> > was sent as a generalised version of:
> > https://github.com/thesofproject/linux/pull/3388
> >
> > AFAIK, we would need a similar patch for every single board which
> > I am not sure it is doable in a reasonable timeframe.
> >
> > On the meantime this seems like a decent compromises. Yes, a
> > miss-behaving userspace can still stall during suspend, but that was
> > not introduced in this patch.
>
> Well, I mean if you know what wrong then I'd say at least return to
> a sanely broken state.
>
> The whole approach is wrong. You need to be able to deal with user
> space talking to removed devices by returning an error and keeping
> the resources association with the open file allocated until
> user space calls close()
In general, the whole shutdown is broken for all the subsystems ;).
It is a complicated issue. Users handling fds, devices with DMAs in
the middle of an operation, dma fences
Unfortunately I am not that familiar with the sound subsystem to make
a proper patch for this.
>
> Regards
> Oliver
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Chromeos Kdump" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromeos-kdump+unsubscr...@google.com.
> To view this discussion on the web, visit
> https://groups.google.com/a/google.com/d/msgid/chromeos-kdump/d3730d1d-6f92-700a-06c4-0e0a35e270b0%40suse.com.
--
Ricardo Ribalda
Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
Hi Oliver
Thanks for your review
On Thu, 1 Dec 2022 at 13:29, Oliver Neukum wrote:
>
> On 01.12.22 12:08, Ricardo Ribalda wrote:
> > If we are shutting down due to kexec and the userspace is frozen, the
> > system will stall forever waiting for userspace to complete.
> >
> > Do not wait for the clients to complete in that case.
>
> Hi,
>
> I am afraid I have to state that this approach is bad in every case,
> not just this corner case. It basically means that user space can stall
> the kernel for an arbitrary amount of time. And we cannot have that.
>
> Regards
> Oliver
This patchset does not modify this behaviour. It simply fixes the
stall for kexec().
The patch that introduced the stall:
83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
was sent as a generalised version of:
https://github.com/thesofproject/linux/pull/3388
AFAIK, we would need a similar patch for every single board which
I am not sure it is doable in a reasonable timeframe.
On the meantime this seems like a decent compromises. Yes, a
miss-behaving userspace can still stall during suspend, but that was
not introduced in this patch.
Regards!
>
--
Ricardo Ribalda
[PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
If we are shutting down due to kexec and the userspace is frozen, the
system will stall forever waiting for userspace to complete.
Do not wait for the clients to complete in that case.
This fixes:
[ 84.943749] Freezing user space processes ... (elapsed 0.111 seconds) done.
[ 246.784446] INFO: task kexec-lite:5123 blocked for more than 122 seconds.
[ 246.819035] Call Trace:
[ 246.821782]
[ 246.824186] __schedule+0x5f9/0x1263
[ 246.828231] schedule+0x87/0xc5
[ 246.831779] snd_card_disconnect_sync+0xb5/0x127
...
[ 246.889249] snd_sof_device_shutdown+0xb4/0x150
[ 246.899317] pci_device_shutdown+0x37/0x61
[ 246.903990] device_shutdown+0x14c/0x1d6
[ 246.908391] kernel_kexec+0x45/0xb9
And:
[ 246.893222] INFO: task kexec-lite:4891 blocked for more than 122 seconds.
[ 246.927709] Call Trace:
[ 246.930461]
[ 246.932819] __schedule+0x5f9/0x1263
[ 246.936855] ? fsnotify_grab_connector+0x5c/0x70
[ 246.942045] schedule+0x87/0xc5
[ 246.945567] schedule_timeout+0x49/0xf3
[ 246.949877] wait_for_completion+0x86/0xe8
[ 246.954463] snd_card_free+0x68/0x89
...
[ 247.001080] platform_device_unregister+0x12/0x35
Cc: sta...@vger.kernel.org
Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
Signed-off-by: Ricardo Ribalda
---
sound/soc/sof/core.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c
index 3e6141d03770..9587b6a85103 100644
--- a/sound/soc/sof/core.c
+++ b/sound/soc/sof/core.c
@@ -9,6 +9,8 @@
//
#include
+#include
+#include
#include
#include
#include
@@ -484,9 +486,10 @@ int snd_sof_device_shutdown(struct device *dev)
* make sure clients and machine driver(s) are unregistered to force
* all userspace devices to be closed prior to the DSP shutdown sequence
*/
- sof_unregister_clients(sdev);
-
- snd_sof_machine_unregister(sdev, pdata);
+ if (!(kexec_in_progress() && pm_freezing())) {
+ sof_unregister_clients(sdev);
+ snd_sof_machine_unregister(sdev, pdata);
+ }
if (sdev->fw_state == SOF_FW_BOOT_COMPLETE)
return snd_sof_shutdown(sdev);
--
2.39.0.rc0.267.gcb52ba06e7-goog-b4-0.11.0-dev-696ae
[PATCH v8 2/3] freezer: refactor pm_freezing into a function.
Add a way to let the drivers know if the processes are frozen.
This is needed by drivers that are waiting for processes to end on their
shutdown path.
Convert pm_freezing into a function and export it, so it can be used by
drivers that are either built-in or modules.
Cc: sta...@vger.kernel.org
Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
Signed-off-by: Ricardo Ribalda
sdad
---
include/linux/freezer.h | 3 ++-
kernel/freezer.c| 3 +--
kernel/power/process.c | 24
3 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/include/linux/freezer.h b/include/linux/freezer.h
index b303472255be..3413c869d68b 100644
--- a/include/linux/freezer.h
+++ b/include/linux/freezer.h
@@ -13,7 +13,7 @@
#ifdef CONFIG_FREEZER
DECLARE_STATIC_KEY_FALSE(freezer_active);
-extern bool pm_freezing; /* PM freezing in effect */
+bool pm_freezing(void);
extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
/*
@@ -80,6 +80,7 @@ static inline int freeze_processes(void) { return -ENOSYS; }
static inline int freeze_kernel_threads(void) { return -ENOSYS; }
static inline void thaw_processes(void) {}
static inline void thaw_kernel_threads(void) {}
+static inline bool pm_freezing(void) { return false; }
static inline bool try_to_freeze(void) { return false; }
diff --git a/kernel/freezer.c b/kernel/freezer.c
index 4fad0e6fca64..2d3530ebdb7e 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -20,7 +20,6 @@ EXPORT_SYMBOL(freezer_active);
* indicate whether PM freezing is in effect, protected by
* system_transition_mutex
*/
-bool pm_freezing;
bool pm_nosig_freezing;
/* protects freezing and frozen transitions */
@@ -46,7 +45,7 @@ bool freezing_slow_path(struct task_struct *p)
if (pm_nosig_freezing || cgroup_freezing(p))
return true;
- if (pm_freezing && !(p->flags & PF_KTHREAD))
+ if (pm_freezing() && !(p->flags & PF_KTHREAD))
return true;
return false;
diff --git a/kernel/power/process.c b/kernel/power/process.c
index ddd9988327fe..8a4d0e2c8c20 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -108,6 +108,22 @@ static int try_to_freeze_tasks(bool user_only)
return todo ? -EBUSY : 0;
}
+/*
+ * Indicate whether PM freezing is in effect, protected by
+ * system_transition_mutex.
+ */
+static bool pm_freezing_internal;
+
+/**
+ * pm_freezing - indicate whether PM freezing is in effect.
+ *
+ */
+bool pm_freezing(void)
+{
+ return pm_freezing_internal;
+}
+EXPORT_SYMBOL(pm_freezing);
+
/**
* freeze_processes - Signal user space processes to enter the refrigerator.
* The current thread will not be frozen. The same process that calls
@@ -126,12 +142,12 @@ int freeze_processes(void)
/* Make sure this task doesn't get frozen */
current->flags |= PF_SUSPEND_TASK;
- if (!pm_freezing)
+ if (!pm_freezing())
static_branch_inc(_active);
pm_wakeup_clear(0);
pr_info("Freezing user space processes ... ");
- pm_freezing = true;
+ pm_freezing_internal = true;
error = try_to_freeze_tasks(true);
if (!error) {
__usermodehelper_set_disable_depth(UMH_DISABLED);
@@ -187,9 +203,9 @@ void thaw_processes(void)
struct task_struct *curr = current;
trace_suspend_resume(TPS("thaw_processes"), 0, true);
- if (pm_freezing)
+ if (pm_freezing())
static_branch_dec(_active);
- pm_freezing = false;
+ pm_freezing_internal = false;
pm_nosig_freezing = false;
oom_killer_enable();
--
2.39.0.rc0.267.gcb52ba06e7-goog-b4-0.11.0-dev-696ae
[PATCH v8 1/3] kexec: Refactor kexec_in_progress into a function
Drivers running .shutdown() might want to behave differently during
kexec.
Convert kexec_in_progress into a function and export it, so it can be
used by drivers that are either built-in or modules.
Cc: sta...@vger.kernel.org
Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
Signed-off-by: Ricardo Ribalda
---
arch/powerpc/platforms/pseries/vio.c | 2 +-
arch/x86/kernel/cpu/mshyperv.c | 6 +++---
arch/x86/xen/enlighten_hvm.c | 2 +-
drivers/firmware/efi/efi.c | 2 +-
drivers/pci/pci-driver.c | 2 +-
include/linux/kexec.h| 5 ++---
kernel/kexec_core.c | 12 ++--
7 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/vio.c
b/arch/powerpc/platforms/pseries/vio.c
index 00ecac2c205b..923f9a36b992 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -1289,7 +1289,7 @@ static void vio_bus_shutdown(struct device *dev)
viodrv = to_vio_driver(dev->driver);
if (viodrv->shutdown)
viodrv->shutdown(viodev);
- else if (kexec_in_progress)
+ else if (kexec_in_progress())
vio_bus_remove(dev);
}
}
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 831613959a92..f91f35206489 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -122,21 +122,21 @@ void hv_remove_crash_handler(void)
#ifdef CONFIG_KEXEC_CORE
static void hv_machine_shutdown(void)
{
- if (kexec_in_progress && hv_kexec_handler)
+ if (kexec_in_progress() && hv_kexec_handler)
hv_kexec_handler();
/*
* Call hv_cpu_die() on all the CPUs, otherwise later the hypervisor
* corrupts the old VP Assist Pages and can crash the kexec kernel.
*/
- if (kexec_in_progress && hyperv_init_cpuhp > 0)
+ if (kexec_in_progress() && hyperv_init_cpuhp > 0)
cpuhp_remove_state(hyperv_init_cpuhp);
/* The function calls stop_other_cpus(). */
native_machine_shutdown();
/* Disable the hypercall page when there is only 1 active CPU. */
- if (kexec_in_progress)
+ if (kexec_in_progress())
hyperv_cleanup();
}
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index c1cd28e915a3..769163833ffc 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -145,7 +145,7 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_xen_hvm_callback)
static void xen_hvm_shutdown(void)
{
native_machine_shutdown();
- if (kexec_in_progress)
+ if (kexec_in_progress())
xen_reboot(SHUTDOWN_soft_reset);
}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index a46df5d1d094..608bc2146802 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -1040,7 +1040,7 @@ static int update_efi_random_seed(struct notifier_block
*nb,
struct linux_efi_random_seed *seed;
u32 size = 0;
- if (!kexec_in_progress)
+ if (!kexec_in_progress())
return NOTIFY_DONE;
seed = memremap(efi_rng_seed, sizeof(*seed), MEMREMAP_WB);
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 107d77f3c846..23eeb7538b03 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -519,7 +519,7 @@ static void pci_device_shutdown(struct device *dev)
* If it is not a kexec reboot, firmware will hit the PCI
* devices with big hammer and stop their DMA any way.
*/
- if (kexec_in_progress && (pci_dev->current_state <= PCI_D3hot))
+ if (kexec_in_progress() && pci_dev->current_state <= PCI_D3hot)
pci_clear_master(pci_dev);
}
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 41a686996aaa..2ec0aec1a0de 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -423,8 +423,7 @@ extern int kexec_load_disabled;
#define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
KEXEC_FILE_NO_INITRAMFS)
-/* flag to track if kexec reboot is in progress */
-extern bool kexec_in_progress;
+bool kexec_in_progress(void);
int crash_shrink_memory(unsigned long new_size);
ssize_t crash_get_memory_size(void);
@@ -507,7 +506,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
static inline void crash_kexec(struct pt_regs *regs) { }
static inline int kexec_should_crash(struct task_struct *p) { return 0; }
static inline int kexec_crash_loaded(void) { return 0; }
-#define kexec_in_progress false
+static inline bool kexec_in_progress(void) { return false; }
#endif /* CONFIG_KEXEC_CORE */
#ifdef CONFIG_KEXEC_SIG
diff --git a/kernel/ke
[PATCH v8 0/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
Since: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
we wait for all the workloads to be completed during shutdown. This was done to
avoid a stall once the device is started again.
Unfortunately this has the side effect of stalling kexec(), if the userspace
is frozen. Let's handle that case.
To: Joel Fernandes
To: Pierre-Louis Bossart
To: Liam Girdwood
To: Peter Ujfalusi
To: Bard Liao
To: Ranjani Sridharan
To: Kai Vehmanen
To: Daniel Baluta
To: Mark Brown
To: Jaroslav Kysela
To: Takashi Iwai
To: Eric Biederman
To: Chromeos Kdump
To: Steven Rostedt
To: Michael Ellerman
To: Nicholas Piggin
To: Christophe Leroy
To: "K. Y. Srinivasan"
To: Haiyang Zhang
To: Wei Liu
To: Dexuan Cui
To: Thomas Gleixner
To: Ingo Molnar
To: Borislav Petkov
To: Dave Hansen
To: x...@kernel.org
To: "H. Peter Anvin"
To: Juergen Gross
To: Boris Ostrovsky
To: Ard Biesheuvel
To: Bjorn Helgaas
To: "Rafael J. Wysocki"
To: Pavel Machek
To: Len Brown
Cc: sta...@vger.kernel.org
Cc: sound-open-firmw...@alsa-project.org
Cc: alsa-de...@alsa-project.org
Cc: linux-ker...@vger.kernel.org
Cc: ke...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-hyp...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Ricardo Ribalda
---
Changes in v8:
- Wrap pm_freezing and kexec_inprogress in functions.
- Do not run snd_sof_machine_unregister(sdev, pdata) during kexec (Thanks Kai).
- Link to v7:
https://lore.kernel.org/r/20221127-snd-freeze-v7-0-127c582f1...@chromium.org
Changes in v7:
- Fix commit message (Thanks Pierre-Louis).
- Link to v6:
https://lore.kernel.org/r/20221127-snd-freeze-v6-0-3e90553f6...@chromium.org
Changes in v6:
- Check if we are in kexec with the userspace frozen.
- Link to v5:
https://lore.kernel.org/r/20221127-snd-freeze-v5-0-4ededeb08...@chromium.org
Changes in v5:
- Edit subject prefix.
- Link to v4:
https://lore.kernel.org/r/20221127-snd-freeze-v4-0-51ca64b7f...@chromium.org
Changes in v4:
- Do not call snd_sof_machine_unregister from shutdown.
- Link to v3:
https://lore.kernel.org/r/20221127-snd-freeze-v3-0-a2eda731c...@chromium.org
Changes in v3:
- Wrap pm_freezing in a function.
- Link to v2:
https://lore.kernel.org/r/20221127-snd-freeze-v2-0-d8a425ea9...@chromium.org
Changes in v2:
- Only use pm_freezing if CONFIG_FREEZER .
- Link to v1:
https://lore.kernel.org/r/20221127-snd-freeze-v1-0-57461a366...@chromium.org
---
Ricardo Ribalda (3):
kexec: Refactor kexec_in_progress into a function
freezer: refactor pm_freezing into a function.
ASoC: SOF: Fix deadlock when shutdown a frozen userspace
arch/powerpc/platforms/pseries/vio.c | 2 +-
arch/x86/kernel/cpu/mshyperv.c | 6 +++---
arch/x86/xen/enlighten_hvm.c | 2 +-
drivers/firmware/efi/efi.c | 2 +-
drivers/pci/pci-driver.c | 2 +-
include/linux/freezer.h | 3 ++-
include/linux/kexec.h| 5 ++---
kernel/freezer.c | 3 +--
kernel/kexec_core.c | 12 ++--
kernel/power/process.c | 24
sound/soc/sof/core.c | 9 ++---
11 files changed, 48 insertions(+), 22 deletions(-)
---
base-commit: 4312098baf37ee17a8350725e6e0d0e8590252d4
change-id: 20221127-snd-freeze-1ee143228326
Best regards,
--
Ricardo Ribalda
[PATCH] ll_temac: Add support for ethtool
This patch enables the ethtool interface. The implementation is done
using the libphy helper functions.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
drivers/net/ll_temac_main.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 728fe41..91a9804 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -957,6 +957,32 @@ static const struct attribute_group temac_attr_group = {
.attrs = temac_device_attrs,
};
+/* ethtool support */
+static int temac_get_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_ethtool_gset(lp-phy_dev, cmd);
+}
+
+static int temac_set_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_ethtool_sset(lp-phy_dev, cmd);
+}
+
+static int temac_nway_reset(struct net_device *ndev)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_start_aneg(lp-phy_dev);
+}
+
+static const struct ethtool_ops temac_ethtool_ops = {
+ .get_settings = temac_get_settings,
+ .set_settings = temac_set_settings,
+ .nway_reset = temac_nway_reset,
+ .get_link = ethtool_op_get_link,
+};
+
static int __devinit temac_of_probe(struct platform_device *op)
{
struct device_node *np;
@@ -978,6 +1004,7 @@ static int __devinit temac_of_probe(struct platform_device
*op)
ndev-flags = ~IFF_MULTICAST; /* clear multicast */
ndev-features = NETIF_F_SG | NETIF_F_FRAGLIST;
ndev-netdev_ops = temac_netdev_ops;
+ ndev-ethtool_ops= temac_ethtool_ops;
#if 0
ndev-features |= NETIF_F_IP_CSUM; /* Can checksum TCP/UDP over IPv4. */
ndev-features |= NETIF_F_HW_CSUM; /* Can checksum all the packets. */
--
1.7.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SD card over (xilinx_)SPI, timeout error while CID
] Xilinx SPI: cs on [ 55.209369] Spi Transfer at 0x8A00 [ 55.221281] Sending 1 bytes [ 55.222873] ff [ 55.241289] Received 1 bytes [ 55.242978] ff [ 55.261376] Xilinx SPI: change mode 3, 8 bits/w, 0 cs_high [ 55.274774] Xilins SPI: cs off [ 55.286183] mmc0: req done (CMD0): -110: [ 55.303059] mmc0: starting CMD8 arg 01aa flags 02f5 [ 55.317605] mmc_spi spi1.0: mmc_spi: CMD8, resp R3/R4/R7 [ 55.332234] Xilinx SPI: cs on [ 55.344288] Spi Transfer at 0x8A00 [ 55.357357] Sending 21 bytes [ 55.359048] ff 48 00 00 01 aa 87 ff ff ff ff ff ff ff ff ff [ 55.373268] ff ff ff ff ff [ 55.395064] Received 21 bytes [ 55.397272] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 55.411374] ff ff ff ff ff [ 55.433854] Xilinx SPI: cs on [ 55.446394] Spi Transfer at 0x8A00 [ 55.459800] Sending 1 bytes [ 55.461818] ff [ 55.483642] Received 1 bytes [ 55.485751] ff [ 55.507455] Xilinx SPI: cs on [ 55.520004] Spi Transfer at 0x8A00 [ 55.533515] Sending 1 bytes [ 55.535105] ff [ 55.556813] Received 1 bytes [ 55.558502] ff [ 55.580275] Xilinx SPI: cs on [ 55.592791] Spi Transfer at 0x8A00 [ 55.606171] Sending 1 bytes [ 55.607768] ff [ 55.629567] Received 1 bytes [ 55.631260] ff [ 55.653122] Xilinx SPI: cs on [ 55.665601] Spi Transfer at 0x8A00 [ 55.679005] Sending 1 bytes [ 55.681015] ff [ 55.702801] Received 1 bytes [ 55.704492] ff [ 55.726140] Xilinx SPI: cs on [ 55.738660] Spi Transfer at 0x8A00 [ 55.752158] Sending 1 bytes [ 55.754162] ff [ 55.775802] Received 1 bytes [ 55.777912] ff [ 55.799564] Xilinx SPI: cs on [ 55.811801] Spi Transfer at 0x8A00 [ 55.824923] Sending 1 bytes [ 55.826514] ff [ 55.846619] Received 1 bytes [ 55.848304] ff [ 55.867579] Xilinx SPI: cs on [ 55.878762] Spi Transfer at 0x8A00 [ 55.890810] Sending 1 bytes [ 55.892404] ff [ 55.911203] Received 1 bytes [ 55.913311] ff [ 55.931740] Xilinx SPI: cs on [ 55.942575] Spi Transfer at 0x8A00 [ 55.954480] Sending 1 bytes [ 55.956073] ff [ 55.974448] Received 1 bytes [ 55.976134] ff [ 55.994486] Xilinx SPI: cs on [ 56.005406] Spi Transfer at 0x8A00 [ 56.017305] Sending 1 bytes [ 56.018894] ff [ 56.037248] Received 1 bytes [ 56.038924] ff [ 56.057282] Xilinx SPI: cs on -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SD card over (xilinx_)SPI, timeout error while CID
Hello
Thanks for your reply
Is the I/O logged from within the Xilinx-SPI-Driver or from within the
mmc-spi-layer?
It is take from inside the spi driver.
The response to CMD10 seems quite strange to me. The R1 answer to that
command says that everything is OK, so what is done next is that the 0xfe
token will be expected by the mmc-spi-layer. Obviously that one is not
received within the proper time (assuming your data-logging was done from
within xilinx-spi-driver). Also be aware of printk() taking milliseconds for
printing to console, within time critical routines that might not be the
best choice for debugging.
I will retry tomorrow removing all the spi debug and report what happens.
What frequency does Your SPI-Bus use?
33Mhz arghh. just checked is over the standard... Tomorrow I will
test with a slower clk
Also double check to completely disable the whole
if (spi-master-dev.parent-dma_mask) {
...
}
Tomorow morning i will double check it, but it was something we
removed from the very begining (we dont have dma for the spi and we
suppose it was an error) In my last log check:
[ 48.990098] mmc_spi spi1.0: SD/MMC host mmc0, no DMA, no WP, no
poweroff, cd polling
Anyway the problem is definitely here:
[ 52.094569] mmc0: starting CMD10 arg flags 00b5
[ 52.113755] mmc0: blksz 16 blocks 1 flags 0200 tsac 0 ms nsac 64
[ 52.134240] mmc_spi spi1.0: mmc_spi: CMD10, resp R1
[ 52.152922] Xilinx SPI: cs on
[ 52.169228] Spi Transfer at 0x8A00
[ 52.186386] Sending 9 bytes
[ 52.187978] ff 4a 00 00 00 00 1b ff ff
[ 52.218225] Received 9 bytes
[ 52.219911] ff ff ff ff ff ff ff ff 00
[ 52.249970] mmc_spi spi1.0: mmc_spi: read block, 16 bytes
[ 52.269009] Xilinx SPI: cs on
[ 52.285210] Spi Transfer at 0x8A00
[ 52.302276] Sending 1 bytes
[ 52.303867] ff
[ 52.332598] Received 1 bytes
[ 52.334287] ff
[ 52.362345] Xilinx SPI: cs on
[ 52.377675] Spi Transfer at 0x8A00
[ 52.393815] Sending 1 bytes
[ 52.395408] ff
[ 52.422215] Received 1 bytes
[ 52.423901] ff
It tries to read the cid and the only thing it get from the sd back
are 0xff. I have made it loop without timeout and I keep receiving
0xff
Also after the cid read the sd card dont reply to any command
weird. lets see tomorrow with a slower clk.
Thanks for your commends
Best regards
--
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SD card over (xilinx_)SPI, timeout error while CID
Hello Wolfgang This is with a 4xx core, right? Is this the same SPI controller design like in AMCC's 40x and 44x cores, i. e. with a FIFO of depth 1? It is a ppc440 but it is does not have ans spi controller as in the amcc. The spi controller is a xilinx core allocated at the plb bus, including a deeper fifo. The actual version does not have a sustained speed of 33Mhz but a can have a peak speed of 33 MHz Thanks for your comment -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [MTD] ofpart: Partitions at same address cannot have thesame name v3
Hello Ah! After writing my original reply, I read the documentation, and this had me confused. 4b08e14 looks wrong to me. It also didn't update the documentation. So, what shall we do, revert 4b08e14 or apply this patch changing the name to linux,mtd,partition or similar ? Regards -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [MTD] ofpart: Partitions at same address cannot have thesame name v3
Hello Segher Thanks for your comments. Your special partition isn't really a partition then, is it. Because of that, device nodes to represent your partitions doesn't work very well. I think that they work pretty well. Unfortunately, since 4b08e149c0e02e97ec49c2a31d14a0d3a02f8074 all the partiton must be named partition You really want to use something else, a partition table on the flash itself for example. Or maybe the (platform? MTD?) code should create a Linux device for the full device. This wont be very flexible. With the device tree aproach we can define partitions not only for the full flash, but also for two partitions merged, a partition inside a partition Because two nodes of a device tree cannot have the same name, This isn't true. Are you sure? This is what I get if I try to compile a device tree with two partitions with the same name starting at the same address. $ arch/powerpc/boot/dtc -O dtb -b 0 -p 1024 arch/powerpc/boot/dts/q5-avnet.dts -o /tmp/kk DTC: dts-dtb on file arch/powerpc/boot/dts/q5-avnet.dts ERROR (duplicate_node_names): Duplicate node name /p...@0/fl...@ff00/partit...@ff00 ERROR: Input tree has errors, aborting (use -f to force output) but all the partitions must be named partition, Bad binding, no cookie for you! Sorry, I dont understand want you want to say here. You cannot claim a name as generic as partition for this. Pick something else if you really must do things this way. You choose :) Best regards -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [MTD] ofpart: Partitions at same address cannot have the same name v3
Sometimes, an special partition is included in the device tree including all the
partitions. Like in:
partit...@ff00 {
reg = 0x00 0x80 ;
label = Root File System;
};
partit...@ff80 {
reg = 0x80 0x1a ;
label = Bitstream;
};
...
f...@ff00 {
compatible = partition;
reg = 0x00 0x100 ;
label = Full FLASH;
};
Because two nodes of a device tree cannot have the same name, but all the
partitions must be named partition, this special partition is invalid.
This patch makes ofpart.c accept spetial partitions compatible with
partition but not named partition.
These spetial partitions are very useful for flashing the full firmware
of a device from linux
---
This v3 includes feedback from Scott Wood, Peter Korsgaard Benjamin Kril
v3: Use the compatible propierty
v2: buggy implementation, strlen-1 instead of strlen
v1: Just check the firt part of the name
drivers/mtd/ofpart.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 3e164f0..59c1e4a 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -48,7 +48,9 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
/* check if this is a partition node */
partname = of_get_property(pp, name, len);
- if (strcmp(partname, partition) != 0) {
+ if ((strcmp(partname, partition) != 0)
+ (of_device_is_compatible(pp, partition) != 1))
+ {
nr_parts--;
continue;
}
--
1.6.2.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[MTD] ofpart: Partitions at same address cannot have the same name
Sometimes, an special partition is included in the device tree including all the
partitions. Like in:
partit...@ff00 {
reg = 0x00 0x80 ;
label = Root File System;
};
partit...@ff80 {
reg = 0x80 0x1a ;
label = Bitstream;
};
...
partition...@ff00 {
reg = 0x00 0x100 ;
label = Full FLASH;
};
Because two nodes of a device tree cannot have the same name, but all the
partitions must be named partition, this special partition is invalid.
This patch makes ofpart.c only check for the firt part of the name, and
ignore the rest, allowing this special partition.
---
The extra partition is quite useful while formating the full firmware from linux
drivers/mtd/ofpart.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 3e164f0..0af3b07 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -48,7 +48,8 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
/* check if this is a partition node */
partname = of_get_property(pp, name, len);
- if (strcmp(partname, partition) != 0) {
+ if (strncmp(partname, partition, strlen(partition)-1)
+ != 0) {
nr_parts--;
continue;
}
--
1.6.2.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ofpart: Partitions at same address cannot have the same name
Sometimes, an special partition is included in the device tree including all the
partitions. Like in:
partit...@ff00 {
reg = 0x00 0x80 ;
label = Root File System;
};
partit...@ff80 {
reg = 0x80 0x1a ;
label = Bitstream;
};
...
partition...@ff00 {
reg = 0x00 0x100 ;
label = Full FLASH;
};
Because two nodes of a device tree cannot have the same name, but all the
partitions must be named partition, this special partition is invalid.
This patch makes ofpart.c only check for the firt part of the name, and
ignore the rest, allowing this special partition.
---
The extra partition is quite useful while formating the full firmware from linux
v2, removes the -1 Peter Korsgaard
drivers/mtd/ofpart.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 3e164f0..0af3b07 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -48,7 +48,7 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
/* check if this is a partition node */
partname = of_get_property(pp, name, len);
- if (strcmp(partname, partition) != 0) {
+ if (strncmp(partname, partition, strlen(partition) != 0) {
nr_parts--;
continue;
}
--
1.6.2.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MTD] ofpart: Partitions at same address cannot have the same name
Hello
You are right, remove the -1. I thought that strlen gives the #of
chars + 1 ('\0').
Thanks
On Wed, Apr 22, 2009 at 11:24, Peter Korsgaard jac...@sunsite.dk wrote:
Ricardo == Ricardo Ribalda Delgado ricardo.riba...@uam.es writes:
Hi,
Ricardo Sometimes, an special partition is included in the device
Ricardo tree including all the partitions. Like in:
Ricardo drivers/mtd/ofpart.c | 3 ++-
Ricardo 1 files changed, 2 insertions(+), 1 deletions(-)
Ricardo diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
Ricardo index 3e164f0..0af3b07 100644
Ricardo --- a/drivers/mtd/ofpart.c
Ricardo +++ b/drivers/mtd/ofpart.c
Ricardo @@ -48,7 +48,8 @@ int __devinit of_mtd_parse_partitions(struct
device *dev,
Ricardo /* check if this is a partition node */
Ricardo partname = of_get_property(pp, name, len);
Ricardo - if (strcmp(partname, partition) != 0) {
Ricardo + if (strncmp(partname, partition,
strlen(partition)-1)
Why strlen() - 1 ?
--
Bye, Peter Korsgaard
--
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ofpart: Partitions at same address cannot have the same name
Hi Scott
Perhaps compatible should be used instead?
What do you mean?
if (strcmp(partname, partition) || strcmp(partname, compatible) )
I can't see the advantages.
Hi Recardo,
I would suggest to do:
if (strcmp(partname, partition) = 0) {
Check whether it sorts alphabetically before partition? Why?
-Scott
--
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ofpart: Partitions at same address cannot have the same name
Hello Benjamin
Hi Recardo,
I would suggest to do:
if (strcmp(partname, partition) = 0) {
Anything alfabetically higher than partition (like z will pass
the test :S)
Regards
cheers
ben
--
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Xilinx EDK 10.1 and XUPV2P: A little report
Hello list I have tried to port Linux 2.6 (xilinx git) to a XUPV2P board running a system implemented with EDK10.1 (Linux Version). I have fail, and I think I now why, this is a little report written for saving you some time (and maybe solving my problem if I am doing something wrong) The board is not supported by EDK 10.1, but I have found a Board Support File form https://wiki.ittc.ku.edu that seems to work. To start I have created a design that consists on a ppc, the mpmc, an uartlite, an interrupt manager and some bram. The basic programs worked ok on it. I have downloaded the kernel form xilinx git and adapted the xparameters file to fit my design. I have created a toolchain using OpenEmbedded and compiled the kernel with it, then I have downloaded the binary to the board and everything works fine until Now booting the kernel Debugging the kernel I have found that the system crashes (Exception 0x700) setting the mmu inside start_here (head_4xx.S)... Because it was a crash in the very beginning of my kernel live I developed some simple apps to tests all my peripherals and they worked ok in real mode: All of them worked OK BUT I have created a small piece of code that tests the peripherals in virtual mode and when the program is linked to the ram the system crashes!! Strangely, it works ok when it runs from bram. The same code works perfectly on a design created with EDK 8.1 and the kernel also works fine. I attach the source code of my test app and the OpenEmbedded parameters I have used. Best Regards - main: .globl main my_code: bl uart tlbia isync lis r3,[EMAIL PROTECTED] ori r3,r3,[EMAIL PROTECTED] mr r4,r3 iccci r0,r3 /*PID*/ li r0,0 mtpid r0 sync mem_map: /*RAM*/ lis r3,[EMAIL PROTECTED] ori r3,r3,[EMAIL PROTECTED] mr r4,r3 rlwinm r4,r4,0,0,21 ori r4,r4,768 rlwinm r3,r3,0,0,21 ori r3,r3,960 /*16M*/ li r0,0 tlbwelo r4,r0 tlbwehi r3,r0 /*BRAM*/ lis r3,[EMAIL PROTECTED] ori r3,r3,[EMAIL PROTECTED] mr r4,r3 rlwinm r4,r4,0,0,21 ori r4,r4,768 rlwinm r3,r3,0,0,21 ori r3,r3,448 /* 64K */ li r0,1 tlbwelo r4,r0 tlbwehi r3,r0 /*UARTLITE*/ lis r3,[EMAIL PROTECTED] ori r3,r3,[EMAIL PROTECTED] mr r4,r3 rlwinm r4,r4,0,0,21 ori r4,r4,263 rlwinm r3,r3,0,0,21 ori r3,r3,448 /*64K*/ li r0,2 tlbwelo r4,r0 tlbwehi r3,r0 sync on_mmu: lis r0,0 ori r0,r0,4146 mtsrr1 r0 lis r0,[EMAIL PROTECTED] ori r0,r0,[EMAIL PROTECTED] mtsrr0 r0 rfi b . uart: lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] li r14,0x0 stb r14,0x0(r11) lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] busy: lwz r10,0(r11) andi. r12,r10,8 bne+ busy lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] li r14,0x32 stb r14,0x0(r11) br rw_ram: lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] lwz r10,0(r11) lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] li r10,0xcc stb r10,0x0(r11) br rw_rom: lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] lwz r10,0(r11) lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] li r10,0xcc stb r10,0x0(r11) br bucle: bl rw_ram bl uart bl rw_rom bl bucle --- OpenEmbedded Parameters: PREFERRED_VERSION_gcc = 4.2.1 PREFERRED_VERSION_gcc-cross = 4.2.1 PREFERRED_VERSION_gcc-cross-initial = 4.2.1 PREFERRED_VERSION_binutils = 2.18 PREFERRED_VERSION_binutils-cross = 2.18 PREFERRED_VERSION_glibc = 2.5 PREFERRED_VERSION_glibc-intermediate = 2.5 PREFERRED_VERSION_linux-libc-headers = 2.6.25 -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
