Re: next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
On Fri, 18 Dec 2020 at 20:12, Ard Biesheuvel wrote: > > On Fri, 18 Dec 2020 at 15:01, Ard Biesheuvel wrote: > > > > On Fri, 18 Dec 2020 at 15:00, Russell King - ARM Linux admin > > wrote: > > > > > > On Fri, Dec 18, 2020 at 01:48:09PM +, Guillaume Tucker wrote: > > > > Please see the bisection report below about a boot failure on > > > > ox820-cloudengines-pogoplug-series-3. There was also a bisection > > > > yesterday with next-20201216 which landed on the same commit, on > > > > the same platform and also with oxnas_v6_defconfig. I'm not > > > > aware of any other platform on kernelci.org showing the same > > > > regression. > > > > > > Ah, I bet I know what's happening. > > > > > > We test for the presence of VFP by issuing an instruction to read > > > FPSID. If VFP is not present, this will raise an undefined instruction > > > exception, and we expect to head into the vfp_testing_entry code. > > > > > > I bet Pogoplug, being an ARM11 MPCore platform, either raises an > > > exception here. > > > > > > We probably need to also rework the code in vfp_init() as well to > > > register a temporary hook when reading the FPSID. > > > > > > > Thanks for diagnosing that - I wasn't quite sure what was going on. > > > > I will look into this later today. > > Working again with my fix applied: https://kernelci.org/test/plan/id/5fdcebf1a6350e2bd1c94cd3/ I'll drop it into the patch system tomorrow (unless there is a pressing need to do it earlier)
Re: next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
On Fri, 18 Dec 2020 at 15:01, Ard Biesheuvel wrote: > > On Fri, 18 Dec 2020 at 15:00, Russell King - ARM Linux admin > wrote: > > > > On Fri, Dec 18, 2020 at 01:48:09PM +, Guillaume Tucker wrote: > > > Please see the bisection report below about a boot failure on > > > ox820-cloudengines-pogoplug-series-3. There was also a bisection > > > yesterday with next-20201216 which landed on the same commit, on > > > the same platform and also with oxnas_v6_defconfig. I'm not > > > aware of any other platform on kernelci.org showing the same > > > regression. > > > > Ah, I bet I know what's happening. > > > > We test for the presence of VFP by issuing an instruction to read > > FPSID. If VFP is not present, this will raise an undefined instruction > > exception, and we expect to head into the vfp_testing_entry code. > > > > I bet Pogoplug, being an ARM11 MPCore platform, either raises an > > exception here. > > > > We probably need to also rework the code in vfp_init() as well to > > register a temporary hook when reading the FPSID. > > > > Thanks for diagnosing that - I wasn't quite sure what was going on. > > I will look into this later today. Working again with my fix applied:
Re: next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
On Fri, 18 Dec 2020 at 15:00, Russell King - ARM Linux admin wrote: > > On Fri, Dec 18, 2020 at 01:48:09PM +, Guillaume Tucker wrote: > > Please see the bisection report below about a boot failure on > > ox820-cloudengines-pogoplug-series-3. There was also a bisection > > yesterday with next-20201216 which landed on the same commit, on > > the same platform and also with oxnas_v6_defconfig. I'm not > > aware of any other platform on kernelci.org showing the same > > regression. > > Ah, I bet I know what's happening. > > We test for the presence of VFP by issuing an instruction to read > FPSID. If VFP is not present, this will raise an undefined instruction > exception, and we expect to head into the vfp_testing_entry code. > > I bet Pogoplug, being an ARM11 MPCore platform, either raises an > exception here. > > We probably need to also rework the code in vfp_init() as well to > register a temporary hook when reading the FPSID. > Thanks for diagnosing that - I wasn't quite sure what was going on. I will look into this later today.
Re: next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
On Fri, Dec 18, 2020 at 01:48:09PM +, Guillaume Tucker wrote: > Please see the bisection report below about a boot failure on > ox820-cloudengines-pogoplug-series-3. There was also a bisection > yesterday with next-20201216 which landed on the same commit, on > the same platform and also with oxnas_v6_defconfig. I'm not > aware of any other platform on kernelci.org showing the same > regression. Ah, I bet I know what's happening. We test for the presence of VFP by issuing an instruction to read FPSID. If VFP is not present, this will raise an undefined instruction exception, and we expect to head into the vfp_testing_entry code. I bet Pogoplug, being an ARM11 MPCore platform, either raises an exception here. We probably need to also rework the code in vfp_init() as well to register a temporary hook when reading the FPSID. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
Hi Ard,
Please see the bisection report below about a boot failure on
ox820-cloudengines-pogoplug-series-3. There was also a bisection
yesterday with next-20201216 which landed on the same commit, on
the same platform and also with oxnas_v6_defconfig. I'm not
aware of any other platform on kernelci.org showing the same
regression.
Hope this helps!
Best wishes,
Guillaume
On 18/12/2020 10:51, KernelCI bot wrote:
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer:*
> * Reported-by: "kernelci.org bot" *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
>
> Summary:
> Start: 90cc8cf2d1ab Add linux-next specific files for 20201217
> Plain log:
> https://storage.kernelci.org/next/master/next-20201217/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/baseline-ox820-cloudengines-pogoplug-series-3.txt
> HTML log:
> https://storage.kernelci.org/next/master/next-20201217/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/baseline-ox820-cloudengines-pogoplug-series-3.html
> Result: f77ac2e378be ARM: 9030/1: entry: omit FP emulation for UND
> exceptions taken in kernel mode
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: next
> URL:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> Branch: master
> Target: ox820-cloudengines-pogoplug-series-3
> CPU arch: arm
> Lab:lab-baylibre
> Compiler: gcc-8
> Config: oxnas_v6_defconfig
> Test case: baseline.login
>
> Breaking commit found:
>
> ---
> commit f77ac2e378be9dd61eb88728f0840642f045d9d1
> Author: Ard Biesheuvel
> Date: Thu Nov 19 18:09:16 2020 +0100
>
> ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel
> mode
>
> There are a couple of problems with the exception entry code that deals
> with FP exceptions (which are reported as UND exceptions) when building
> the kernel in Thumb2 mode:
> - the conditional branch to vfp_kmode_exception in vfp_support_entry()
> may be out of range for its target, depending on how the linker decides
> to arrange the sections;
> - when the UND exception is taken in kernel mode, the emulation handling
> logic is entered via the 'call_fpe' label, which means we end up using
> the wrong value/mask pairs to match and detect the NEON opcodes.
>
> Since UND exceptions in kernel mode are unlikely to occur on a hot path
> (as opposed to the user mode version which is invoked for VFP support
> code and lazy restore), we can use the existing undef hook machinery for
> any kernel mode instruction emulation that is needed, including calling
> the existing vfp_kmode_exception() routine for unexpected cases. So drop
> the call to call_fpe, and instead, install an undef hook that will get
> called for NEON and VFP instructions that trigger an UND exception in
> kernel mode.
>
> While at it, make sure that the PC correction is accurate for the
> execution mode where the exception was taken, by checking the PSR
> Thumb bit.
>
> Cc: Dmitry Osipenko
> Cc: Kees Cook
> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
> Signed-off-by: Ard Biesheuvel
> Reviewed-by: Linus Walleij
> Reviewed-by: Nick Desaulniers
> Signed-off-by: Russell King
>
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index c4220f51fcf3..0ea8529a4872 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -252,31 +252,10 @@ __und_svc:
> #else
> svc_entry
> #endif
> - @
> - @ call emulation code, which returns using r9 if it has emulated
> - @ the instruction, or the more conventional lr if we are to treat
> - @ this as a real undefined instruction
> - @
> - @ r0 - instruction
> - @
> -#ifndef CONFIG_THUMB2_KERNEL
> - ldr r0, [r4, #-4
Re: next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
On Thu, 18 Jun 2020 15:23:45 +0100 Guillaume Tucker wrote: > On 18/06/2020 15:09, Miquel Raynal wrote: > > Hi Guillaume, > > > > Miquel Raynal wrote on Thu, 18 Jun 2020 > > 15:23:24 +0200: > > > >> Hi Guillaume, > >> > >> Guillaume Tucker wrote on Thu, 18 Jun > >> 2020 13:28:05 +0100: > >> > >>> Please see the bisection report below about a kernel panic. > >>> > >>> Reports aren't automatically sent to the public while we're > >>> trialing new bisection features on kernelci.org but this one > >>> looks valid. > >>> > >>> See the kernel Oops due to a NULL pointer followed by a panic: > >>> > >>> > >>> https://storage.kernelci.org/next/master/next-20200618/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/baseline-ox820-cloudengines-pogoplug-series-3.html#L504 > >>> > >> > >> Thanks for the report, I will not be able to manage it before Monday, > >> but I'll try to take care of it early next week. > > > > Actually Boris saw the issue, I just updated nand/next, it should be > > part of tomorrow's linux-next. Could you please report if it fixes your > > boot? > > Sure, will check tomorrow. Thanks for the update. > > We may also consider adding the nand/next branch to kernelci.org > and catch issues earlier. We can discuss that separately. If you're testing linux-next that shouldn't help us much (nand/next is pulled in linux-next already), but maybe it's just about making the bisection easier for kernelci (less commits to inspect), in which case that's probably a good idea. You might also want to add mtd/next, spi-nor/next and cfi/next so the entire MTD subsystem gets tested.
Re: next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
On 18/06/2020 15:09, Miquel Raynal wrote: > Hi Guillaume, > > Miquel Raynal wrote on Thu, 18 Jun 2020 > 15:23:24 +0200: > >> Hi Guillaume, >> >> Guillaume Tucker wrote on Thu, 18 Jun >> 2020 13:28:05 +0100: >> >>> Please see the bisection report below about a kernel panic. >>> >>> Reports aren't automatically sent to the public while we're >>> trialing new bisection features on kernelci.org but this one >>> looks valid. >>> >>> See the kernel Oops due to a NULL pointer followed by a panic: >>> >>> >>> https://storage.kernelci.org/next/master/next-20200618/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/baseline-ox820-cloudengines-pogoplug-series-3.html#L504 >> >> Thanks for the report, I will not be able to manage it before Monday, >> but I'll try to take care of it early next week. > > Actually Boris saw the issue, I just updated nand/next, it should be > part of tomorrow's linux-next. Could you please report if it fixes your > boot? Sure, will check tomorrow. Thanks for the update. We may also consider adding the nand/next branch to kernelci.org and catch issues earlier. We can discuss that separately. Guillaume
Re: next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
Hi Guillaume, Miquel Raynal wrote on Thu, 18 Jun 2020 15:23:24 +0200: > Hi Guillaume, > > Guillaume Tucker wrote on Thu, 18 Jun > 2020 13:28:05 +0100: > > > Please see the bisection report below about a kernel panic. > > > > Reports aren't automatically sent to the public while we're > > trialing new bisection features on kernelci.org but this one > > looks valid. > > > > See the kernel Oops due to a NULL pointer followed by a panic: > > > > > > https://storage.kernelci.org/next/master/next-20200618/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/baseline-ox820-cloudengines-pogoplug-series-3.html#L504 > > Thanks for the report, I will not be able to manage it before Monday, > but I'll try to take care of it early next week. Actually Boris saw the issue, I just updated nand/next, it should be part of tomorrow's linux-next. Could you please report if it fixes your boot? Thanks, Miquèl
Re: next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
Hi Guillaume, Guillaume Tucker wrote on Thu, 18 Jun 2020 13:28:05 +0100: > Please see the bisection report below about a kernel panic. > > Reports aren't automatically sent to the public while we're > trialing new bisection features on kernelci.org but this one > looks valid. > > See the kernel Oops due to a NULL pointer followed by a panic: > > > https://storage.kernelci.org/next/master/next-20200618/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/baseline-ox820-cloudengines-pogoplug-series-3.html#L504 Thanks for the report, I will not be able to manage it before Monday, but I'll try to take care of it early next week. Thanks for your patience, Miquèl
Re: next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3
Please see the bisection report below about a kernel panic. Reports aren't automatically sent to the public while we're trialing new bisection features on kernelci.org but this one looks valid. See the kernel Oops due to a NULL pointer followed by a panic: https://storage.kernelci.org/next/master/next-20200618/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/baseline-ox820-cloudengines-pogoplug-series-3.html#L504 Thanks, Guillaume On 18/06/2020 13:20, kernelci.org bot wrote: > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * This automated bisection report was sent to you on the basis * > * that you may be involved with the breaking commit it has * > * found. No manual investigation has been done to verify it, * > * and the root cause of the problem may be somewhere else. * > * * > * If you do send a fix, please include this trailer:* > * Reported-by: "kernelci.org bot" * > * * > * Hope this helps! * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > next/master bisection: baseline.login on ox820-cloudengines-pogoplug-series-3 > > Summary: > Start: ce2cc8efd7a4 Add linux-next specific files for 20200618 > Plain log: > https://storage.kernelci.org/next/master/next-20200618/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/baseline-ox820-cloudengines-pogoplug-series-3.txt > HTML log: > https://storage.kernelci.org/next/master/next-20200618/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/baseline-ox820-cloudengines-pogoplug-series-3.html > Result: 7b929258ff0e mtd: rawnand: Allocate the interface > configurations dynamically > > Checks: > revert: PASS > verify: PASS > > Parameters: > Tree: next > URL: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > Branch: master > Target: ox820-cloudengines-pogoplug-series-3 > CPU arch: arm > Lab:lab-baylibre > Compiler: gcc-8 > Config: oxnas_v6_defconfig > Test case: baseline.login > > Breaking commit found: > > --- > commit 7b929258ff0e913616e21661a757f5ecb776d337 > Author: Miquel Raynal > Date: Fri May 29 13:13:22 2020 +0200 > > mtd: rawnand: Allocate the interface configurations dynamically > > Instead of manipulating the statically allocated structure and copy > timings around, allocate one at identification time and save it in the > nand_chip structure once it has been initialized. > > All NAND chips using the same interface configuration during reset and > startup, we define a helper to retrieve a single reset interface > configuration object, shared across all NAND chips. > > We use a second pointer to always have a reference on the currently > applied interface configuration, which may either point to the "best > interface configuration" or to the "default reset interface > configuration". > > Signed-off-by: Miquel Raynal > Reviewed-by: Boris Brezillon > Link: > https://lore.kernel.org/linux-mtd/20200529111322.7184-29-miquel.ray...@bootlin.com > > diff --git a/drivers/mtd/nand/raw/internals.h > b/drivers/mtd/nand/raw/internals.h > index 5ebfbb89e572..012876e14317 100644 > --- a/drivers/mtd/nand/raw/internals.h > +++ b/drivers/mtd/nand/raw/internals.h > @@ -93,6 +93,7 @@ onfi_find_closest_sdr_mode(const struct nand_sdr_timings > *spec_timings); > int nand_choose_best_sdr_timings(struct nand_chip *chip, >struct nand_interface_config *iface, >struct nand_sdr_timings *spec_timings); > +const struct nand_interface_config *nand_get_reset_interface_config(void); > int nand_get_features(struct nand_chip *chip, int addr, u8 > *subfeature_param); > int nand_set_features(struct nand_chip *chip, int addr, u8 > *subfeature_param); > int nand_read_page_raw_notsupp(struct nand_chip *chip, u8 *buf, > diff --git a/drivers/mtd/nand/raw/nand_base.c > b/drivers/mtd/nand/raw/nand_base.c > index 753328f106c1..4a0d486210e9 100644 > --- a/drivers/mtd/nand/raw/nand_base.c > +++ b/drivers/mtd/nand/raw/nand_base.c > @@ -928,9 +928,9 @@ static int nand_reset_interface(struct nand_chip *chip, > int chipnr) >* timings to timing mode 0. >*/ > > - onfi_fill_interface_config(chip, >interface_config, > -NAND_SDR_IFACE, 0); > - ret = ops->setu
