Android LEB fails to mount system and user partition interminttently

[Mathieu Poirier]

The snowball android LEB (https://android-build.linaro.org/builds/~linaro-android/leb-snowball/) fails to mount the system and data partition when starting up, resulting in a failure to find the binaries required to boot the system.

When booting normally (system and data partition mounted) the mmc0 and mmc1 are discovered, scanned and respective partitions are identified. When the system fails to find the system and data partition, scrolling back the console log one can find that mmc0 and mmc1 are not discovered nor scanned.

This problem is intermittent on some board and reproducible at will on other. The type and speed of the SD card also seems to have an effect.

[Mathieu Poirier (mathieu.poirier-deactivatedaccount)]

Adding two snapshots - working.txt and notworking.txt. It it pretty obvious that in notworking.txt mmc0 and mmc1 aren't scanned, resulting in the failure detailed above. Both snapshots have been taken from the exact same kernel, board, and SD card.

[Zach Pfeffer (pfefferz)]

Hey Anmar, lets sync up about this.

[Philippe Langlais (philang)]

I found the root cause, the problem is that some SD-card are too slow to enumerate their partitions and Snowbal Android boot doesn't verify that mmc partitions are present.
To fix this bug, Android must mount mmc parttions with wait option in Snowball platform init.rc file:

In Snowball Android 3.0 kernel, git://git.linaro.org/bsp/st-ericsson/linux-3.0-android-ux500.git :
   revert commit 2036fd7 "Temporary fix to bypass mmc card discovery problem"

In git://android.git.linaro.org/device/linaro/snowball.git:
  revert d04a69b7 "Temporary fix to bypass mmc card discovery problem"
  and apply attached patch

Mathieu, can you test this fix with your Snowball and different SD-cards

[Mathieu Poirier (mathieu.poirier-deactivatedaccount)]

Introducing the 'wait' option to the mount commands in 'init.rc' resolves the issue when PRCMU v2.2.5 is used but it is still reproducible with PRCMU v3.3.2.

The problem can be approached from two fronts:

1) in the kernel, to understand why it take so long for the sdcard (and sometimes the emmc) to be discovered.
2) in Android, to understand why the 'wait' option supplied to mount doesn't yield the intended purpose with PRCMU v3.3.2.

I will look into the latter.

[Zach Pfeffer (pfefferz)]

Moved out to 11.10 due LT dependency.

[Mathieu Poirier (mathieu.poirier-deactivatedaccount)]

At this point we need help from ST-Ericsson.

[Lee Jones (lag)]

This issue has been escalated to ST-Ericsson.

And now, we wait ...

[Thomas Espersson (espersson)]

Can you please confirm what Snowball HW version, base HW pack (boot binaries) and kernel version (commit) that has been used.

[Mathieu Poirier (mathieu.poirier-deactivatedaccount)]

This problem can be reproduced on V2, V4 and V5 boards running android.

The kernel used for these build can be found here: http://git.linaro.org/git/bsp/st-ericsson/linux-3.0-android-ux500.git, the config file is u8500_snowball_android_defconfig.

The mmc issue can be observed on all the snowball android build that have been release since July, including the latest found here: https://android-build.linaro.org/builds/~linaro-android/landing-snowball/#build=17

The problem is intermittent but much easier to reproduce with Patriot Memory MicroSD cards. I had two of these cards but I sent one to Philippe Langlais. Philippe has been leading the investigation on this issue and has the latest details. Please follow up with him.

[Zach Pfeffer (pfefferz)]

Is this bug seen in the igloo community builds?

[David Zinman (dzinman)]

Unset the milestone since this has not been resolved for many cycles.

[Anmar Oueja (anmar)]

Mathieu: Any update on this issue? We should test it with V11 when they land in our hands.

[Mathieu Poirier (mathieu.poirier-deactivatedaccount)]

Nobody is working on this problem anymore. The solution is to see if the new mmc driver coming with the 3.1 kernel will yield better results.

[Anmar Oueja (anmar)]

I will mark this bug as won't fix since we don't plan on working on it anymore.