On Friday 18 September 2009, OGAWA Hirofumi wrote:
> "Rafael J. Wysocki" writes:
>
> > On Saturday 12 September 2009, Chris Ball wrote:
> >> Hi,
> >>
> >>> Well system could check basic card ids if they match after resume
> >>
> >> No. That (arguably) guarantees that it's the same card, bu
"Rafael J. Wysocki" writes:
> On Saturday 12 September 2009, Chris Ball wrote:
>> Hi,
>>
>>> Well system could check basic card ids if they match after resume
>>
>> No. That (arguably) guarantees that it's the same card, but not that
>> it wasn't modified in another machine during the susp
On Mon 2009-09-14 10:39:44, Zdenek Kabelac wrote:
> 2009/9/12 Rafael J. Wysocki :
> > On Saturday 12 September 2009, Chris Ball wrote:
> >> Hi,
> >>
> >> > Well system could check basic card ids if they match after resume
> >>
> >> No. That (arguably) guarantees that it's the same card, but not
On Mon 2009-09-14 22:05:10, Pierre Ossman wrote:
> On Fri, 11 Sep 2009 23:51:17 +0200
> Pavel Machek wrote:
>
> > On Fri 2009-09-11 23:45:01, Zdenek Kabelac wrote:
> > >
> > > Well system could check basic card ids if they match after resume - if
> > > some users wants to crash his card by rando
On Fri, 11 Sep 2009 23:51:17 +0200
Pavel Machek wrote:
> On Fri 2009-09-11 23:45:01, Zdenek Kabelac wrote:
> >
> > Well system could check basic card ids if they match after resume - if
> > some users wants to crash his card by randomly swapping it during
> > suspend/resume - I'd have no problem
On Monday 14 September 2009, Zdenek Kabelac wrote:
> 2009/9/12 Rafael J. Wysocki :
> > On Saturday 12 September 2009, Chris Ball wrote:
> >> Hi,
> >>
> >>> Well system could check basic card ids if they match after resume
> >>
> >> No. That (arguably) guarantees that it's the same card, but no
2009/9/12 Rafael J. Wysocki :
> On Saturday 12 September 2009, Chris Ball wrote:
>> Hi,
>>
>> > Well system could check basic card ids if they match after resume
>>
>> No. That (arguably) guarantees that it's the same card, but not that
>> it wasn't modified in another machine during the suspen
On Saturday 12 September 2009, Chris Ball wrote:
> Hi,
>
>> Well system could check basic card ids if they match after resume
>
> No. That (arguably) guarantees that it's the same card, but not that
> it wasn't modified in another machine during the suspend.
Generally speaking, we'd also ne
Hi,
> Well system could check basic card ids if they match after resume
No. That (arguably) guarantees that it's the same card, but not that
it wasn't modified in another machine during the suspend.
> if some users wants to crash his card by randomly swapping it
> during suspend/resume
On Saturday 12 September 2009, Pavel Machek wrote:
> On Sat 2009-09-12 00:04:02, Rafael J. Wysocki wrote:
> > On Friday 11 September 2009, OGAWA Hirofumi wrote:
> > > Pavel Machek writes:
> > >
> > > > On Wed 2009-09-09 22:21:56, OGAWA Hirofumi wrote:
> > > >> Pavel Machek writes:
> > > >>
> >
Hi,
> 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.
How can the MMC stack tell whether you kept the card inside or
modified it during suspend?
Ther
On Sat 2009-09-12 00:04:02, Rafael J. Wysocki wrote:
> On Friday 11 September 2009, OGAWA Hirofumi wrote:
> > Pavel Machek writes:
> >
> > > On Wed 2009-09-09 22:21:56, OGAWA Hirofumi wrote:
> > >> Pavel Machek writes:
> > >>
> > >> >> It seems
> > >> >>
> > >> >> 1) sync() (probabry "sync
On Friday 11 September 2009, Pavel Machek wrote:
> On Fri 2009-09-11 23:45:01, Zdenek Kabelac wrote:
> > 2009/9/11 Pavel Machek :
> > >
> > >> And why suspend of mmc should generate card removal ??
> > >
> > > Card is powered down during suspend -> mmc can't guarantee the card is
> > > same and unc
On Friday 11 September 2009, OGAWA Hirofumi wrote:
> Pavel Machek writes:
>
> > On Wed 2009-09-09 22:21:56, OGAWA Hirofumi wrote:
> >> Pavel Machek writes:
> >>
> >> >> It seems
> >> >>
> >> >> 1) sync() (probabry "sync" command)
> >> >> 2) sync as part of suspend sequence
> >> >>
On Fri 2009-09-11 23:45:01, Zdenek Kabelac wrote:
> 2009/9/11 Pavel Machek :
> >
> >> And why suspend of mmc should generate card removal ??
> >
> > Card is powered down during suspend -> mmc can't guarantee the card is
> > same and unchanged -> it makes some sense to simulate
> > removal/reinsert.
2009/9/11 Pavel Machek :
>
>> And why suspend of mmc should generate card removal ??
>
> Card is powered down during suspend -> mmc can't guarantee the card is
> same and unchanged -> it makes some sense to simulate
> removal/reinsert.
But how is this going to work when I keep the device mounted a
> And why suspend of mmc should generate card removal ??
Card is powered down during suspend -> mmc can't guarantee the card is
same and unchanged -> it makes some sense to simulate
removal/reinsert.
> if I suspend and resume my laptop and I keep the card inside - all
> those step looks plain wr
2009/9/11 Pavel Machek :
>
>> 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 backtrac
> 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
>
Pavel Machek writes:
> On Wed 2009-09-09 22:21:56, OGAWA Hirofumi wrote:
>> Pavel Machek writes:
>>
>> >> It seems
>> >>
>> >> 1) sync() (probabry "sync" command)
>> >> 2) sync as part of suspend sequence
>> >> 3) sync_filesystem() by mmc remove event
>> >>
>> >> I guess the root-
On Wed 2009-09-09 22:21:56, OGAWA Hirofumi wrote:
> Pavel Machek writes:
>
> >> It seems
> >>
> >> 1) sync() (probabry "sync" command)
> >> 2) sync as part of suspend sequence
> >> 3) sync_filesystem() by mmc remove event
> >>
> >> I guess the root-cause of the problem would be 3).
Christoph Hellwig writes:
> On Fri, Sep 04, 2009 at 09:47:46AM +0900, OGAWA Hirofumi wrote:
>> Well, that commit seems a bit strange. It calls fat_clusters_flush()
>> unconditionally without checking sb->s_dirt. However, if my guess is
>> right, "sync after removed event" itself sounds like the i
Pavel Machek writes:
>> It seems
>>
>> 1) sync() (probabry "sync" command)
>> 2) sync as part of suspend sequence
>> 3) sync_filesystem() by mmc remove event
>>
>> I guess the root-cause of the problem would be 3). However, it would not
>> be easy to fix, at least, we would need to
Zdenek Kabelac writes:
> Just a side note - Could be there any connection with my previous report?
>
> http://lkml.org/lkml/2009/8/28/90
As far as I can see, it doesn't seem related problem to this. It seems
mmc's driver problem (or problem of unusual device).
Thanks.
--
OGAWA Hirofumi
--
To
On Tuesday 08 September 2009, Christoph Hellwig wrote:
> On Fri, Sep 04, 2009 at 09:47:46AM +0900, OGAWA Hirofumi wrote:
> > Well, that commit seems a bit strange. It calls fat_clusters_flush()
> > unconditionally without checking sb->s_dirt. However, if my guess is
> > right, "sync after removed e
On Fri, Sep 04, 2009 at 09:47:46AM +0900, OGAWA Hirofumi wrote:
> Well, that commit seems a bit strange. It calls fat_clusters_flush()
> unconditionally without checking sb->s_dirt. However, if my guess is
> right, "sync after removed event" itself sounds like the issue in
> suspend process.
The i
2009/9/6 OGAWA Hirofumi :
> Zdenek Kabelac writes:
>
>> 2009/9/5 OGAWA Hirofumi :
>>> Zdenek Kabelac writes:
>>>
2009/9/4 OGAWA Hirofumi :
> Christoph Hellwig writes:
>
>> Note that when you rever this patch on a current kernel you do actually
>> get different behvaviour tha
Hi!
> >>> Note that when you rever this patch on a current kernel you do actually
> >>> get different behvaviour than when going back to before this commit.
> >>>
> >>> In 2.6.30 we called ->write_super in the various sync functions and
> >>> then ->sync_fs, in 2.6.31-rc8 you would not call any sy
Zdenek Kabelac writes:
> 2009/9/5 OGAWA Hirofumi :
>> Zdenek Kabelac writes:
>>
>>> 2009/9/4 OGAWA Hirofumi :
Christoph Hellwig writes:
> Note that when you rever this patch on a current kernel you do actually
> get different behvaviour than when going back to before this comm
2009/9/5 OGAWA Hirofumi :
> Zdenek Kabelac writes:
>
>> 2009/9/4 OGAWA Hirofumi :
>>> Christoph Hellwig writes:
>>>
Note that when you rever this patch on a current kernel you do actually
get different behvaviour than when going back to before this commit.
In 2.6.30 we called
Zdenek Kabelac writes:
> 2009/9/4 OGAWA Hirofumi :
>> Christoph Hellwig writes:
>>
>>> Note that when you rever this patch on a current kernel you do actually
>>> get different behvaviour than when going back to before this commit.
>>>
>>> In 2.6.30 we called ->write_super in the various sync fu
2009/9/4 OGAWA Hirofumi :
> Christoph Hellwig writes:
>
>> On Fri, Sep 04, 2009 at 12:29:04AM +0200, Zdenek Kabelac wrote:
>>> Ok - another bisect game played - and unexpected winner is:
>>>
>>> (fat: add ->sync_fs)
>>>
>>> f83d6d46e7adf241a064a4a425e5cd8a8fd8925f
>>>
>>> Reverting this commit wit
Christoph Hellwig writes:
> On Fri, Sep 04, 2009 at 12:29:04AM +0200, Zdenek Kabelac wrote:
>> Ok - another bisect game played - and unexpected winner is:
>>
>> (fat: add ->sync_fs)
>>
>> f83d6d46e7adf241a064a4a425e5cd8a8fd8925f
>>
>> Reverting this commit with current -rc8 kernel makes the sy
On Fri, Sep 04, 2009 at 12:29:04AM +0200, Zdenek Kabelac wrote:
> Ok - another bisect game played - and unexpected winner is:
>
> (fat: add ->sync_fs)
>
> f83d6d46e7adf241a064a4a425e5cd8a8fd8925f
>
> Reverting this commit with current -rc8 kernel makes the system happy
> during the suspend/resum
2009/9/1 Zdenek Kabelac :
> 2009/8/31 Rafael J. Wysocki :
>> On Monday 31 August 2009, Zdenek Kabelac wrote:
>>> Hi
>>>
>>> I've noticed that my machine freezes while doing s2r and having
>>> mounted filesystem from SD card.
>>>
>>> My system: Lenovo T61, 4GB, C2D, kernel 2.6.31-rc8
>>>
>>> Here is
2009/8/31 Rafael J. Wysocki :
> On Monday 31 August 2009, Zdenek Kabelac wrote:
>> Hi
>>
>> I've noticed that my machine freezes while doing s2r and having
>> mounted filesystem from SD card.
>>
>> My system: Lenovo T61, 4GB, C2D, kernel 2.6.31-rc8
>>
>> Here is the trace of suspend when SD card i
On Monday 31 August 2009, Zdenek Kabelac wrote:
> Hi
>
> I've noticed that my machine freezes while doing s2r and having
> mounted filesystem from SD card.
>
> My system: Lenovo T61, 4GB, C2D, kernel 2.6.31-rc8
>
> Here is the trace of suspend when SD card is inserted, follows resume
> and agai
Hi
I've noticed that my machine freezes while doing s2r and having
mounted filesystem from SD card.
My system: Lenovo T61, 4GB, C2D, kernel 2.6.31-rc8
Here is the trace of suspend when SD card is inserted, follows resume
and again suspend and this time with mounted filesystem from SD card.
Sys
38 matches
Mail list logo
