[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c4e36d110909111414n716a06b1mdd0cd741230595b5@mail.gmail.com>
Date: Fri, 11 Sep 2009 23:14:08 +0200
From: Zdenek Kabelac <zdenek.kabelac@...il.com>
To: Pavel Machek <pavel@....cz>
Cc: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
Christoph Hellwig <hch@....de>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mmc@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: Regression in suspend to ram in 2.6.31-rc kernels
2009/9/11 Pavel Machek <pavel@....cz>:
>
>> Um..., sorry, I'm not sure what are you talking about. Of course, the
>> problem of this is that system freeze on suspend.
>>
>> Or are you asking my guess of the cause, or something? If so, although
>> I'm not reading all emails on this thread, from Zdenek's backtrace, the
>> sequence would be
>>
>> 1) suspend mmc
>> 2) mmc generates card removed event
>> 3) prepare to invalidate blockdev
>> 4) sync fs on invalidating blockdev
>> 5) flush buffers on invalidating blockdev (partitions)
>> 6) delete blockdev (partitions)
>>
>> or like the above. And I can guess some possible issues/root-cause we
>> have to handle from it.
>>
>> a) card removed event from mmc for suspend is right design?
>> b) the card can be changed/removed before system was resumed, mmc
>> can be detect/handle it properly?
>> c) flushing buffers on _deleted_ device is right design?
>>
>> and I suspect there are more issues in detail and resume process though.
>
> I guess c) is main problem. If device is not there, how do you want to
> flush buffers on it?
>
Well I do not even understand why someone wants to sync something when
card is removed ??
And why suspend of mmc should generate card removal ??
IMHO steps 2..6 are only valid for the case I would 'remove'
unexpectedly card - but
if I suspend and resume my laptop and I keep the card inside - all
those step looks plain wrong.
Zdenek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists