On Thu, Jun 19, 2014 at 5:28 AM, Russell King - ARM Linux
[off-list ref] wrote:

On Mon, Jun 16, 2014 at 02:17:30PM +0200, Ulf Hansson wrote:

quoted

Anyway, we did get some folks to test the patches and was thus fairly
confident that we could merge them. Chris asked me to try to collect
them in a PR for him, so I did. Sorry if I managed to screw some
things up, there were several conflicts and actual regressions, which
I tried to take care of.

The mmc people were also very helping in sending patches to fixup
related regressions, immediately after we merged your patchset. Thus
together I think we managed to pull it off.

I tend to look through slightly less rose-tinted glasses.

The fact is... there's loads of ARM platforms which now fail in Olof's
build/boot testing, and they all seem to have a very similar pattern:

hummingboard:
[    1.149688] sdhci: Secure Digital Host Controller Interface driver
[    1.155901] sdhci: Copyright(c) Pierre Ossman
...
[    1.253630] Waiting for root device /dev/mmcblk0p2...
[   60.325469] imx-sdma 20ec000.sdma: firmware not found
~$off
# PYBOOT: Exception: timeout

jetson:
[    2.261355] Waiting for root device /dev/mmcblk0p1...

wandboard:
[    1.186870] sdhci: Secure Digital Host Controller Interface driver
[    1.193075] sdhci: Copyright(c) Pierre Ossman
...
[    1.291064] Waiting for root device /dev/mmcblk0p2...

Whether these are caused by the patch set or not is anyone's guess,
because we (a) don't know what's causing these failures, and (b)
my patch series was never tested on anything but iMX6.

I'm pretty certain that the hummingboard failure is not related to
my series as that's one of the platforms I did test my series on.

There's more failures which look like possibly something in core MMC is
rather screwed, as OMAP5 (which doesn't use SDHCI) is also failing at
a similar point.

What these failures /do/ mean is that when I'm pushing my ARM for-next
branch out, Olof's builder picks it up and runs a build across it, and
the report returns a whole load of failures.  A whole load of failures
means that those platforms haven't tested my changes, which means the
quality of testing is much lower than it should be.

With 26 passing and 15 failing, that's over 1/3 of platforms failing,
which means 1/3 aren't getting tested.

This level of failure has been going on for quite a while now, and (afaik)
it remains uninvestigated and undiagnosed.  (This is one of the complaints
I have about Olof's build/boot test system, much of the information about
the build and boot is hidden away and unpublished, which makes it almost
impossible for third parties to diagnose any problem there.  I've given up
looking at most of Olof's build/boot mails because of this - it's just
not interesting to see the same abbreviated boot failure logs which give
no useful information time and time again.)

Most of this is because I want to avoid sending huuuge emails out with
the failures. I'll add a push of the full log to arm-soc.lixom.net and
include a link to it in the emails, similar to how I do the build
logs. I'll let you know when I've made that change.


-Olof