Re: [bug] kernel panic if writting data to mmc after suspendding

[Nguyen Viet Dung <nv-dung@jinso.co.jp>]

Hi Geert

Thank for your reply.

On 2015年12月18日 19:27, Ulf Hansson wrote:
> On 18 December 2015 at 10:33, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> Hi Dung-san,
>>
>> CC Ulf
>>
>> On Mon, Dec 14, 2015 at 3:34 AM, Nguyen Viet Dung <nv-dung@jinso.co.jp> 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?
Yes , I can help you test.
If you have rebased patchset, phease tell me.

Best regards,
Nguyen Viet Dung