On Tue, Apr 8, 2014 at 9:53 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Tue, Apr 08, 2014 at 09:12:44AM -0700, Kevin Hilman wrote:
Hi Russell,
On Mon, Apr 7, 2014 at 7:25 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Mon, Apr 07, 2014 at 07:15:34AM -0700, Olof Johansson wrote:
On Mon, Apr 7, 2014 at 2:10 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Sun, Apr 06, 2014 at 11:12:51PM -0700, Olof's autobooter wrote:
Failed boards:
cubie multi_v7_defconfig : FAILED 1:05.77 cubie2 sunxi_defconfig : FAILED 1:21.41 cubie2 multi_v7_defconfig : FAILED 1:09.94 cubie2 multi_lpae_defconfig : FAILED 0:59.68 hummingboard multi_v7_defconfig : FAILED 1:04.69 panda multi_v7_defconfig : FAILED 1:36.35 snow exynos_defconfig : FAILED 2:24.53 snowball multi_v7_defconfig : FAILED 1:07.90 wandboard multi_v7_defconfig : FAILED 1:05.66So do we have any clues what's causing these to fail?
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since we've already requested the patch to be sent to the patch tracker...
I haven't applied anything from the patch system for the last month or more as I've been soo bogged down with the l2c and fec changes.
The multi_v7_defconfig change that triggers the PJ4 enable (and thus some boot failures[1]) is now in mainline. The fixes for this are in the patch tracker as 8015/1 and 8016/1.
Right, eventually submitted four days *after* the merge window had opened.
Yes, that was very unfortunate. I had asked him several times to get those patches submitted to your patch tracker, but he took a long time.
A good question at this point is what change introduced this regression,
What introduced this regression was enabling MACH_DOVE in multi_v7_defconfig (commit 5c436fbef207e11aeae54ea6c8dfd4c65b2aaac2) since that selects the PJ4 options.
We've had this reverted in arm-soc/for-next while waiting for the patches to make it through your patch tracker, but the pull request with that change has gone out, and now it's in mainline, so we have boot failures in mainline[1]
Right, so rather than checking with me about those *late* submitted patches, arm-soc people decided to go off and do their own thing.
You're right, I should've checked with you on these. You were Cc'd on the PJ4 patches (and even had some comments on them), and since I was requesting Chao to submit them to your patch tracker on the same thread, I assumed you would see them and know they were needed as fixes. I know you're busy, so I should have pinged you on those fixes.
and why did that change go through a different tree to that which is being asked to carry the fixes?
The original change was a multi_v7_defconfig change which we've been handling through arm-soc. The fix is a core CPU identification change that typically goes through you.
Right. If we're doing the strict file ownership thing, then this is what _should_ have happened, because there's a strict dependency between these two changes:
- the fixes for the PJ4B needed to be merged into a branch in my tree
- _then_ that branch cross-merged into arm-soc
- _then_ the offending arm-soc change should have been committed on top of that.
That means whoever merges first, the outcome is the same, and avoids any kind of build breakage.
Agreed, That makes sense for build breakage.
The problem here though is actually boot breakage. We could do the same thing, but for boot breakage, it's just fine (IMO) that patches take separate paths, as long as they arrive around the same time.
If that didn't happen (it didn't) then with strict file ownership, arm-soc can't take the offending change. arm-soc shouldn't just stuff it into the mainline kernel anyway.
I think our (mistaken) assumption was that since the patches landed in your tracker, they would be applied soon since I assumed you were aware of the need for them. Our pull request wen out 3 days after the patches landed in your tracker, but I should've pinged you to confirm when they would be applied/submitted.
I will merge these two patches today. However, I'm *not* changing my plans as for pull requests to Linus for.
Thanks, I don't expect you to change your pull request plans.
We _could_ of course all calm down, and realise that there will always be cases where patches for "files under our control" to go through different trees from time to time, and just deal with it as we have done in the past
That is what I'm trying to do now.
I acknowledge it would've worked better if I had been checking with you on those patches before we sent our pull request. Sorry about that.
Kevin