On Sat, Oct 17, 2015 at 8:19 AM, Rob Herring <robh+dt@xxxxxxxxxx> wrote: > On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson <olof@xxxxxxxxx> wrote: >> Hi, >> >> I've bisected boot failures in next-20151016 down to patches in this branch: >> >> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso >> <tomeu.vizoso@xxxxxxxxxxxxx> wrote: >>> Tomeu Vizoso (20): >>> driver core: handle -EPROBE_DEFER from bus_type.match() >> >> The machine it happened on was OMAP5UEVM: >> >> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html > > So this one is because the MMC node numbering changed. I don't know > how to fix that other than with aliases, but that doesn't solve > backwards compatibility. Yep, aliases will take care of it in this case. This is where -next fills a great purpose, we can make sure we get those aliases added in before the patches go in. >> But I've also seen it on tegra2, that one bisected down to: >> >>> regulator: core: Probe regulators on demand >> >> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html > > This one you need a rootwait I think. The MMC scanning is not > guaranteed to be done before the rootfs mounting AFAIK. There may be > other problems, but we can't see them since it panics. Embarrassing, I almost always do this and I'm surprised this machine has been this stable without it. -Olof -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
