Message ID | 20211122163459.41079-1-max.krummenacher@toradex.com |
---|---|
Headers | show |
Series | perf: sort-pmuevents: some fixes | expand |
On Mon, Nov 22, 2021 at 11:35 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > I am trying out a kernel recipe using linux master, 5.16-rc2. I found > that perf fails to build in do_compile with such a setup. > Root cause is that the kernel did add 'static' and 'const' to the > arrays of structs which sort-pmuevents does sort. > This is addressed in the second commit. > > While at it I noticed that there are some struct arrays which neither > have a name or cpuid element with 1 array element. That 1 element was > dropped. I did not verify if that causes any issues at runtime, however > that behaviour was improved with the first commit. > > Note that the kernel itself doesn't build either as after 5.15 it now > does try to run the dt_binding_check for which the kernel recipe does > not provide whatever stuff is needed. > I just did a revert patch for commit 53182e81f47d ("kbuild: Enable > DT schema checks for %.dtb targets") to get over that. I have a fixefor that particular problem (the bindings), so you can safely continue to ignore it .. but I hadn't gotten around to fixing perf yet. The changes look fine to me for perf. The sorting of events is hopefully something we can drop soon, as there have been other reproducibility changes to perf upstream, that will make it unnecessary. Bruce > > Max Krummenacher (2): > perf: sort-pmuevents: don't drop elements > perf: sort-pmuevents: allow for additional type qualifiers and storage > class > > .../perf/perf/sort-pmuevents.py | 28 +++++++++++-------- > 1 file changed, 16 insertions(+), 12 deletions(-) > > -- > 2.20.1 >
Hello! On Mon, 22 Nov 2021 at 10:51, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > On Mon, Nov 22, 2021 at 11:35 AM Max Krummenacher <max.oss.09@gmail.com> wrote: [...] > > Note that the kernel itself doesn't build either as after 5.15 it now > > does try to run the dt_binding_check for which the kernel recipe does > > not provide whatever stuff is needed. > > I just did a revert patch for commit 53182e81f47d ("kbuild: Enable > > DT schema checks for %.dtb targets") to get over that. > > I have a fixefor that particular problem (the bindings), so you can > safely continue to ignore it .. but I hadn't gotten around to fixing > perf yet. [...] I don't mean to hijack the subject, but do you have some quick pointers on that? We're seeing the same on linux-next and linux-mainline since that patch landed in those trees, and have soft-reverted the commit for now. This (incomplete) recipe has not helped us get through that: https://github.com/mrchapp/meta-lkft/blob/d/add-dtschema/recipes-devtools/python/dtschema_2021.10.bb Thanks and greetings! Daniel Díaz daniel.diaz@linaro.org
On Mon, Nov 22, 2021 at 12:23 PM Daniel Díaz <daniel.diaz@linaro.org> wrote: > > Hello! > > On Mon, 22 Nov 2021 at 10:51, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > On Mon, Nov 22, 2021 at 11:35 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > [...] > > > Note that the kernel itself doesn't build either as after 5.15 it now > > > does try to run the dt_binding_check for which the kernel recipe does > > > not provide whatever stuff is needed. > > > I just did a revert patch for commit 53182e81f47d ("kbuild: Enable > > > DT schema checks for %.dtb targets") to get over that. > > > > I have a fixefor that particular problem (the bindings), so you can > > safely continue to ignore it .. but I hadn't gotten around to fixing > > perf yet. > [...] > > I don't mean to hijack the subject, but do you have some quick > pointers on that? We're seeing the same on linux-next and > linux-mainline since that patch landed in those trees, and have I'm trying to come up with a way to fix this without needing a kernel patch. Sounds like you are already aware of the pkgconfig issue, which is what I'm attempting to fix via environment manipulation versus a patch. We do need python dtschema as well, as a new native dependency of the bindings check, which unfortunately pulls in ruamel and jsonschema. Those are both in meta-python, so they need to migrate to core to support the new checking. There's also a problem with nproc being used, and it was giving me an error on one of my servers, I haven't looked into it more yet. I have a quick recipe here as well. And with those two pieces in place, I'm up and running again. The right thing for the short term, is that revert. There's quite a bit of sorting out to do, to get this in decent shape for core ... personally, I'd like to make the checking optional for those that don't want it .. but that goes against what Rob is trying to do in the kernel :D If those issues sound familiar, and there's interest, I can drop my WIP commits into a branch and share. Bruce > soft-reverted the commit for now. This (incomplete) recipe has not > helped us get through that: > > https://github.com/mrchapp/meta-lkft/blob/d/add-dtschema/recipes-devtools/python/dtschema_2021.10.bb > > Thanks and greetings! > > Daniel Díaz > daniel.diaz@linaro.org -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
On Mon, Nov 22, 2021 at 11:35 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > I am trying out a kernel recipe using linux master, 5.16-rc2. I found > that perf fails to build in do_compile with such a setup. > Root cause is that the kernel did add 'static' and 'const' to the > arrays of structs which sort-pmuevents does sort. > This is addressed in the second commit. > > While at it I noticed that there are some struct arrays which neither > have a name or cpuid element with 1 array element. That 1 element was > dropped. I did not verify if that causes any issues at runtime, however > that behaviour was improved with the first commit. What MACHINE were you testing against ? When I build perf against my -rc2 dev kernel, I still run into the build issues with these commits in place. I just want to make sure that I'm not seeing something different .. so I can do some runs against a similar config as you are using. Bruce > > Note that the kernel itself doesn't build either as after 5.15 it now > does try to run the dt_binding_check for which the kernel recipe does > not provide whatever stuff is needed. > I just did a revert patch for commit 53182e81f47d ("kbuild: Enable > DT schema checks for %.dtb targets") to get over that. > > Max Krummenacher (2): > perf: sort-pmuevents: don't drop elements > perf: sort-pmuevents: allow for additional type qualifiers and storage > class > > .../perf/perf/sort-pmuevents.py | 28 +++++++++++-------- > 1 file changed, 16 insertions(+), 12 deletions(-) > > -- > 2.20.1 >
On Mon, Nov 22, 2021 at 8:39 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > On Mon, Nov 22, 2021 at 12:23 PM Daniel Díaz <daniel.diaz@linaro.org> wrote: > > > > Hello! > > > > On Mon, 22 Nov 2021 at 10:51, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > On Mon, Nov 22, 2021 at 11:35 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > [...] > > > > Note that the kernel itself doesn't build either as after 5.15 it now > > > > does try to run the dt_binding_check for which the kernel recipe does > > > > not provide whatever stuff is needed. > > > > I just did a revert patch for commit 53182e81f47d ("kbuild: Enable > > > > DT schema checks for %.dtb targets") to get over that. > > > > > > I have a fixefor that particular problem (the bindings), so you can > > > safely continue to ignore it .. but I hadn't gotten around to fixing > > > perf yet. > > [...] > > > > I don't mean to hijack the subject, but do you have some quick > > pointers on that? We're seeing the same on linux-next and > > linux-mainline since that patch landed in those trees, and have > > I'm trying to come up with a way to fix this without needing a kernel patch. > FYI: I have this sorted out now. The commits to get 5.16 building with device tree validation are here: https://github.com/zeddii/openembedded-core/tree/zedd/kernel (I would have pushed it to my poky-contrib zedd/kernel branch, but there's something broken on the machine tonight). You'll need to add the DEPENDS to your kernel recipe, like I did for linux-yocto-dev, but outside of that the pkg-config tweaking that I did avoided the need for kernel patches. The dtschema recipe + the imported meta-python recipes should "just work". I haven't done a second pass to make sure I found all the dependencies, but it is close .. and if you have meta-python in your layers, you won't have any issues. For now, the DEPENDS are recipe specific, since they are fairly heavy, and the mapping of PV -> ARCH -> conditional dependencies is still a WIP (it gets brittle/complex very quickly) .. but moving the DEPENDS into kernel.bbclass is something that I'm working on as well. I still need more cleanup, but I expect that I can submit the queue by the end of the week. .. and the proof: qemuarm64 login: root uroot@qemuarm64:~# uname -a Linux qemuarm64 5.16.0-rc2-yoctodev-standard #1 SMP PREEMPT Sun Nov 21 21:47:39 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux root@qemuarm64:~# Cheers, Bruce > Sounds like you are already aware of the pkgconfig issue, which is > what I'm attempting to fix via environment manipulation versus a > patch. > > We do need python dtschema as well, as a new native dependency of the > bindings check, which unfortunately pulls in ruamel and jsonschema. > Those are both in meta-python, so they need to migrate to core to > support the new checking. > > There's also a problem with nproc being used, and it was giving me an > error on one of my servers, I haven't looked into it more yet. > > I have a quick recipe here as well. And with those two pieces in > place, I'm up and running again. > > The right thing for the short term, is that revert. There's quite a > bit of sorting out to do, to get this in decent shape for core ... > personally, I'd like to make the checking optional for those that > don't want it .. but that goes against what Rob is trying to do in the > kernel :D > > If those issues sound familiar, and there's interest, I can drop my > WIP commits into a branch and share. > > Bruce > > > soft-reverted the commit for now. This (incomplete) recipe has not > > helped us get through that: > > > > https://github.com/mrchapp/meta-lkft/blob/d/add-dtschema/recipes-devtools/python/dtschema_2021.10.bb > > > > Thanks and greetings! > > > > Daniel Díaz > > daniel.diaz@linaro.org > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
Hi Bruce, On Tue, Nov 23, 2021 at 2:41 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > On Mon, Nov 22, 2021 at 11:35 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > > > I am trying out a kernel recipe using linux master, 5.16-rc2. I found > > that perf fails to build in do_compile with such a setup. > > Root cause is that the kernel did add 'static' and 'const' to the > > arrays of structs which sort-pmuevents does sort. > > This is addressed in the second commit. > > > > While at it I noticed that there are some struct arrays which neither > > have a name or cpuid element with 1 array element. That 1 element was > > dropped. I did not verify if that causes any issues at runtime, however > > that behaviour was improved with the first commit. > > What MACHINE were you testing against ? When I build perf against my > -rc2 dev kernel, I still run into the build issues with these commits > in place. > > I just want to make sure that I'm not seeing something different .. so > I can do some runs against a similar config as you are using. > I did the inital work against a Toradex machine, apalis-imx6. However I built before sending the patches with qemuarm64 qemuarm qemux86-64 with the following modification to use my 'master' kernel recipe: +PREFERRED_PROVIDER_virtual/kernel = "linux-toradex-mainline" +KBUILD_DEFCONFIG:arm = "tegra_defconfig" +KBUILD_DEFCONFIG:aarch64 = "defconfig" +KBUILD_DEFCONFIG:qemux86-64 = "x86_64_defconfig" I tried again. With the patches perf builds for all three machines, reverting the patches and it fails again. The x86 compiles forever, for the two ARM machines I get: ... Traceback (most recent call last): File "/build/krm/oe-core_master/build/tmp/work/qemuarm64-tdx-linux/perf/1.0-r9/perf-1.0/sort-pmuevents.py", line 83, in <module> print( preamble.group(1) ) AttributeError: 'NoneType' object has no attribute 'group' ... Max > > > > > Note that the kernel itself doesn't build either as after 5.15 it now > > does try to run the dt_binding_check for which the kernel recipe does > > not provide whatever stuff is needed. > > I just did a revert patch for commit 53182e81f47d ("kbuild: Enable > > DT schema checks for %.dtb targets") to get over that. > > > > Max Krummenacher (2): > > perf: sort-pmuevents: don't drop elements > > perf: sort-pmuevents: allow for additional type qualifiers and storage > > class > > > > .../perf/perf/sort-pmuevents.py | 28 +++++++++++-------- > > 1 file changed, 16 insertions(+), 12 deletions(-) > > > > -- > > 2.20.1 > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II
On Tue, Nov 23, 2021 at 8:48 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > Hi Bruce, > > On Tue, Nov 23, 2021 at 2:41 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > On Mon, Nov 22, 2021 at 11:35 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > > > > > I am trying out a kernel recipe using linux master, 5.16-rc2. I found > > > that perf fails to build in do_compile with such a setup. > > > Root cause is that the kernel did add 'static' and 'const' to the > > > arrays of structs which sort-pmuevents does sort. > > > This is addressed in the second commit. > > > > > > While at it I noticed that there are some struct arrays which neither > > > have a name or cpuid element with 1 array element. That 1 element was > > > dropped. I did not verify if that causes any issues at runtime, however > > > that behaviour was improved with the first commit. > > > > What MACHINE were you testing against ? When I build perf against my > > -rc2 dev kernel, I still run into the build issues with these commits > > in place. > > > > I just want to make sure that I'm not seeing something different .. so > > I can do some runs against a similar config as you are using. > > > > I did the inital work against a Toradex machine, apalis-imx6. > However I built before sending the patches with qemuarm64 qemuarm qemux86-64 > with the following modification to use my 'master' kernel recipe: > +PREFERRED_PROVIDER_virtual/kernel = "linux-toradex-mainline" > +KBUILD_DEFCONFIG:arm = "tegra_defconfig" > +KBUILD_DEFCONFIG:aarch64 = "defconfig" > +KBUILD_DEFCONFIG:qemux86-64 = "x86_64_defconfig" > > I tried again. With the patches perf builds for all three machines, > reverting the patches and it fails again. > The x86 compiles forever, for the two ARM machines I get: > ... > Traceback (most recent call last): > File "/build/krm/oe-core_master/build/tmp/work/qemuarm64-tdx-linux/perf/1.0-r9/perf-1.0/sort-pmuevents.py", > line 83, in <module> > print( preamble.group(1) ) > AttributeError: 'NoneType' object has no attribute 'group' Definitely still fails here for some of my configurations. I'll look into it more today, and see if there's something in my reference kernel configurations that are causing it. I need to sort this out, and can put it in a queue with my -dev upgrades to 5.16, since without those version bumps, we have nothing in core that exercises the change. Cheers, Bruce > ... > > Max > > > > > > > > > Note that the kernel itself doesn't build either as after 5.15 it now > > > does try to run the dt_binding_check for which the kernel recipe does > > > not provide whatever stuff is needed. > > > I just did a revert patch for commit 53182e81f47d ("kbuild: Enable > > > DT schema checks for %.dtb targets") to get over that. > > > > > > Max Krummenacher (2): > > > perf: sort-pmuevents: don't drop elements > > > perf: sort-pmuevents: allow for additional type qualifiers and storage > > > class > > > > > > .../perf/perf/sort-pmuevents.py | 28 +++++++++++-------- > > > 1 file changed, 16 insertions(+), 12 deletions(-) > > > > > > -- > > > 2.20.1 > > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II
Let me know if there is anything I can do/provide from my side. I know you already did, but does 'bitbake perf -c cleansstate' help? Max On Tue, Nov 23, 2021 at 2:55 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > On Tue, Nov 23, 2021 at 8:48 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > > > Hi Bruce, > > > > On Tue, Nov 23, 2021 at 2:41 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > On Mon, Nov 22, 2021 at 11:35 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > > > > > > > I am trying out a kernel recipe using linux master, 5.16-rc2. I found > > > > that perf fails to build in do_compile with such a setup. > > > > Root cause is that the kernel did add 'static' and 'const' to the > > > > arrays of structs which sort-pmuevents does sort. > > > > This is addressed in the second commit. > > > > > > > > While at it I noticed that there are some struct arrays which neither > > > > have a name or cpuid element with 1 array element. That 1 element was > > > > dropped. I did not verify if that causes any issues at runtime, however > > > > that behaviour was improved with the first commit. > > > > > > What MACHINE were you testing against ? When I build perf against my > > > -rc2 dev kernel, I still run into the build issues with these commits > > > in place. > > > > > > I just want to make sure that I'm not seeing something different .. so > > > I can do some runs against a similar config as you are using. > > > > > > > I did the inital work against a Toradex machine, apalis-imx6. > > However I built before sending the patches with qemuarm64 qemuarm qemux86-64 > > with the following modification to use my 'master' kernel recipe: > > +PREFERRED_PROVIDER_virtual/kernel = "linux-toradex-mainline" > > +KBUILD_DEFCONFIG:arm = "tegra_defconfig" > > +KBUILD_DEFCONFIG:aarch64 = "defconfig" > > +KBUILD_DEFCONFIG:qemux86-64 = "x86_64_defconfig" > > > > I tried again. With the patches perf builds for all three machines, > > reverting the patches and it fails again. > > The x86 compiles forever, for the two ARM machines I get: > > ... > > Traceback (most recent call last): > > File "/build/krm/oe-core_master/build/tmp/work/qemuarm64-tdx-linux/perf/1.0-r9/perf-1.0/sort-pmuevents.py", > > line 83, in <module> > > print( preamble.group(1) ) > > AttributeError: 'NoneType' object has no attribute 'group' > > Definitely still fails here for some of my configurations. I'll look > into it more today, and see if there's something in my reference > kernel configurations that are causing it. > > I need to sort this out, and can put it in a queue with my -dev > upgrades to 5.16, since without those version bumps, we have nothing > in core that exercises the change. > > Cheers, > > Bruce > > > ... > > > > Max > > > > > > > > > > > > > Note that the kernel itself doesn't build either as after 5.15 it now > > > > does try to run the dt_binding_check for which the kernel recipe does > > > > not provide whatever stuff is needed. > > > > I just did a revert patch for commit 53182e81f47d ("kbuild: Enable > > > > DT schema checks for %.dtb targets") to get over that. > > > > > > > > Max Krummenacher (2): > > > > perf: sort-pmuevents: don't drop elements > > > > perf: sort-pmuevents: allow for additional type qualifiers and storage > > > > class > > > > > > > > .../perf/perf/sort-pmuevents.py | 28 +++++++++++-------- > > > > 1 file changed, 16 insertions(+), 12 deletions(-) > > > > > > > > -- > > > > 2.20.1 > > > > > > > > > > > > > -- > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > thee at its end > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II
On Tue, Nov 23, 2021 at 8:58 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > Let me know if there is anything I can do/provide from my side. > I know you already did, but does 'bitbake perf -c cleansstate' help? The builds were clean, but to rule out old artifacts, I just started a new build on a separate server, without my normal sstate sharing configuration. Fingers crossed :D Bruce > > Max > > On Tue, Nov 23, 2021 at 2:55 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > On Tue, Nov 23, 2021 at 8:48 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > > > > > Hi Bruce, > > > > > > On Tue, Nov 23, 2021 at 2:41 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > > > On Mon, Nov 22, 2021 at 11:35 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > > > > > > > > > I am trying out a kernel recipe using linux master, 5.16-rc2. I found > > > > > that perf fails to build in do_compile with such a setup. > > > > > Root cause is that the kernel did add 'static' and 'const' to the > > > > > arrays of structs which sort-pmuevents does sort. > > > > > This is addressed in the second commit. > > > > > > > > > > While at it I noticed that there are some struct arrays which neither > > > > > have a name or cpuid element with 1 array element. That 1 element was > > > > > dropped. I did not verify if that causes any issues at runtime, however > > > > > that behaviour was improved with the first commit. > > > > > > > > What MACHINE were you testing against ? When I build perf against my > > > > -rc2 dev kernel, I still run into the build issues with these commits > > > > in place. > > > > > > > > I just want to make sure that I'm not seeing something different .. so > > > > I can do some runs against a similar config as you are using. > > > > > > > > > > I did the inital work against a Toradex machine, apalis-imx6. > > > However I built before sending the patches with qemuarm64 qemuarm qemux86-64 > > > with the following modification to use my 'master' kernel recipe: > > > +PREFERRED_PROVIDER_virtual/kernel = "linux-toradex-mainline" > > > +KBUILD_DEFCONFIG:arm = "tegra_defconfig" > > > +KBUILD_DEFCONFIG:aarch64 = "defconfig" > > > +KBUILD_DEFCONFIG:qemux86-64 = "x86_64_defconfig" > > > > > > I tried again. With the patches perf builds for all three machines, > > > reverting the patches and it fails again. > > > The x86 compiles forever, for the two ARM machines I get: > > > ... > > > Traceback (most recent call last): > > > File "/build/krm/oe-core_master/build/tmp/work/qemuarm64-tdx-linux/perf/1.0-r9/perf-1.0/sort-pmuevents.py", > > > line 83, in <module> > > > print( preamble.group(1) ) > > > AttributeError: 'NoneType' object has no attribute 'group' > > > > Definitely still fails here for some of my configurations. I'll look > > into it more today, and see if there's something in my reference > > kernel configurations that are causing it. > > > > I need to sort this out, and can put it in a queue with my -dev > > upgrades to 5.16, since without those version bumps, we have nothing > > in core that exercises the change. > > > > Cheers, > > > > Bruce > > > > > ... > > > > > > Max > > > > > > > > > > > > > > > > > Note that the kernel itself doesn't build either as after 5.15 it now > > > > > does try to run the dt_binding_check for which the kernel recipe does > > > > > not provide whatever stuff is needed. > > > > > I just did a revert patch for commit 53182e81f47d ("kbuild: Enable > > > > > DT schema checks for %.dtb targets") to get over that. > > > > > > > > > > Max Krummenacher (2): > > > > > perf: sort-pmuevents: don't drop elements > > > > > perf: sort-pmuevents: allow for additional type qualifiers and storage > > > > > class > > > > > > > > > > .../perf/perf/sort-pmuevents.py | 28 +++++++++++-------- > > > > > 1 file changed, 16 insertions(+), 12 deletions(-) > > > > > > > > > > -- > > > > > 2.20.1 > > > > > > > > > > > > > > > > > -- > > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > > thee at its end > > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II
On Tue, Nov 23, 2021 at 9:05 AM Bruce Ashfield via lists.openembedded.org <bruce.ashfield=gmail.com@lists.openembedded.org> wrote: > > On Tue, Nov 23, 2021 at 8:58 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > > > Let me know if there is anything I can do/provide from my side. > > I know you already did, but does 'bitbake perf -c cleansstate' help? > > The builds were clean, but to rule out old artifacts, I just started a > new build on a separate server, without my normal sstate sharing > configuration. Fingers crossed :D It is building on my completely fresh box. Which does imply I was getting the old script before .. but I can't say for sure why. Regardless, I'm sending a consolidated pull request shortly with some v5.16 fixes, and have these stacked on top, just to confirm they are working in my setup and that I've tested them. Bruce > > Bruce > > > > > Max > > > > On Tue, Nov 23, 2021 at 2:55 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > On Tue, Nov 23, 2021 at 8:48 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > > > > > > > Hi Bruce, > > > > > > > > On Tue, Nov 23, 2021 at 2:41 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > > > > > On Mon, Nov 22, 2021 at 11:35 AM Max Krummenacher <max.oss.09@gmail.com> wrote: > > > > > > > > > > > > I am trying out a kernel recipe using linux master, 5.16-rc2. I found > > > > > > that perf fails to build in do_compile with such a setup. > > > > > > Root cause is that the kernel did add 'static' and 'const' to the > > > > > > arrays of structs which sort-pmuevents does sort. > > > > > > This is addressed in the second commit. > > > > > > > > > > > > While at it I noticed that there are some struct arrays which neither > > > > > > have a name or cpuid element with 1 array element. That 1 element was > > > > > > dropped. I did not verify if that causes any issues at runtime, however > > > > > > that behaviour was improved with the first commit. > > > > > > > > > > What MACHINE were you testing against ? When I build perf against my > > > > > -rc2 dev kernel, I still run into the build issues with these commits > > > > > in place. > > > > > > > > > > I just want to make sure that I'm not seeing something different .. so > > > > > I can do some runs against a similar config as you are using. > > > > > > > > > > > > > I did the inital work against a Toradex machine, apalis-imx6. > > > > However I built before sending the patches with qemuarm64 qemuarm qemux86-64 > > > > with the following modification to use my 'master' kernel recipe: > > > > +PREFERRED_PROVIDER_virtual/kernel = "linux-toradex-mainline" > > > > +KBUILD_DEFCONFIG:arm = "tegra_defconfig" > > > > +KBUILD_DEFCONFIG:aarch64 = "defconfig" > > > > +KBUILD_DEFCONFIG:qemux86-64 = "x86_64_defconfig" > > > > > > > > I tried again. With the patches perf builds for all three machines, > > > > reverting the patches and it fails again. > > > > The x86 compiles forever, for the two ARM machines I get: > > > > ... > > > > Traceback (most recent call last): > > > > File "/build/krm/oe-core_master/build/tmp/work/qemuarm64-tdx-linux/perf/1.0-r9/perf-1.0/sort-pmuevents.py", > > > > line 83, in <module> > > > > print( preamble.group(1) ) > > > > AttributeError: 'NoneType' object has no attribute 'group' > > > > > > Definitely still fails here for some of my configurations. I'll look > > > into it more today, and see if there's something in my reference > > > kernel configurations that are causing it. > > > > > > I need to sort this out, and can put it in a queue with my -dev > > > upgrades to 5.16, since without those version bumps, we have nothing > > > in core that exercises the change. > > > > > > Cheers, > > > > > > Bruce > > > > > > > ... > > > > > > > > Max > > > > > > > > > > > > > > > > > > > > > Note that the kernel itself doesn't build either as after 5.15 it now > > > > > > does try to run the dt_binding_check for which the kernel recipe does > > > > > > not provide whatever stuff is needed. > > > > > > I just did a revert patch for commit 53182e81f47d ("kbuild: Enable > > > > > > DT schema checks for %.dtb targets") to get over that. > > > > > > > > > > > > Max Krummenacher (2): > > > > > > perf: sort-pmuevents: don't drop elements > > > > > > perf: sort-pmuevents: allow for additional type qualifiers and storage > > > > > > class > > > > > > > > > > > > .../perf/perf/sort-pmuevents.py | 28 +++++++++++-------- > > > > > > 1 file changed, 16 insertions(+), 12 deletions(-) > > > > > > > > > > > > -- > > > > > > 2.20.1 > > > > > > > > > > > > > > > > > > > > > -- > > > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > > > thee at its end > > > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > > > > > -- > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > thee at its end > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#158604): https://lists.openembedded.org/g/openembedded-core/message/158604 > Mute This Topic: https://lists.openembedded.org/mt/87238903/1050810 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >