| Message ID | 1476361881-19685-2-git-send-email-jun.nie@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote: > GICR for multiple CPU can be described with start address and stride, > or with multiple address. Current multiple address and stride are > both used. Fix it. > > vmalloc patch 727a7f5a9 triggered this bug: > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008 > [ 0.097150] pgd = ffff000008602000 > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000 > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP > [ 0.097170] Modules linked in: > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474 > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT) > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000 > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20 > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5 > > Signed-off-by: Jun Nie <jun.nie@linaro.org> A Fixes: tag would be useful on a patch like this, to tell what patch introduced the problem. Please consider using them in the future. I've applied this one to fixes now. -Olof
On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote: > On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote: > > GICR for multiple CPU can be described with start address and stride, > > or with multiple address. Current multiple address and stride are > > both used. Fix it. > > > > vmalloc patch 727a7f5a9 triggered this bug: > > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008 > > [ 0.097150] pgd = ffff000008602000 > > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000 > > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP > > [ 0.097170] Modules linked in: > > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474 > > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT) > > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000 > > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c > > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20 > > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5 > > > > Signed-off-by: Jun Nie <jun.nie@linaro.org> > > A Fixes: tag would be useful on a patch like this, to tell what patch > introduced the problem. Please consider using them in the future. > > I've applied this one to fixes now. Hi Olof, I happened to still have this one in my todo folder as I must have missed your reply, and I stumbled over it while looking for things that may have gone missing. I don't see it in v4.9-rc6, did it get dropped accidentally? Arnd
On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote: >> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote: >> > GICR for multiple CPU can be described with start address and stride, >> > or with multiple address. Current multiple address and stride are >> > both used. Fix it. >> > >> > vmalloc patch 727a7f5a9 triggered this bug: >> > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008 >> > [ 0.097150] pgd = ffff000008602000 >> > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000 >> > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP >> > [ 0.097170] Modules linked in: >> > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474 >> > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT) >> > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000 >> > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c >> > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20 >> > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5 >> > >> > Signed-off-by: Jun Nie <jun.nie@linaro.org> >> >> A Fixes: tag would be useful on a patch like this, to tell what patch >> introduced the problem. Please consider using them in the future. >> >> I've applied this one to fixes now. > > Hi Olof, > > I happened to still have this one in my todo folder as I must have > missed your reply, and I stumbled over it while looking for things > that may have gone missing. > > I don't see it in v4.9-rc6, did it get dropped accidentally? Please help get this into v4.9 if possible, as it is required to get v4.9 kernel boot up on ZTE ZX296718 SoC. Thanks. Shawn
On Monday, November 28, 2016 10:08:18 PM CET Shawn Guo wrote: > On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote: > >> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote: > >> > GICR for multiple CPU can be described with start address and stride, > >> > or with multiple address. Current multiple address and stride are > >> > both used. Fix it. > >> > > >> > vmalloc patch 727a7f5a9 triggered this bug: > >> > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008 > >> > [ 0.097150] pgd = ffff000008602000 > >> > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000 > >> > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP > >> > [ 0.097170] Modules linked in: > >> > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474 > >> > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT) > >> > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000 > >> > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c > >> > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20 > >> > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5 > >> > > >> > Signed-off-by: Jun Nie <jun.nie@linaro.org> > >> > >> A Fixes: tag would be useful on a patch like this, to tell what patch > >> introduced the problem. Please consider using them in the future. > >> > >> I've applied this one to fixes now. > > > > Hi Olof, > > > > I happened to still have this one in my todo folder as I must have > > missed your reply, and I stumbled over it while looking for things > > that may have gone missing. > > > > I don't see it in v4.9-rc6, did it get dropped accidentally? > > Please help get this into v4.9 if possible, as it is required to get > v4.9 kernel boot up on ZTE ZX296718 SoC. Thanks. > > Shawn > Ok, applied both. Thanks, Arnd
Just noticed this. On 13/10/16 13:31, Jun Nie wrote: > GICR for multiple CPU can be described with start address and stride, > or with multiple address. Current multiple address and stride are > both used. Fix it. > > vmalloc patch 727a7f5a9 triggered this bug: > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008 > [ 0.097150] pgd = ffff000008602000 > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000 > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP > [ 0.097170] Modules linked in: > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474 > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT) > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000 > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20 > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5 > > Signed-off-by: Jun Nie <jun.nie@linaro.org> > --- > arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++-------- > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi > index a223066..6b239a3 100644 > --- a/arch/arm64/boot/dts/zte/zx296718.dtsi > +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi > @@ -239,16 +239,11 @@ > compatible = "arm,gic-v3"; > #interrupt-cells = <3>; > #address-cells = <0>; > - #redistributor-regions = <6>; > - redistributor-stride = <0x0 0x40000>; > + #redistributor-regions = <1>; > + redistributor-stride = <0x20000>; Why is that stride specified? Is the GIC implementation so busted that the GICR_TYPER do not report a GICv3 redistributor, which implies a 128kB stride? Thanks, M.
On Friday, December 2, 2016 5:02:28 PM CET Marc Zyngier wrote: > On 13/10/16 13:31, Jun Nie wrote: > > GICR for multiple CPU can be described with start address and stride, > > or with multiple address. Current multiple address and stride are > > both used. Fix it. > > > > vmalloc patch 727a7f5a9 triggered this bug: > > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008 > > [ 0.097150] pgd = ffff000008602000 > > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000 > > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP > > [ 0.097170] Modules linked in: > > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474 > > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT) > > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000 > > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c > > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20 > > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5 > > > > Signed-off-by: Jun Nie <jun.nie@linaro.org> > > --- > > arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++-------- > > 1 file changed, 3 insertions(+), 8 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi > > index a223066..6b239a3 100644 > > --- a/arch/arm64/boot/dts/zte/zx296718.dtsi > > +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi > > @@ -239,16 +239,11 @@ > > compatible = "arm,gic-v3"; > > #interrupt-cells = <3>; > > #address-cells = <0>; > > - #redistributor-regions = <6>; > > - redistributor-stride = <0x0 0x40000>; > > + #redistributor-regions = <1>; > > + redistributor-stride = <0x20000>; > > Why is that stride specified? Is the GIC implementation so busted that > the GICR_TYPER do not report a GICv3 redistributor, which implies a > 128kB stride? Given that there is any concern about the patch now, and the merge window is almost open, I'm moving both patches to the next/fixes-non-critical branch and will merge it for v4.10 instead of sending it for v4.9. If you end up deciding that the patch is wrong, please follow up with a fix on top. Once the situation is resolved and the patch merged upstream, feel free to ask stable@vger.kernel.org for a backport to stable kernels to get it into v4.9.x. Arnd
On Fri, Dec 02, 2016 at 05:02:28PM +0000, Marc Zyngier wrote: > Just noticed this. > > On 13/10/16 13:31, Jun Nie wrote: > > GICR for multiple CPU can be described with start address and stride, > > or with multiple address. Current multiple address and stride are > > both used. Fix it. > > > > vmalloc patch 727a7f5a9 triggered this bug: > > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008 > > [ 0.097150] pgd = ffff000008602000 > > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000 > > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP > > [ 0.097170] Modules linked in: > > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474 > > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT) > > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000 > > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c > > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20 > > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5 > > > > Signed-off-by: Jun Nie <jun.nie@linaro.org> > > --- > > arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++-------- > > 1 file changed, 3 insertions(+), 8 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi > > index a223066..6b239a3 100644 > > --- a/arch/arm64/boot/dts/zte/zx296718.dtsi > > +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi > > @@ -239,16 +239,11 @@ > > compatible = "arm,gic-v3"; > > #interrupt-cells = <3>; > > #address-cells = <0>; > > - #redistributor-regions = <6>; > > - redistributor-stride = <0x0 0x40000>; > > + #redistributor-regions = <1>; > > + redistributor-stride = <0x20000>; > > Why is that stride specified? Is the GIC implementation so busted that > the GICR_TYPER do not report a GICv3 redistributor, which implies a > 128kB stride? No, it's not required per my testing. I guess it's there for documentation purpose to make the stride setting explicit. Are you suggesting that we simply drop it? Also, it seems that #redistributor-regions can also be saved, since bindings doc tells that it's only required if more than one such region is present? Shawn
On Sat, Dec 03 2016 at 09:22:55 AM, Shawn Guo <shawnguo@kernel.org> wrote: > On Fri, Dec 02, 2016 at 05:02:28PM +0000, Marc Zyngier wrote: >> Just noticed this. >> >> On 13/10/16 13:31, Jun Nie wrote: >> > GICR for multiple CPU can be described with start address and stride, >> > or with multiple address. Current multiple address and stride are >> > both used. Fix it. >> > >> > vmalloc patch 727a7f5a9 triggered this bug: >> > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008 >> > [ 0.097150] pgd = ffff000008602000 >> > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000 >> > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP >> > [ 0.097170] Modules linked in: >> > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474 >> > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT) >> > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000 >> > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c >> > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20 >> > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5 >> > >> > Signed-off-by: Jun Nie <jun.nie@linaro.org> >> > --- >> > arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++-------- >> > 1 file changed, 3 insertions(+), 8 deletions(-) >> > >> > diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi >> > index a223066..6b239a3 100644 >> > --- a/arch/arm64/boot/dts/zte/zx296718.dtsi >> > +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi >> > @@ -239,16 +239,11 @@ >> > compatible = "arm,gic-v3"; >> > #interrupt-cells = <3>; >> > #address-cells = <0>; >> > - #redistributor-regions = <6>; >> > - redistributor-stride = <0x0 0x40000>; >> > + #redistributor-regions = <1>; >> > + redistributor-stride = <0x20000>; >> >> Why is that stride specified? Is the GIC implementation so busted that >> the GICR_TYPER do not report a GICv3 redistributor, which implies a >> 128kB stride? > > No, it's not required per my testing. I guess it's there for > documentation purpose to make the stride setting explicit. Are you > suggesting that we simply drop it? Indeed. This is only meant as a workaround for some of the most braindead platforms out there which have a redistributor stride that deviates from what the architecture defines (128kB for GICv3, 256kB for GICv4). It is good to know that this implementation is not broken. > Also, it seems that #redistributor-regions can also be saved, since > bindings doc tells that it's only required if more than one such region > is present? This could be removed as well. Thanks, M.
On Fri, Dec 02, 2016 at 05:38:01PM +0100, Arnd Bergmann wrote: > On Monday, November 28, 2016 10:08:18 PM CET Shawn Guo wrote: > > On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > > On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote: > > >> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote: > > >> > GICR for multiple CPU can be described with start address and stride, > > >> > or with multiple address. Current multiple address and stride are > > >> > both used. Fix it. > > >> > > > >> > vmalloc patch 727a7f5a9 triggered this bug: > > >> > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008 > > >> > [ 0.097150] pgd = ffff000008602000 > > >> > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000 > > >> > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP > > >> > [ 0.097170] Modules linked in: > > >> > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474 > > >> > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT) > > >> > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000 > > >> > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c > > >> > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20 > > >> > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5 > > >> > > > >> > Signed-off-by: Jun Nie <jun.nie@linaro.org> > > >> > > >> A Fixes: tag would be useful on a patch like this, to tell what patch > > >> introduced the problem. Please consider using them in the future. > > >> > > >> I've applied this one to fixes now. > > > > > > Hi Olof, > > > > > > I happened to still have this one in my todo folder as I must have > > > missed your reply, and I stumbled over it while looking for things > > > that may have gone missing. > > > > > > I don't see it in v4.9-rc6, did it get dropped accidentally? > > > > Please help get this into v4.9 if possible, as it is required to get > > v4.9 kernel boot up on ZTE ZX296718 SoC. Thanks. > > > > Shawn > > > > Ok, applied both. Thanks, Patch 2/2 already went to you in the pull request[1]: [GIT PULL] ZTE arm64 device tree updates for 4.10 Shawn [1] http://www.spinics.net/lists/arm-kernel/msg545640.html
Hi Arnd, On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote: > Given that there is any concern about the patch now, and the merge > window is almost open, I'm moving both patches to the > next/fixes-non-critical branch and will merge it for v4.10 instead > of sending it for v4.9. > > If you end up deciding that the patch is wrong, please follow up > with a fix on top. Once the situation is resolved and the patch > merged upstream, feel free to ask stable@vger.kernel.org for a > backport to stable kernels to get it into v4.9.x. The patch is correct, though it can be cleaned up a bit further per Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can still get this into 4.9 to save the stable kernel backport. I sent you a cleanup patch on top of this one yesterday. If you like, I can quickly resend the patch with the cleanup squashed. Thanks, Shawn
Hi Shawn, On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote: > Hi Arnd, > > On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote: >> Given that there is any concern about the patch now, and the merge >> window is almost open, I'm moving both patches to the >> next/fixes-non-critical branch and will merge it for v4.10 instead >> of sending it for v4.9. >> >> If you end up deciding that the patch is wrong, please follow up >> with a fix on top. Once the situation is resolved and the patch >> merged upstream, feel free to ask stable@vger.kernel.org for a >> backport to stable kernels to get it into v4.9.x. > > The patch is correct, though it can be cleaned up a bit further per > Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can > still get this into 4.9 to save the stable kernel backport. > > I sent you a cleanup patch on top of this one yesterday. If you like, > I can quickly resend the patch with the cleanup squashed. Since the patches have already been applied, an incremental patch to apply on top would work best here. Thanks! -Olof
Hi Olof, On Mon, Dec 05, 2016 at 04:55:02PM -0800, Olof Johansson wrote: > Hi Shawn, > > On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote: > > Hi Arnd, > > > > On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote: > >> Given that there is any concern about the patch now, and the merge > >> window is almost open, I'm moving both patches to the > >> next/fixes-non-critical branch and will merge it for v4.10 instead > >> of sending it for v4.9. > >> > >> If you end up deciding that the patch is wrong, please follow up > >> with a fix on top. Once the situation is resolved and the patch > >> merged upstream, feel free to ask stable@vger.kernel.org for a > >> backport to stable kernels to get it into v4.9.x. > > > > The patch is correct, though it can be cleaned up a bit further per > > Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can > > still get this into 4.9 to save the stable kernel backport. > > > > I sent you a cleanup patch on top of this one yesterday. If you like, > > I can quickly resend the patch with the cleanup squashed. > > Since the patches have already been applied, an incremental patch to > apply on top would work best here. No problem. So would you please apply the incremental patch [1] to the same branch? Or I can send it to you later during -rc cycles. Just let me know your preference. Shawn [1] https://www.spinics.net/lists/arm-kernel/msg546957.html
On Tue, Dec 06, 2016 at 09:12:46AM +0800, Shawn Guo wrote: > Hi Olof, > > On Mon, Dec 05, 2016 at 04:55:02PM -0800, Olof Johansson wrote: > > Hi Shawn, > > > > On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote: > > > Hi Arnd, > > > > > > On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote: > > >> Given that there is any concern about the patch now, and the merge > > >> window is almost open, I'm moving both patches to the > > >> next/fixes-non-critical branch and will merge it for v4.10 instead > > >> of sending it for v4.9. > > >> > > >> If you end up deciding that the patch is wrong, please follow up > > >> with a fix on top. Once the situation is resolved and the patch > > >> merged upstream, feel free to ask stable@vger.kernel.org for a > > >> backport to stable kernels to get it into v4.9.x. > > > > > > The patch is correct, though it can be cleaned up a bit further per > > > Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can > > > still get this into 4.9 to save the stable kernel backport. > > > > > > I sent you a cleanup patch on top of this one yesterday. If you like, > > > I can quickly resend the patch with the cleanup squashed. > > > > Since the patches have already been applied, an incremental patch to > > apply on top would work best here. > > No problem. So would you please apply the incremental patch [1] to the > same branch? Or I can send it to you later during -rc cycles. Just let > me know your preference. > > Shawn > > [1] https://www.spinics.net/lists/arm-kernel/msg546957.html So, it seems that Arnd didn't apply the old patch to fixes-non-critical, or at least didn't push out after doing it. So, I've done that now, as well as applied the fixup you have above. -Olof
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi index a223066..6b239a3 100644 --- a/arch/arm64/boot/dts/zte/zx296718.dtsi +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi @@ -239,16 +239,11 @@ compatible = "arm,gic-v3"; #interrupt-cells = <3>; #address-cells = <0>; - #redistributor-regions = <6>; - redistributor-stride = <0x0 0x40000>; + #redistributor-regions = <1>; + redistributor-stride = <0x20000>; interrupt-controller; reg = <0x02a00000 0x10000>, - <0x02b00000 0x20000>, - <0x02b20000 0x20000>, - <0x02b40000 0x20000>, - <0x02b60000 0x20000>, - <0x02b80000 0x20000>, - <0x02ba0000 0x20000>; + <0x02b00000 0xc0000>; interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; };
GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it. vmalloc patch 727a7f5a9 triggered this bug: [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008 [ 0.097150] pgd = ffff000008602000 [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000 [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP [ 0.097170] Modules linked in: [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474 [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT) [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000 [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c [ 0.097202] LR is at gic_starting_cpu+0xc/0x20 [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5 Signed-off-by: Jun Nie <jun.nie@linaro.org> --- arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)