kgene's for-next branch broken, and boot regressions

kgene's for-next branch broken, and boot regressions

[Andreas Färber]

Hi Kukjin,

Are you aware that `make dtbs` fails on your for-next branch (4533046)?

  DTC     arch/arm/boot/dts/exynos5420-peach-pit.dtb
arch/arm/boot/dts/exynos5420-peach-pit.dts:447:33: fatal error:
cros-ec-keyboard.dtsi: No such file or directory
 #include "cros-ec-keyboard.dtsi"
                                 ^
compilation terminated.
scripts/Makefile.lib:273: recipe for target
'arch/arm/boot/dts/exynos5420-peach-pit.dtb' failed
make[1]: *** [arch/arm/boot/dts/exynos5420-peach-pit.dtb] Error 1
arch/arm/Makefile:314: recipe for target 'dtbs' failed
make: *** [dtbs] Error 2

On https://patchwork.kernel.org/patch/4297431/ Doug had pointed out that
a topic branch merge would be needed for cros-ec-keyboard.dtsi (which I
also pointed out for my spring series). Can you please fix this through
some merge? Your affected branch is v3.17-next/dt-samsung with "ARM:
dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi".
There's a topic branch in the Tegra tree:
http://git.kernel.org/cgit/linux/kernel/git/tegra/linux.git/log/?h=for-3.17/dt-cros-ec-kbd
and it's been merged into arm-soc recently.
https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/tree/arch/arm/boot/dts?h=for-next


Also, I've run into some boot regressions:

On the Arndale Octa (5420) I see an asynchronous external abort on
serial console when systemd gets started.

http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34680.html

On the Spring Chromebook (5250) the screen goes dark after a few lines,
and USB is not initialized. Thus unclear to me why.

