[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090911200922.GF8137@elf.ucw.cz>
Date: Fri, 11 Sep 2009 22:09:23 +0200
From: Pavel Machek <pavel@....cz>
To: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc: Zdenek Kabelac <zdenek.kabelac@...il.com>,
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
> 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?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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