> 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? I see. This patch need to be modified to change the log level. > > Kind regards > Uffe B&R Hongjie
