Re: Unstable mmc operation on armada38x

[Tor Krill <tor@openproducts.com>]

Hi Uffe,

Thank you for your reply!

On mån, 2016-05-02 at 10:59 +0200, Ulf Hansson wrote:
> On 29 April 2016 at 13:48, Tor Krill <tor@openproducts.com> wrote:
> > Hi,
> > 
> > I work on a custom setup using the Solid-run ClearFog Pro that uses
> > the
> > Marvell 88F6828. I use this with a SOM that is equipped with on
> > board
> > eMMC.
> > 
> > When using the provided Marvell based kernel fork operation works
> > nicely.
> > 
> > But when i however try using either stable kernel.org, i.e. 4.5.2,
> > or
> > the latest mmc-next the system malfunctions on the mmc-operation
> > resulting in the root-filesystem remount read only and the system
> > becomes unusable. (I still use the Marvell/Solid-run u-boot to boot
> > the
> > board)
> > 
> > When doing this i get:
> > 
> > mmcblk0: error -110 sending status command, retrying
> > mmcblk0: error -110 sending status command, retrying
> > mmcblk0: error -110 sending status command, aborting
> > 
> > Thus it seems like the mmc doesn't answer the status request?
> > 
> > I have tried debug this further by enable debug on sdhci-pxav3 and
> > mmc_core. When doing so i unfortunately can't reproduce the
> > problem. I
> > do log on a slow serial port which might be the reason for
> > affecting
> > operation since i get a lot of debug messages when doing this.
> 
> We recently added mmc specific TRACE support to the MMC core. That
> allows you to trace each command/request being send to the card, if
> you don't want to affect the timing etc. I suggest you give it a try.

Thank you for that pointer. I now at least can get some capture on what
is happening. (Unfortunately i'm no expert on sd/mmc protocol)

I have created a new paste with an excerpt of the end off my
transaction:

http://pastebin.com/R32MsLyh

If i interpret it somewhat it seems like it does a write and then try
poll status of the device, which then does not respond (at all?).

> You could also try a bisect, as it seems like it might be a
> regression
> and can thus help to pin-point at what commit it broke.

This would be ideal, but since i have two different source trees,
kernel.org and Marvell/SolidRuns bsp that would be difficult. I will
try testing some of the earlier kernel.org kernels that have support
for this platform and se if i can find anything that works and then
bisect from that.

> On the other hand, the problem seems timing related, so it might be
> that the problem been around for a while but was just triggered by an
> unrelated change.

I agree, it somehow seems timing related. The big question here would
then be why it fails three times with the status request? Could it be
that the controller or mmc-chip somehow have "given up"?

Best Regards,

/Tor