On Wed, 27 Feb 2019 at 15:49, Fang Hongjie(方洪杰) <hongjiefang@xxxxxxxxxxxx> wrote: > > > > > > On Thu, 21 Feb 2019 at 08:16, hongjiefang <hongjiefang@xxxxxxxxxxxx> > > wrote: > > > > > > > > > > when failed to verify the cid, the card initialisation will abort. > > > > > it is necessary to print some logs for this critical error. > > > > > > > > Under what circumstances do you observe this error? Is it during > > > > system resume or during runtime resume? > > > > > > > > Moreover, to get this error, I guess you are remove one card and > > > > replacing it with another, right? > > > > > > It happened when the system resume a non-removable eMMC card > > > from deep suspend. > > > > > > > Just wanted to be sure of what kind of scenario you are > > > > testing/looking at. Perhaps you could even fold in some of that > > > > information in the changelog, that would be nice. > > > > > > During the eMMC resume stage, CMD2 returned an error CID value > > > but without any error INT status. > > > The error CID values are as follow 15010044, 4436384d, 4202c2c0, ff808000. > > > The correct value should be 15010044, 4436384d, 4202c2d8, dc2f9400. > > > "c0ff8080" is the response from CMD1. > > > > I see, that is indeed a weird error case. There is for sure a more > > serious bug somewhere to look for. > > > > I guess a overwriting the memory containing the response data, > > somewhere from the host driver up until here is the is what one should > > be looking for in the at first place. > > > > Of course, another option is that the eMMC is internally behaving > > in-correct, but then you need to have the debug equipment to be able > > to listen and decode the bits transferred on the physical lines. > > > > > > > > This problem occasionally occurred when system resume from suspend status. > > > Maybe it happened because there is something wrong about bus clock or our > > host > > > when system do resume. It needs further debugging. > > > > I see, but in such case, there should be an error printed in > > mmc_bus_resume(), along the lines of "...card was removed?"... > > > > Isn't that sufficient? > > There is an error log " mmc0: error -2 doing runtime resume". > But there's no clear indication of where went wrong. > This patch wants to give a clear hint. It should be better. Well, the point is, that it may not be an error for some cases. If you remove the card in suspended state and then insert a new one, then when resume, the check detects that it's not the old card, thus we removes the old card and re-detect the new once. Perhaps printing a message on debug level seems more appropriate, does that work for you? Kind regards Uffe
