Automated DT boot report for various ARM defconfigs.
Tree/Branch: queue Git describe: v3.12.17 Failed boot tests (console logs at the end) =========================================== armada-370-mirabox: FAIL: mvebu_defconfig
Full Report ===========
da8xx_omapl_defconfig --------------------- da850-evm 0 min 14.9 sec: PASS legacy,da850evm 0 min 13.8 sec: PASS
omap2plus_defconfig ------------------- legacy,3730xm 0 min 56.8 sec: PASS am335x-boneblack 0 min 25.1 sec: PASS omap3-beagle-xm 1 min 2.4 sec: PASS legacy,3530beagle 0 min 36.0 sec: PASS omap4-panda 1 min 11.5 sec: PASS omap3-tobi 0 min 22.3 sec: PASS am335x-bone 0 min 26.7 sec: PASS omap4-panda-es 1 min 8.5 sec: PASS legacy,3730storm 0 min 24.0 sec: PASS legacy,3530overo 0 min 21.5 sec: PASS
multi_lpae_defconfig -------------------- sun7i-a20-cubieboard2 0 min 13.7 sec: PASS
tegra_defconfig --------------- tegra30-beaver 0 min 17.3 sec: PASS
imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual 0 min 18.0 sec: PASS imx6dl-wandboard,wand-solo 0 min 17.8 sec: PASS imx6q-wandboard 0 min 16.2 sec: PASS
bcm_defconfig ------------- bcm28155-ap 0 min 21.4 sec: PASS
exynos_defconfig ---------------- exynos5250-arndale 0 min 35.3 sec: PASS
multi_v7_defconfig ------------------ tegra30-beaver 0 min 17.0 sec: PASS am335x-boneblack 0 min 32.2 sec: PASS omap3-beagle-xm 0 min 59.4 sec: PASS sun7i-a20-cubieboard2 0 min 13.4 sec: PASS armada-370-mirabox 0 min 20.5 sec: PASS omap4-panda 0 min 59.7 sec: PASS armada-xp-openblocks-ax3-4 0 min 22.7 sec: PASS sun4i-a10-cubieboard 0 min 13.4 sec: PASS bcm28155-ap 0 min 26.0 sec: PASS imx6dl-wandboard,wand-solo 0 min 17.9 sec: PASS omap3-tobi 0 min 20.3 sec: PASS am335x-bone 0 min 34.0 sec: PASS imx6q-wandboard 0 min 17.5 sec: PASS omap4-panda-es 1 min 3.0 sec: PASS imx6dl-wandboard,wand-dual 0 min 17.5 sec: PASS
sama5_defconfig --------------- sama5d35ek 0 min 27.3 sec: PASS
davinci_all_defconfig --------------------- legacy,dm365evm 0 min 16.5 sec: PASS
mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 0 min 22.0 sec: PASS armada-370-mirabox 0 min 47.6 sec: FAIL
Console logs for failures =========================
mvebu_defconfig ---------------
armada-370-mirabox: FAIL: last 80 lines of boot log: ----------------------------------------------------
phy16= 72 phy16= 72 MMC: MRVL_MMC: 0 Net: egiga0 [PRIME], egiga1 Hit any key to stop autoboot: 3 0 Marvell>> Marvell>> version version
U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ Marvell>> setenv bootargs console=ttyS0,115200 debug earlyprintk setenv bootargs console=ttyS0,115200 debug earlyprintk Marvell>setenv initrd_high 0xffffffff
setenv initrd_high 0xffffffff
Marvell>> if test -n ${initenv}; then run initenv; fi if test -n ${initenv}; then run initenv; fi Marvell>> if test -n ${preboot}; then run preboot; fi if test -n ${preboot}; then run preboot; fi Marvell>setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
Marvell>>dhcp dhcp phyaddr= 0 BOOTP broadcast 1 DHCP client bound to address 192.168.1.183 Marvell>> setenv serverip 192.168.1.2 setenv serverip 192.168.1.2 Marvell>>if test -n ${netargs}; then run netargs; fi if test -n ${netargs}; then run netargs; fi Marvell>> tftp 0x02000000 192.168.1.2:tmp/mirabox-wVO2nj/tmp0l2RnB-uImage tftp 0x02000000 192.168.1.2:tmp/mirabox-wVO2nj/tmp0l2RnB-uImage Using egiga0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.183 Filename 'tmp/mirabox-wVO2nj/tmp0l2RnB-uImage'. Load address: 0x2000000 Loading: *################################################################# ################################################################# ################################################### done Bytes transferred = 2654005 (287f35 hex) Marvell>> tftp 0x03000000 192.168.1.2:buildroot.cpio.gz.uboot tftp 0x03000000 192.168.1.2:buildroot.cpio.gz.uboot Using egiga0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.183 Filename 'buildroot.cpio.gz.uboot'. Load address: 0x3000000 Loading: *############################################ done Bytes transferred = 642602 (9ce2a hex) Marvell>> printenv bootargs printenv bootargs bootargs=console=ttyS0,115200 debug earlyprintk Marvell>bootm 0x02000000 0x03000000
bootm 0x02000000 0x03000000
## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux Created: 2014-04-08 5:54:12 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2653941 Bytes = 2.5 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 03000000 ... Image Name: Created: 2014-02-07 19:37:29 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 642538 Bytes = 627.5 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
~$off # PYBOOT: Exception: kernel: ERROR: did not start booting. # PYBOOT: Time: 47.65 seconds. # PYBOOT: Result: FAIL
On Mon, Apr 07, 2014 at 10:55:01PM -0700, Kevin's boot bot wrote:
Automated DT boot report for various ARM defconfigs.
Tree/Branch: queue Git describe: v3.12.17 Failed boot tests (console logs at the end) =========================================== armada-370-mirabox: FAIL: mvebu_defconfig
...
Console logs for failures
mvebu_defconfig
armada-370-mirabox: FAIL: last 80 lines of boot log:
phy16= 72 phy16= 72 MMC: MRVL_MMC: 0 Net: egiga0 [PRIME], egiga1 Hit any key to stop autoboot: 3 0 Marvell>> Marvell>> version version
U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ Marvell>> setenv bootargs console=ttyS0,115200 debug earlyprintk setenv bootargs console=ttyS0,115200 debug earlyprintk Marvell>setenv initrd_high 0xffffffff
setenv initrd_high 0xffffffff
Marvell>> if test -n ${initenv}; then run initenv; fi if test -n ${initenv}; then run initenv; fi Marvell>> if test -n ${preboot}; then run preboot; fi if test -n ${preboot}; then run preboot; fi Marvell>setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
Marvell>>dhcp dhcp phyaddr= 0 BOOTP broadcast 1 DHCP client bound to address 192.168.1.183 Marvell>> setenv serverip 192.168.1.2 setenv serverip 192.168.1.2 Marvell>>if test -n ${netargs}; then run netargs; fi if test -n ${netargs}; then run netargs; fi Marvell>> tftp 0x02000000 192.168.1.2:tmp/mirabox-wVO2nj/tmp0l2RnB-uImage tftp 0x02000000 192.168.1.2:tmp/mirabox-wVO2nj/tmp0l2RnB-uImage Using egiga0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.183 Filename 'tmp/mirabox-wVO2nj/tmp0l2RnB-uImage'. Load address: 0x2000000 Loading: *################################################################# ################################################################# ################################################### done Bytes transferred = 2654005 (287f35 hex) Marvell>> tftp 0x03000000 192.168.1.2:buildroot.cpio.gz.uboot tftp 0x03000000 192.168.1.2:buildroot.cpio.gz.uboot Using egiga0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.183 Filename 'buildroot.cpio.gz.uboot'. Load address: 0x3000000 Loading: *############################################ done Bytes transferred = 642602 (9ce2a hex) Marvell>> printenv bootargs printenv bootargs bootargs=console=ttyS0,115200 debug earlyprintk Marvell>bootm 0x02000000 0x03000000
bootm 0x02000000 0x03000000
## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux Created: 2014-04-08 5:54:12 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2653941 Bytes = 2.5 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 03000000 ... Image Name: Created: 2014-02-07 19:37:29 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 642538 Bytes = 627.5 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
~$off # PYBOOT: Exception: kernel: ERROR: did not start booting. # PYBOOT: Time: 47.65 seconds. # PYBOOT: Result: FAIL
Kevin,
any insight what happened here?
thx,
Jason.
On 04/08/2014 04:54 AM, Jason Cooper wrote:
On Mon, Apr 07, 2014 at 10:55:01PM -0700, Kevin's boot bot wrote:
Automated DT boot report for various ARM defconfigs.
Tree/Branch: queue Git describe: v3.12.17 Failed boot tests (console logs at the end) =========================================== armada-370-mirabox: FAIL: mvebu_defconfig
...
Console logs for failures
mvebu_defconfig
armada-370-mirabox: FAIL: last 80 lines of boot log:
phy16= 72 phy16= 72 MMC: MRVL_MMC: 0 Net: egiga0 [PRIME], egiga1 Hit any key to stop autoboot: 3 0 Marvell>> Marvell>> version version
U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ Marvell>> setenv bootargs console=ttyS0,115200 debug earlyprintk setenv bootargs console=ttyS0,115200 debug earlyprintk Marvell>setenv initrd_high 0xffffffff
setenv initrd_high 0xffffffff
Marvell>> if test -n ${initenv}; then run initenv; fi if test -n ${initenv}; then run initenv; fi Marvell>> if test -n ${preboot}; then run preboot; fi if test -n ${preboot}; then run preboot; fi Marvell>setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
Marvell>>dhcp dhcp phyaddr= 0 BOOTP broadcast 1 DHCP client bound to address 192.168.1.183 Marvell>> setenv serverip 192.168.1.2 setenv serverip 192.168.1.2 Marvell>>if test -n ${netargs}; then run netargs; fi if test -n ${netargs}; then run netargs; fi Marvell>> tftp 0x02000000 192.168.1.2:tmp/mirabox-wVO2nj/tmp0l2RnB-uImage tftp 0x02000000 192.168.1.2:tmp/mirabox-wVO2nj/tmp0l2RnB-uImage Using egiga0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.183 Filename 'tmp/mirabox-wVO2nj/tmp0l2RnB-uImage'. Load address: 0x2000000 Loading: *################################################################# ################################################################# ################################################### done Bytes transferred = 2654005 (287f35 hex) Marvell>> tftp 0x03000000 192.168.1.2:buildroot.cpio.gz.uboot tftp 0x03000000 192.168.1.2:buildroot.cpio.gz.uboot Using egiga0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.183 Filename 'buildroot.cpio.gz.uboot'. Load address: 0x3000000 Loading: *############################################ done Bytes transferred = 642602 (9ce2a hex) Marvell>> printenv bootargs printenv bootargs bootargs=console=ttyS0,115200 debug earlyprintk Marvell>bootm 0x02000000 0x03000000
bootm 0x02000000 0x03000000
## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux Created: 2014-04-08 5:54:12 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2653941 Bytes = 2.5 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 03000000 ... Image Name: Created: 2014-02-07 19:37:29 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 642538 Bytes = 627.5 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
~$off # PYBOOT: Exception: kernel: ERROR: did not start booting. # PYBOOT: Time: 47.65 seconds. # PYBOOT: Result: FAIL
Kevin,
any insight what happened here?
hmm, nope. Looks like it's been failing on v3.12.y since v3.12.10.
After bisecting, the finger is pointing at the commit below[1]. Smells like another patch missing from stable?
Kevin
[1] 710398e3b203763d847a6310a65006bba7205d27 is the first bad commit commit 710398e3b203763d847a6310a65006bba7205d27 Author: Gregory CLEMENT gregory.clement@free-electrons.com Date: Thu Jan 2 15:08:59 2014 +0100
ARM: mvebu: Add support to get the ID and the revision of a SoC
On Tue, Apr 08, 2014 at 07:43:35AM -0700, Kevin Hilman wrote:
On 04/08/2014 04:54 AM, Jason Cooper wrote:
On Mon, Apr 07, 2014 at 10:55:01PM -0700, Kevin's boot bot wrote:
Automated DT boot report for various ARM defconfigs.
Tree/Branch: queue Git describe: v3.12.17 Failed boot tests (console logs at the end) =========================================== armada-370-mirabox: FAIL: mvebu_defconfig
...
Console logs for failures
mvebu_defconfig
armada-370-mirabox: FAIL: last 80 lines of boot log:
phy16= 72 phy16= 72 MMC: MRVL_MMC: 0 Net: egiga0 [PRIME], egiga1 Hit any key to stop autoboot: 3 0 Marvell>> Marvell>> version version
U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ Marvell>> setenv bootargs console=ttyS0,115200 debug earlyprintk setenv bootargs console=ttyS0,115200 debug earlyprintk Marvell>setenv initrd_high 0xffffffff
setenv initrd_high 0xffffffff
Marvell>> if test -n ${initenv}; then run initenv; fi if test -n ${initenv}; then run initenv; fi Marvell>> if test -n ${preboot}; then run preboot; fi if test -n ${preboot}; then run preboot; fi Marvell>setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
Marvell>>dhcp dhcp phyaddr= 0 BOOTP broadcast 1 DHCP client bound to address 192.168.1.183 Marvell>> setenv serverip 192.168.1.2 setenv serverip 192.168.1.2 Marvell>>if test -n ${netargs}; then run netargs; fi if test -n ${netargs}; then run netargs; fi Marvell>> tftp 0x02000000 192.168.1.2:tmp/mirabox-wVO2nj/tmp0l2RnB-uImage tftp 0x02000000 192.168.1.2:tmp/mirabox-wVO2nj/tmp0l2RnB-uImage Using egiga0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.183 Filename 'tmp/mirabox-wVO2nj/tmp0l2RnB-uImage'. Load address: 0x2000000 Loading: *################################################################# ################################################################# ################################################### done Bytes transferred = 2654005 (287f35 hex) Marvell>> tftp 0x03000000 192.168.1.2:buildroot.cpio.gz.uboot tftp 0x03000000 192.168.1.2:buildroot.cpio.gz.uboot Using egiga0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.183 Filename 'buildroot.cpio.gz.uboot'. Load address: 0x3000000 Loading: *############################################ done Bytes transferred = 642602 (9ce2a hex) Marvell>> printenv bootargs printenv bootargs bootargs=console=ttyS0,115200 debug earlyprintk Marvell>bootm 0x02000000 0x03000000
bootm 0x02000000 0x03000000
## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux Created: 2014-04-08 5:54:12 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2653941 Bytes = 2.5 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 03000000 ... Image Name: Created: 2014-02-07 19:37:29 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 642538 Bytes = 627.5 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
~$off # PYBOOT: Exception: kernel: ERROR: did not start booting. # PYBOOT: Time: 47.65 seconds. # PYBOOT: Result: FAIL
Kevin,
any insight what happened here?
hmm, nope. Looks like it's been failing on v3.12.y since v3.12.10.
After bisecting, the finger is pointing at the commit below[1]. Smells like another patch missing from stable?
Kevin
[1] 710398e3b203763d847a6310a65006bba7205d27 is the first bad commit commit 710398e3b203763d847a6310a65006bba7205d27 Author: Gregory CLEMENT gregory.clement@free-electrons.com Date: Thu Jan 2 15:08:59 2014 +0100
ARM: mvebu: Add support to get the ID and the revision of a SoC
Hmm, all the follow-on fixes appear to be in the 3.12.y tree. Also, this code shouldn't get triggered because of:
static void __init mvebu_dt_init(void) { if (of_machine_is_compatible("plathome,openblocks-ax3-4")) i2c_quirk(); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); }
I'll admit, I'm puzzled. Thomas, Gregory?
thx,
Jason.
On Apr 08, Jason Cooper wrote:
hmm, nope. Looks like it's been failing on v3.12.y since v3.12.10.
After bisecting, the finger is pointing at the commit below[1]. Smells like another patch missing from stable?
Kevin
[1] 710398e3b203763d847a6310a65006bba7205d27 is the first bad commit commit 710398e3b203763d847a6310a65006bba7205d27 Author: Gregory CLEMENT gregory.clement@free-electrons.com Date: Thu Jan 2 15:08:59 2014 +0100
ARM: mvebu: Add support to get the ID and the revision of a SoCHmm, all the follow-on fixes appear to be in the 3.12.y tree. Also, this code shouldn't get triggered because of:
static void __init mvebu_dt_init(void) { if (of_machine_is_compatible("plathome,openblocks-ax3-4")) i2c_quirk(); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); }
I'll admit, I'm puzzled. Thomas, Gregory?
Problem is the above commit reported as first bad introduced a bug, so it could be false positive bisection result. Namely, this commit:
ARM: mvebu: Add support to get the ID and the revision of a SoC commit af8d1c63afcbf36eea06789c92e22d4af118d2fb upstream.
introduces a bug which was later fixed here:
ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed commit dc4910d9e93f8cc56b190dd8fc9e789135978216 upstream.
Kevin: Can you test with the HEAD at the fix: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/...
?
If it works, I'd say that's your 'good' bisection starting point, right?
Unless someone has a better idea.
Hi Ezequiel,
On 04/08/2014 12:44 PM, Ezequiel Garcia wrote:
On Apr 08, Jason Cooper wrote:
hmm, nope. Looks like it's been failing on v3.12.y since v3.12.10.
After bisecting, the finger is pointing at the commit below[1]. Smells like another patch missing from stable?
Kevin
[1] 710398e3b203763d847a6310a65006bba7205d27 is the first bad commit commit 710398e3b203763d847a6310a65006bba7205d27 Author: Gregory CLEMENT gregory.clement@free-electrons.com Date: Thu Jan 2 15:08:59 2014 +0100
ARM: mvebu: Add support to get the ID and the revision of a SoCHmm, all the follow-on fixes appear to be in the 3.12.y tree. Also, this code shouldn't get triggered because of:
static void __init mvebu_dt_init(void) { if (of_machine_is_compatible("plathome,openblocks-ax3-4")) i2c_quirk(); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); }
I'll admit, I'm puzzled. Thomas, Gregory?
Problem is the above commit reported as first bad introduced a bug, so it could be false positive bisection result. Namely, this commit:
ARM: mvebu: Add support to get the ID and the revision of a SoC commit af8d1c63afcbf36eea06789c92e22d4af118d2fb upstream.
introduces a bug which was later fixed here:
ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed commit dc4910d9e93f8cc56b190dd8fc9e789135978216 upstream.
Kevin: Can you test with the HEAD at the fix: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/...
?
If it works, I'd say that's your 'good' bisection starting point, right?
That commit doesn't boot either.
Note that this failure is only on mvebu_defconfig, multi_v7_defconfig boots just fine, so that strongly suggests it's a missing defconfig change that's needed in -stable.
ISTR that there was some defconfig change around this time that went into multi_v7_defconfig that was needed in mvebu_defconfig. I don't remember the details, but it' likely that patch that needs a stable backport.
Kevin
On Apr 08, Kevin Hilman wrote:
Hi Ezequiel,
On 04/08/2014 12:44 PM, Ezequiel Garcia wrote:
On Apr 08, Jason Cooper wrote:
hmm, nope. Looks like it's been failing on v3.12.y since v3.12.10.
After bisecting, the finger is pointing at the commit below[1]. Smells like another patch missing from stable?
Kevin
[1] 710398e3b203763d847a6310a65006bba7205d27 is the first bad commit commit 710398e3b203763d847a6310a65006bba7205d27 Author: Gregory CLEMENT gregory.clement@free-electrons.com Date: Thu Jan 2 15:08:59 2014 +0100
ARM: mvebu: Add support to get the ID and the revision of a SoCHmm, all the follow-on fixes appear to be in the 3.12.y tree. Also, this code shouldn't get triggered because of:
static void __init mvebu_dt_init(void) { if (of_machine_is_compatible("plathome,openblocks-ax3-4")) i2c_quirk(); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); }
I'll admit, I'm puzzled. Thomas, Gregory?
Problem is the above commit reported as first bad introduced a bug, so it could be false positive bisection result. Namely, this commit:
ARM: mvebu: Add support to get the ID and the revision of a SoC commit af8d1c63afcbf36eea06789c92e22d4af118d2fb upstream.
introduces a bug which was later fixed here:
ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed commit dc4910d9e93f8cc56b190dd8fc9e789135978216 upstream.
Kevin: Can you test with the HEAD at the fix: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/...
?
If it works, I'd say that's your 'good' bisection starting point, right?
That commit doesn't boot either.
Note that this failure is only on mvebu_defconfig, multi_v7_defconfig boots just fine, so that strongly suggests it's a missing defconfig change that's needed in -stable.
Ah... that is certainly something. Let me take a look and let you know.
On Apr 08, Kevin Hilman wrote:
Hi Ezequiel,
On 04/08/2014 12:44 PM, Ezequiel Garcia wrote:
On Apr 08, Jason Cooper wrote:
hmm, nope. Looks like it's been failing on v3.12.y since v3.12.10.
After bisecting, the finger is pointing at the commit below[1]. Smells like another patch missing from stable?
Kevin
[1] 710398e3b203763d847a6310a65006bba7205d27 is the first bad commit commit 710398e3b203763d847a6310a65006bba7205d27 Author: Gregory CLEMENT gregory.clement@free-electrons.com Date: Thu Jan 2 15:08:59 2014 +0100
ARM: mvebu: Add support to get the ID and the revision of a SoCHmm, all the follow-on fixes appear to be in the 3.12.y tree. Also, this code shouldn't get triggered because of:
static void __init mvebu_dt_init(void) { if (of_machine_is_compatible("plathome,openblocks-ax3-4")) i2c_quirk(); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); }
I'll admit, I'm puzzled. Thomas, Gregory?
Problem is the above commit reported as first bad introduced a bug, so it could be false positive bisection result. Namely, this commit:
ARM: mvebu: Add support to get the ID and the revision of a SoC commit af8d1c63afcbf36eea06789c92e22d4af118d2fb upstream.
introduces a bug which was later fixed here:
ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed commit dc4910d9e93f8cc56b190dd8fc9e789135978216 upstream.
Kevin: Can you test with the HEAD at the fix: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/...
?
If it works, I'd say that's your 'good' bisection starting point, right?
That commit doesn't boot either.
Note that this failure is only on mvebu_defconfig, multi_v7_defconfig boots just fine, so that strongly suggests it's a missing defconfig change that's needed in -stable.
Hm... unfortunately it's not that simple. multi_v7_defconfig does *not* select PCI, while mvebu_defconfig does. And the problem seems to be PCI-related.
Could you try the following patch? It applies on v3.12.17.
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c index 1953c16..0671db9 100644 --- a/drivers/pci/host/pci-mvebu.c +++ b/drivers/pci/host/pci-mvebu.c @@ -830,6 +830,16 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev) if (!of_device_is_available(child)) continue;
+ port->clk = of_clk_get_by_name(child, NULL); + if (IS_ERR(port->clk)) { + dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n", + port->port, port->lane); + iounmap(port->base); + port->haslink = 0; + continue; + } + clk_prepare_enable(port->clk); + port->pcie = pcie;
if (of_property_read_u32(child, "marvell,pcie-port", @@ -886,18 +896,8 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev) port->port, port->lane); }
- port->clk = of_clk_get_by_name(child, NULL); - if (IS_ERR(port->clk)) { - dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n", - port->port, port->lane); - iounmap(port->base); - port->haslink = 0; - continue; - } - port->dn = child;
- clk_prepare_enable(port->clk); spin_lock_init(&port->conf_lock);
mvebu_sw_pci_bridge_init(port);
On Tue, Apr 8, 2014 at 4:37 PM, Ezequiel Garcia ezequiel.garcia@free-electrons.com wrote:
On Apr 08, Kevin Hilman wrote:
Hi Ezequiel,
On 04/08/2014 12:44 PM, Ezequiel Garcia wrote:
On Apr 08, Jason Cooper wrote:
hmm, nope. Looks like it's been failing on v3.12.y since v3.12.10.
After bisecting, the finger is pointing at the commit below[1]. Smells like another patch missing from stable?
Kevin
[1] 710398e3b203763d847a6310a65006bba7205d27 is the first bad commit commit 710398e3b203763d847a6310a65006bba7205d27 Author: Gregory CLEMENT gregory.clement@free-electrons.com Date: Thu Jan 2 15:08:59 2014 +0100
ARM: mvebu: Add support to get the ID and the revision of a SoCHmm, all the follow-on fixes appear to be in the 3.12.y tree. Also, this code shouldn't get triggered because of:
static void __init mvebu_dt_init(void) { if (of_machine_is_compatible("plathome,openblocks-ax3-4")) i2c_quirk(); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); }
I'll admit, I'm puzzled. Thomas, Gregory?
Problem is the above commit reported as first bad introduced a bug, so it could be false positive bisection result. Namely, this commit:
ARM: mvebu: Add support to get the ID and the revision of a SoC commit af8d1c63afcbf36eea06789c92e22d4af118d2fb upstream.
introduces a bug which was later fixed here:
ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed commit dc4910d9e93f8cc56b190dd8fc9e789135978216 upstream.
Kevin: Can you test with the HEAD at the fix: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/...
?
If it works, I'd say that's your 'good' bisection starting point, right?
That commit doesn't boot either.
Note that this failure is only on mvebu_defconfig, multi_v7_defconfig boots just fine, so that strongly suggests it's a missing defconfig change that's needed in -stable.
Hm... unfortunately it's not that simple. multi_v7_defconfig does *not* select PCI, while mvebu_defconfig does. And the problem seems to be PCI-related.
Could you try the following patch? It applies on v3.12.17.
Your patch gets v3.12.17 (mvebu_defconfig) booting again for me on armada-370-mirabox.
Kevin
Ezequiel, Kevin,
On Tue, 8 Apr 2014 20:37:07 -0300, Ezequiel Garcia wrote:
Hm... unfortunately it's not that simple. multi_v7_defconfig does *not* select PCI, while mvebu_defconfig does. And the problem seems to be PCI-related.
Could you try the following patch? It applies on v3.12.17.
Ok, let's try to explain what happened.
As of v3.12, the PCI driver was doing this:
1/ Access some registers 2/ Take + enable the PCIe clock
Obviously, it isn't correct, but it was working, because by default when you boot, the PCIe clock is left enabled by the bootloader, so the above sequence 1/ then 2/ above worked perfectly fine.
However, as of v3.12.10, the following commits were merged:
020043ee82cf6f8b61b76cb90af73818f66e9f60 ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed a4496ba6f8961044812d6362426774c231bbe6df ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board 710398e3b203763d847a6310a65006bba7205d27 ARM: mvebu: Add support to get the ID and the revision of a SoC
These commits add a small piece of code in arch/arm/mach-mvebu/ to implement a SoC identification mechanism. And it happens that on Marvell EBU platforms, the way to retrieve the SoC identifier is by poking into PCIe registers. So what this mvebu-soc-id thing does is:
1/ Take + enable the PCIe clock 2/ Fetch the useful values from PCIe registers to identify the SoC 3/ Disable and drop the PCIe clock
After this is done, the PCIe driver comes and does:
1/ Access some registers => BANG, because the PCIe clock has been disabled by step (3) above. 2/ We never get there :-)
The sequence of (1) and (2) in the PCI driver has already been fixed as of:
b42285f66f871a9898a0e79e2d74bc7e7a101995 PCI: mvebu: move clock enable before register access
This commit needs to be backported to all the stable versions where the mvebu-soc-id patches were backported.
Thomas
Greg,
We found another boot fix that needs to be backported to v3.12.x and above. Please cherry-pick:
b42285f66f87 "PCI: mvebu: move clock enable before register access"
See the below explanation for context.
On Wed, Apr 09, 2014 at 11:51:12AM +0200, Thomas Petazzoni wrote:
Ezequiel, Kevin,
On Tue, 8 Apr 2014 20:37:07 -0300, Ezequiel Garcia wrote:
Hm... unfortunately it's not that simple. multi_v7_defconfig does *not* select PCI, while mvebu_defconfig does. And the problem seems to be PCI-related.
Could you try the following patch? It applies on v3.12.17.
Ok, let's try to explain what happened.
As of v3.12, the PCI driver was doing this:
1/ Access some registers 2/ Take + enable the PCIe clock
Obviously, it isn't correct, but it was working, because by default when you boot, the PCIe clock is left enabled by the bootloader, so the above sequence 1/ then 2/ above worked perfectly fine.
However, as of v3.12.10, the following commits were merged:
020043ee82cf6f8b61b76cb90af73818f66e9f60 ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed a4496ba6f8961044812d6362426774c231bbe6df ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board 710398e3b203763d847a6310a65006bba7205d27 ARM: mvebu: Add support to get the ID and the revision of a SoC
These commits add a small piece of code in arch/arm/mach-mvebu/ to implement a SoC identification mechanism. And it happens that on Marvell EBU platforms, the way to retrieve the SoC identifier is by poking into PCIe registers. So what this mvebu-soc-id thing does is:
1/ Take + enable the PCIe clock 2/ Fetch the useful values from PCIe registers to identify the SoC 3/ Disable and drop the PCIe clock
After this is done, the PCIe driver comes and does:
1/ Access some registers => BANG, because the PCIe clock has been disabled by step (3) above. 2/ We never get there :-)
The sequence of (1) and (2) in the PCI driver has already been fixed as of:
b42285f66f871a9898a0e79e2d74bc7e7a101995 PCI: mvebu: move clock enable before register access
This commit needs to be backported to all the stable versions where the mvebu-soc-id patches were backported.
Thanks for the great explanation, Thomas!
thx,
Jason.
On Wed, Apr 09, 2014 at 07:17:20AM -0400, Jason Cooper wrote:
Greg,
We found another boot fix that needs to be backported to v3.12.x and above. Please cherry-pick:
b42285f66f87 "PCI: mvebu: move clock enable before register access"
Looks like it's only relevant for 3.12, which I'm not doing anymore, Jiri is...
thanks,
greg k-h
On 04/11/2014 05:55 PM, Greg KH wrote:
On Wed, Apr 09, 2014 at 07:17:20AM -0400, Jason Cooper wrote:
Greg,
We found another boot fix that needs to be backported to v3.12.x and above. Please cherry-pick:
b42285f66f87 "PCI: mvebu: move clock enable before register access"
Looks like it's only relevant for 3.12, which I'm not doing anymore, Jiri is...
The patch has been added right now.
thanks,
kernel-build-reports@lists.linaro.org
-
Ezequiel Garcia -
Greg KH -
Jason Cooper -
Jiri Slaby -
Kevin Hilman -
Kevin's boot bot
-
Thomas Petazzoni