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