On 18 December 2015 at 10:33, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > Hi Dung-san, > > CC Ulf > > On Mon, Dec 14, 2015 at 3:34 AM, Nguyen Viet Dung <nv-dung@xxxxxxxxxxx> wrote: >> While is testting LTSI-v4.1.13-rc1, we have found the following the failure >> of mmcif. >> 1. mount mmc block >> 2. write data to mmc block >> 3. suspend/resume >> 4. write data to mmc block one again => happen kernel panic >> (Probability in this test procedure is 100%) >> >> We have used git bisect to find cause of failure in LTS-v4.1.13 to >> LTSI-v4.1.13-rc1 >> and have found commit which cause failure. >> (On LTS-v4.1.13 has not this failure) >> drivers: sh: Disable PM runtime for multi-platform ARM with genpd >> commit :cbc41d0a761bffb3166a413a3c77100a737c0cd7 > > That means there's a bug in Runtime PM handling of the sh_mmcif driver, or > in the MMC subsystem. > > Usually such bugs cause a kernel hang on register access, not a NULL pointer > dereference, though. Agree! I doubt the bisected commit is where the *real* issue is. Looking into the details for how system PM and runtime PM is deployed in sh_mmcif, I believe some improvements are needed. Actually, I made an attempt to modernize the PM code for sh_mmcif a while ago. http://marc.info/?l=linux-mmc&m=138245085523815&w=2 Whether that fixes the problem reported here, I have no idea. Although if not, it should move the code to a position where it becomes easier to properly fix this issue. I am willing to help and rebase that patchset, but I require help in testing since I haven't been able to get a hold of a HW. Can I count on that? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
