Hello Kevin, On Tue, Nov 25, 2014 at 8:50 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: > On Mon, Nov 24, 2014 at 5:50 PM, Kukjin Kim <kgene@xxxxxxxxxx> wrote: >> Olof Johansson wrote: >>> >>> On Mon, Nov 24, 2014 at 5:37 PM, Olof Johansson <olof@xxxxxxxxx> wrote: >>> > On Mon, Nov 24, 2014 at 5:35 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >>> >> On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson <olof@xxxxxxxxx> wrote: >>> >>> On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >>> >>>> Kukjin, >>> >>>> >>> >>>> On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >>> >>>>> Kukjin Kim <kgene@xxxxxxxxxx> writes: >>> >>>>> >>> >>>>>> Kevin Hilman wrote: >>> >>>>>>> >>> >>>>>>> From: Kevin Hilman <khilman@xxxxxxxxxx> >>> >>>>>>> >>> >>>>>>> The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts >>> >>>>>>> during boot testing, causing various userspace startup failures. >>> >>>>>>> >>> >>>>>>> Disable until it has gotten more testing. >>> >>>>>>> >>> >>>>>>> Cc: Kukjin Kim <kgene.kim@xxxxxxxxxxx>, >>> >>>>>>> Cc: Javier Martinez Canillas <javier.martinez@xxxxxxxxxxxxxxx>, >>> >>>>>>> Cc: Sachin Kamat <sachin.kamat@xxxxxxxxxxx>, >>> >>>>>>> Cc: Doug Anderson <dianders@xxxxxxxxxxxx>, >>> >>>>>>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@xxxxxxxxxxx>, >>> >>>>>>> Cc: Krzysztof Kozlowski <k.kozlowski@xxxxxxxxxxx>, >>> >>>>>>> Cc: Tushar Behera <tushar.behera@xxxxxxxxxx>, >>> >>>>>>> Cc: stable@xxxxxxxxxxxxxxx # v3.17+ >>> >>>>>>> Signed-off-by: Kevin Hilman <khilman@xxxxxxxxxx> >>> >>>>>>> --- >>> >>>>>>> This has been reported by a few people[1], but not investigated or fixed, so it's >>> >>>>>>> time to disable this feature until it can be fixed. >>> >>>>>>> >>> >>>>>> Hi Kevin, >>> >>>>>> >>> >>>>>> Yeah I agree with your opinion. >>> >>>>>> >>> >>>>>> But as you can see my tree, I've queued regarding mcpm patches for 3.19 will >>> >>>>>> be shown in -next in this weekend. >>> >>>>> >>> >>>>> Which of the recently queued patches are expected to address the >>> >>>>> imprecise abort issue? I'd be happy to test them out. >>> >>>> >>> >>>> Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. >>> >>>> >>> >>>> What is the status of $SUBJECT patch? >>> >>>> >>> >>>>>> Anyway let me apply this into -fixes and >>> >>>>>> then let's enable after test its functionality in -next in a couple of days. >>> >>>>> >>> >>>>> Yes, I think this needs to be applied until these aborts are understood >>> >>>>> and fixed. >>> >>>> >>> >>>> Is anyone at Samsung actually looking into these MCPM issues? >>> >>> >>> >>> Hi Kevin, >>> >>> >>> >>> What hardware are you having problems with? 5420 or 5422/5800? >>> >> >>> >> Yes. :) >>> >> >>> >> exynos5420-arndale-octa: >>> >> http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420- >>> arndale-octa.html >>> >> exynos5422-odroid-xu3: >>> >> http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422- >>> odroid-xu3.html >>> >> >>> >> My boot tests seem to pass fine because I have such a minimal >>> >> userspace, but Tyler Baker reported that with a "real" userspace, he >>> >> can't boot to a shell: >>> >> >>> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html >>> > >> Hmm...his report was in Sep...I think it should be fine with current -next? > > No, it is still broken in linux-next (as I stated above.) > > Moreover, earlier in this thread you mentioned you were merging some > MCPM patches that should address this, but did not respond when I > asked which patches you thing should address this issue > >> To be honest, since I don't have the exynos5420 arndale, chromebook...but smdk >> which has different bootloader, I couldn't test it...I'll try to make a test >> farm like you guys... > > Do you have some colleagues with any other 542x hardware? I had > assumed that linux-next was being better tested on the publicaly > available, and widely available boards like odroid-xu3 and > Chromebook2, but I've come to realize the hard way that that is not Are you seeing this on Chromebook2 (Peach-Pi 5800) too ? > the case. You mention your board has a different bootloader. Do you > suspect there's a bootloader issue on these other platforms? If so, > could you elaborate on possible fixes? I'm more than willing to test > any proposed fixes, but I'm not familiar enough yet with these SoCs to > figure out the underlying issues alone. > > Until you have a working board farm, you could start having a closer > look at the boot logs we're already producing. Admittedly linux-next > broken in many ways besides this one for exynos currently, but it has > been having these imprecise aborts well before the other recent > issues. > > Also, It's very possible that this issue is not even MCPM related at > all, and MCPM is just uncovering a previously hidden bug. It would be > very helpful if people more familiar with this hardware and SoC would > investigate bug reports like these. The 3 boards I have access to (SMDK5420, Chromebook Peach-Pi and Chromebook Peach-Pit) work fine with MCPM enabled. I am not sure why it is failing only on the above mentioned boards as there is nothing specific to them in the MCPM back-end. I assume that when you default to platsmp (on disabling MCPM), the non-working boards boot all cores upto userspace without any issues ? Based on the timeline (problems started about 2.5 months back), there have only been a couple of changes in the 5420 MCPM back-end. Could you revert the following commits and check if things improve. 20fe6f9 ARM: EXYNOS: Support cluster power off on exynos5420/5800 fbb0499 ARM: 8083/1: exynos: activate the CCI on boot CPU/cluster using the MCPM loopback These might not revert cleanly, so instead of the above you could also comment the following 2 lines: diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c index dc9a764..9a07188 100644 --- a/arch/arm/mach-exynos/mcpm-exynos.c +++ b/arch/arm/mach-exynos/mcpm-exynos.c @@ -152,7 +152,7 @@ static void exynos_power_down(void) exynos_cpu_power_down(cpunr); if (exynos_cluster_unused(cluster)) { - exynos_cluster_power_down(cluster); + //exynos_cluster_power_down(cluster); last_man = true; } } else if (cpu_use_count[cpu][cluster] == 1) { @@ -356,8 +356,8 @@ static int __init exynos_mcpm_init(void) ret = mcpm_platform_register(&exynos_power_ops); if (!ret) ret = mcpm_sync_init(exynos_pm_power_up_setup); - if (!ret) - ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */ + //if (!ret) + //ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */ if (ret) { iounmap(ns_sram_base_addr); return ret; If you still get aborts then I suspect that the problem is with the bootloader configuration but am not sure. I am OK with disabling 5420_MCPM in the default configuration in such a case. This would however mean that S2R also stops working by default on 5420. Regards, Abhilash > > Kevin > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |