On Wed, 27 Feb 2019 at 15:11, 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? [...] Kind regards Uffe