On the ODROID-XU (with local patches based on smdk5410) I get the
following with earlyprintk:

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.16.0-rc6+ (andreas@droide) (gcc version
4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #2 SMP
PREEMPT Sun Jul 27 02:31:31 CEST 2014
[    0.000000] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7),
cr=30c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
cache
[    0.000000] Machine model: ODROID-XU based on EXYNOS5410
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Forcing write-allocate cache policy for SMP
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Running under secure firmware.
[    0.000000] PERCPU: Embedded 7 pages/cpu @ee7b3000 s7872 r8192 d12608
u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 522256
[    0.000000] Kernel command line: console=ttySAC2,115200n8 earlyprintk
root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[    0.000000] Memory: 2070984K/2095104K available (4364K kernel code,
271K rwdata, 1420K rodata, 271K init, 283K bss, 24120K reserved,
1316864K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc05ae384   (5785 kB)
[    0.000000]       .init : 0xc05af000 - 0xc05f2ec0   ( 272 kB)
[    0.000000]       .data : 0xc05f4000 - 0xc0637d80   ( 272 kB)
[    0.000000]        .bss : 0xc0637d8c - 0xc067eb00   ( 284 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] GIC physical location is 0x10481000
[    0.000000] Kernel panic - not syncing: failed to find exynos pmu
register
[    0.000000]
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc6+ #2
[    0.000000] [<c0022214>] (unwind_backtrace) from [<c001f3b4>]
(show_stack+0x10/0x14)
[    0.000000] [<c001f3b4>] (show_stack) from [<c04204d4>]
(dump_stack+0x80/0xc0)
[    0.000000] [<c04204d4>] (dump_stack) from [<c041d9a4>]
(panic+0xa4/0x200)
[    0.000000] [<c041d9a4>] (panic) from [<c05b745c>]
(exynos_reserve+0x0/0x4c)
[    0.000000] [<c05b745c>] (exynos_reserve) from [<00000000>] (  (null))
[    0.000000] ---[ end Kernel panic - not syncing: failed to find
exynos pmu register
[    0.000000]

Reverting "ARM: EXYNOS: Refactored code for using PMU address via DT"
and "ARM: EXYNOS: Add support for mapping PMU base address via DT" fixed
the latter.

Anyone know what might cause the others and how to fix?

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: kgene's for-next branch broken, and boot regressions

[Andreas Färber]

Am 27.07.2014 05:08, schrieb Andreas Färber:
> On the ODROID-XU (with local patches based on smdk5410) I get the
> following with earlyprintk:
> 
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 3.16.0-rc6+ (andreas@droide) (gcc version
> 4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #2 SMP
> PREEMPT Sun Jul 27 02:31:31 CEST 2014
> [    0.000000] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7),
> cr=30c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
> cache
> [    0.000000] Machine model: ODROID-XU based on EXYNOS5410
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] Forcing write-allocate cache policy for SMP
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] Running under secure firmware.
> [    0.000000] PERCPU: Embedded 7 pages/cpu @ee7b3000 s7872 r8192 d12608
> u32768
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 522256
> [    0.000000] Kernel command line: console=ttySAC2,115200n8 earlyprintk
> root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait
> [    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
> bytes)
> [    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
> bytes)
> [    0.000000] Memory: 2070984K/2095104K available (4364K kernel code,
> 271K rwdata, 1420K rodata, 271K init, 283K bss, 24120K reserved,
> 1316864K highmem)
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
> [    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc05ae384   (5785 kB)
> [    0.000000]       .init : 0xc05af000 - 0xc05f2ec0   ( 272 kB)
> [    0.000000]       .data : 0xc05f4000 - 0xc0637d80   ( 272 kB)
> [    0.000000]        .bss : 0xc0637d8c - 0xc067eb00   ( 284 kB)
> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [    0.000000] Preemptible hierarchical RCU implementation.
> [    0.000000]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
> [    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
> [    0.000000] NR_IRQS:16 nr_irqs:16 16
> [    0.000000] GIC physical location is 0x10481000
> [    0.000000] Kernel panic - not syncing: failed to find exynos pmu
> register
> [    0.000000]
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc6+ #2
> [    0.000000] [<c0022214>] (unwind_backtrace) from [<c001f3b4>]
> (show_stack+0x10/0x14)
> [    0.000000] [<c001f3b4>] (show_stack) from [<c04204d4>]
> (dump_stack+0x80/0xc0)
> [    0.000000] [<c04204d4>] (dump_stack) from [<c041d9a4>]
> (panic+0xa4/0x200)
> [    0.000000] [<c041d9a4>] (panic) from [<c05b745c>]
> (exynos_reserve+0x0/0x4c)
> [    0.000000] [<c05b745c>] (exynos_reserve) from [<00000000>] (  (null))
> [    0.000000] ---[ end Kernel panic - not syncing: failed to find
> exynos pmu register
> [    0.000000]
> 
> Reverting "ARM: EXYNOS: Refactored code for using PMU address via DT"
> and "ARM: EXYNOS: Add support for mapping PMU base address via DT" fixed
> the latter.

Adding a "samsung,exynos5410-pmu" system-controller node like on 5420
fixes this as well. Patchset being prepared.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: kgene's for-next branch broken, and boot regressions

[Andreas Färber]

Am 27.07.2014 07:57, schrieb Andreas Färber:
> Am 27.07.2014 05:08, schrieb Andreas Färber:
>> On the ODROID-XU (with local patches based on smdk5410) I get the
>> following with earlyprintk:
>>
[...]
>> [    0.000000] Kernel panic - not syncing: failed to find exynos pmu
>> register
[...]
>>
>> Reverting "ARM: EXYNOS: Refactored code for using PMU address via DT"
>> and "ARM: EXYNOS: Add support for mapping PMU base address via DT" fixed
>> the latter.
> 
> Adding a "samsung,exynos5410-pmu" system-controller node like on 5420
> fixes this as well. Patchset being prepared.

http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34686.html

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: kgene's for-next branch broken, and boot regressions

[Andreas Färber]

Am 27.07.2014 05:08, schrieb Andreas Färber:
> On the Arndale Octa (5420) I see an asynchronous external abort on
> serial console when systemd gets started.
> 
> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34680.html

This turned out to be somehow caused by MCPM driver. Disabling MCPM and
ARM_BIG_LITTLE_CPUIDLE worked around it.

> On the Spring Chromebook (5250) the screen goes dark after a few lines,
> and USB is not initialized. Thus unclear to me why.

Using boot_delay=1000 I tracked this down to the DRM initialization.
Reverting the previously working DRM bridge series v4 and commenting out
spring's dp-controller node worked around this.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

RE: kgene's for-next branch broken, and boot regressions

[Kukjin Kim]

Andreas Färber wrote:
> 
> Hi Kukjin,
> 
Hi,

> Are you aware that `make dtbs` fails on your for-next branch (4533046)?
> 
>   DTC     arch/arm/boot/dts/exynos5420-peach-pit.dtb
> arch/arm/boot/dts/exynos5420-peach-pit.dts:447:33: fatal error:
> cros-ec-keyboard.dtsi: No such file or directory
>  #include "cros-ec-keyboard.dtsi"
>                                  ^
> compilation terminated.
> scripts/Makefile.lib:273: recipe for target
> 'arch/arm/boot/dts/exynos5420-peach-pit.dtb' failed
> make[1]: *** [arch/arm/boot/dts/exynos5420-peach-pit.dtb] Error 1
> arch/arm/Makefile:314: recipe for target 'dtbs' failed
> make: *** [dtbs] Error 2
> 
Oops, I always use my script to check kernel build like follow...

$ mt
building exynos_defconfig done
building s3c2410_defconfig done
building s3c6400_defconfig done
building s5pv210_defconfig done

but seems it couldn't detect the breakage from dtb :(

> On https://patchwork.kernel.org/patch/4297431/ Doug had pointed out that
> a topic branch merge would be needed for cros-ec-keyboard.dtsi (which I
> also pointed out for my spring series). Can you please fix this through
> some merge? Your affected branch is v3.17-next/dt-samsung with "ARM:
> dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi".
> There's a topic branch in the Tegra tree:
> http://git.kernel.org/cgit/linux/kernel/git/tegra/linux.git/log/?h=for-3.17/dt-cros-ec-kbd
> and it's been merged into arm-soc recently.
> https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/tree/arch/arm/boot/dts?h=for-next
> 
Sure I'll fix it soon. Thanks for your report.

- Kukjin

> 
> Also, I've run into some boot regressions:
> 
> On the Arndale Octa (5420) I see an asynchronous external abort on
> serial console when systemd gets started.
> 
> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34680.html
> 
> On the Spring Chromebook (5250) the screen goes dark after a few lines,
> and USB is not initialized. Thus unclear to me why.
> 
> On the ODROID-XU (with local patches based on smdk5410) I get the
> following with earlyprintk:
> 
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 3.16.0-rc6+ (andreas@droide) (gcc version
> 4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #2 SMP
> PREEMPT Sun Jul 27 02:31:31 CEST 2014
> [    0.000000] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7),
> cr=30c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
> cache
> [    0.000000] Machine model: ODROID-XU based on EXYNOS5410
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] Forcing write-allocate cache policy for SMP
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] Running under secure firmware.
> [    0.000000] PERCPU: Embedded 7 pages/cpu @ee7b3000 s7872 r8192 d12608
> u32768
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 522256
> [    0.000000] Kernel command line: console=ttySAC2,115200n8 earlyprintk
> root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait
> [    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
> bytes)
> [    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
> bytes)
> [    0.000000] Memory: 2070984K/2095104K available (4364K kernel code,
> 271K rwdata, 1420K rodata, 271K init, 283K bss, 24120K reserved,
> 1316864K highmem)
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
> [    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc05ae384   (5785 kB)
> [    0.000000]       .init : 0xc05af000 - 0xc05f2ec0   ( 272 kB)
> [    0.000000]       .data : 0xc05f4000 - 0xc0637d80   ( 272 kB)
> [    0.000000]        .bss : 0xc0637d8c - 0xc067eb00   ( 284 kB)
> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [    0.000000] Preemptible hierarchical RCU implementation.
> [    0.000000]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
> [    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
> [    0.000000] NR_IRQS:16 nr_irqs:16 16
> [    0.000000] GIC physical location is 0x10481000
> [    0.000000] Kernel panic - not syncing: failed to find exynos pmu
> register
> [    0.000000]
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc6+ #2
> [    0.000000] [<c0022214>] (unwind_backtrace) from [<c001f3b4>]
> (show_stack+0x10/0x14)
> [    0.000000] [<c001f3b4>] (show_stack) from [<c04204d4>]
> (dump_stack+0x80/0xc0)
> [    0.000000] [<c04204d4>] (dump_stack) from [<c041d9a4>]
> (panic+0xa4/0x200)
> [    0.000000] [<c041d9a4>] (panic) from [<c05b745c>]
> (exynos_reserve+0x0/0x4c)
> [    0.000000] [<c05b745c>] (exynos_reserve) from [<00000000>] (  (null))
> [    0.000000] ---[ end Kernel panic - not syncing: failed to find
> exynos pmu register
> [    0.000000]
> 
> Reverting "ARM: EXYNOS: Refactored code for using PMU address via DT"
> and "ARM: EXYNOS: Add support for mapping PMU base address via DT" fixed
> the latter.
> 
> Anyone know what might cause the others and how to fix?
> 
Hmm...I didn't look at that yet sorry...

- Kukjin

RE: kgene's for-next branch broken, and boot regressions

[Kukjin Kim]

Andreas Färber wrote:
> 
> Am 27.07.2014 05:08, schrieb Andreas Färber:
> > On the ODROID-XU (with local patches based on smdk5410) I get the
> > following with earlyprintk:
> >
> > Uncompressing Linux... done, booting the kernel.
> > [    0.000000] Booting Linux on physical CPU 0x0
> > [    0.000000] Linux version 3.16.0-rc6+ (andreas@droide) (gcc version
> > 4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #2 SMP
> > PREEMPT Sun Jul 27 02:31:31 CEST 2014
> > [    0.000000] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7),
> > cr=30c5387d
> > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
> > cache
> > [    0.000000] Machine model: ODROID-XU based on EXYNOS5410
> > [    0.000000] bootconsole [earlycon0] enabled
> > [    0.000000] Forcing write-allocate cache policy for SMP
> > [    0.000000] Memory policy: Data cache writealloc
> > [    0.000000] Running under secure firmware.
> > [    0.000000] PERCPU: Embedded 7 pages/cpu @ee7b3000 s7872 r8192 d12608
> > u32768
> > [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> > Total pages: 522256
> > [    0.000000] Kernel command line: console=ttySAC2,115200n8 earlyprintk
> > root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait
> > [    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
> > [    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
> > bytes)
> > [    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
> > bytes)
> > [    0.000000] Memory: 2070984K/2095104K available (4364K kernel code,
> > 271K rwdata, 1420K rodata, 271K init, 283K bss, 24120K reserved,
> > 1316864K highmem)
> > [    0.000000] Virtual kernel memory layout:
> > [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> > [    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
> > [    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
> > [    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
> > [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> > [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> > [    0.000000]       .text : 0xc0008000 - 0xc05ae384   (5785 kB)
> > [    0.000000]       .init : 0xc05af000 - 0xc05f2ec0   ( 272 kB)
> > [    0.000000]       .data : 0xc05f4000 - 0xc0637d80   ( 272 kB)
> > [    0.000000]        .bss : 0xc0637d8c - 0xc067eb00   ( 284 kB)
> > [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> > [    0.000000] Preemptible hierarchical RCU implementation.
> > [    0.000000]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
> > [    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
> > [    0.000000] NR_IRQS:16 nr_irqs:16 16
> > [    0.000000] GIC physical location is 0x10481000
> > [    0.000000] Kernel panic - not syncing: failed to find exynos pmu
> > register
> > [    0.000000]
> > [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc6+ #2
> > [    0.000000] [<c0022214>] (unwind_backtrace) from [<c001f3b4>]
> > (show_stack+0x10/0x14)
> > [    0.000000] [<c001f3b4>] (show_stack) from [<c04204d4>]
> > (dump_stack+0x80/0xc0)
> > [    0.000000] [<c04204d4>] (dump_stack) from [<c041d9a4>]
> > (panic+0xa4/0x200)
> > [    0.000000] [<c041d9a4>] (panic) from [<c05b745c>]
> > (exynos_reserve+0x0/0x4c)
> > [    0.000000] [<c05b745c>] (exynos_reserve) from [<00000000>] (  (null))
> > [    0.000000] ---[ end Kernel panic - not syncing: failed to find
> > exynos pmu register
> > [    0.000000]
> >
> > Reverting "ARM: EXYNOS: Refactored code for using PMU address via DT"
> > and "ARM: EXYNOS: Add support for mapping PMU base address via DT" fixed
> > the latter.
> 
> Adding a "samsung,exynos5410-pmu" system-controller node like on 5420
> fixes this as well. Patchset being prepared.
> 
Thanks again ;)

- Kukjin

Re: kgene's for-next branch broken, and boot regressions

[Doug Anderson]

Kukjin,

On Sun, Jul 27, 2014 at 5:30 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Oops, I always use my script to check kernel build like follow...
>
> $ mt
> building exynos_defconfig done
> building s3c2410_defconfig done
> building s3c6400_defconfig done
> building s5pv210_defconfig done
>
> but seems it couldn't detect the breakage from dtb :(

Could you add a "make dtbs" in there?

Is there any chance you could get a boot farm on this, or somehow try
to piggyback on Olof's or Kevin's boot farms (assuming they are
willing to build/boot your branch on relevant hardware)?

-Doug

Re: kgene's for-next branch broken, and boot regressions

[Olof Johansson]

On Sun, Jul 27, 2014 at 8:30 PM, Doug Anderson <dianders@chromium.org> wrote:
> Kukjin,
>
> On Sun, Jul 27, 2014 at 5:30 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>> Oops, I always use my script to check kernel build like follow...
>>
>> $ mt
>> building exynos_defconfig done
>> building s3c2410_defconfig done
>> building s3c6400_defconfig done
>> building s5pv210_defconfig done
>>
>> but seems it couldn't detect the breakage from dtb :(
>
> Could you add a "make dtbs" in there?
>
> Is there any chance you could get a boot farm on this, or somehow try
> to piggyback on Olof's or Kevin's boot farms (assuming they are
> willing to build/boot your branch on relevant hardware)?

I boot -next on the farm, and it had found the 5410 issues, which I
forwarded on to some of the relevant parties (but maybe not all). I
don't have any 5410 hardware so I couldn't bisect the problem and
narrow it down to a single patch. Hardware currently in there is 4412
(ODROID-U3), 5250 (Arndale and Snow), 5420 and 5800 (Pit/Pi). I have a
6410-based board that I have not yet hooked up.

I also boot arm-soc's for-next branch, so as soon as we merge
something in I'll notice breakage, if it's somehow masked by other
parts of linux-next (i.e. dependent but not described driver changes,
etc).


-Olof

Re: kgene's for-next branch broken, and boot regressions

[Olof Johansson]

On Sun, Jul 27, 2014 at 8:44 PM, Olof Johansson <olof@lixom.net> wrote:
> On Sun, Jul 27, 2014 at 8:30 PM, Doug Anderson <dianders@chromium.org> wrote:
>> Kukjin,
>>
>> On Sun, Jul 27, 2014 at 5:30 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>>> Oops, I always use my script to check kernel build like follow...
>>>
>>> $ mt
>>> building exynos_defconfig done
>>> building s3c2410_defconfig done
>>> building s3c6400_defconfig done
>>> building s5pv210_defconfig done
>>>
>>> but seems it couldn't detect the breakage from dtb :(
>>
>> Could you add a "make dtbs" in there?
>>
>> Is there any chance you could get a boot farm on this, or somehow try
>> to piggyback on Olof's or Kevin's boot farms (assuming they are
>> willing to build/boot your branch on relevant hardware)?
>
> I boot -next on the farm, and it had found the 5410 issues, which I
> forwarded on to some of the relevant parties (but maybe not all). I
> don't have any 5410 hardware so I couldn't bisect the problem and
> narrow it down to a single patch.


Obviously those two sentences are contradictory, and it was indeed
Kevin that found the issues with his boards, not me.


-Olof