From mboxrd@z Thu Jan 1 00:00:00 1970 From: OGAWA Hirofumi Subject: Re: Regression in suspend to ram in 2.6.31-rc kernels Date: Sun, 06 Sep 2009 07:42:13 +0900 Message-ID: <873a7157zu.fsf@devron.myhome.or.jp> References: <200908312119.12121.rjw@sisk.pl> <20090903232317.GA6760@lst.de> <87ljkvmt71.fsf@devron.myhome.or.jp> <87iqfx5mss.fsf@devron.myhome.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail.parknet.ad.jp ([210.171.162.6]:53793 "EHLO mail.officemail.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751918AbZIEWmO (ORCPT ); Sat, 5 Sep 2009 18:42:14 -0400 In-Reply-To: (Zdenek Kabelac's message of "Sat, 5 Sep 2009 21:53:49 +0200") Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Zdenek Kabelac Cc: Christoph Hellwig , "Rafael J. Wysocki" , Linux Kernel Mailing List , linux-mmc@vger.kernel.org, viro@zeniv.linux.org.uk 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 ac= tually >>>>> get different behvaviour than when going back to before this comm= it. >>>>> >>>>> In 2.6.30 we called ->write_super in the various sync functions a= nd >>>>> then ->sync_fs, in 2.6.31-rc8 you would not call any syncing at a= ll >>>>> anymore. =A0I think this patch might just be a symptom for a situ= ation >>>>> where the suspend code causes a sync and the mmc driver can't han= dle >>>>> it anymore. >>> >>> So - here is the console trace from suspend when I've added >>> dump_stack() to the fat_sync_fs() =A0 (and also added debug prints >>> around each call in this function -so its obvious the function is >>> actually left - but then it freezes later somewhere.) >>> >>> It's interesting that 3 calls to sync happens. >> >> It seems >> >> =A0 =A01) sync() (probabry "sync" command) >> =A0 =A02) sync as part of suspend sequence >> =A0 =A03) 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 think about what we want = to >> do for it. So, to workaround it for now, I've made this patch. >> >> Can you try whether this patch fixes this problem? >> > > So I've tested your patch - it seems to fix the problem in suspend - > the machine sleeps - however after resume the mmc SD card becomes > unusable to the system and appended call trace filled my message log > very quickly: > > After reboot the filesystem appeared to be usable again without error= s. Thanks for testing. "logical block size: 27499" is wrong value completely. Of course, fatfs is assuming the blocksize is not changed. (mmc wasn't resumed correctly?) Well, this problem seems to be completely different problem, and it seems the problem of suspend or mmc (or block?) stuff, or something. It would need to be analyzed by those people. Meanwhile, I'll apply this patch to workaround suspend problem and to remove unneeded write for next window. Thanks. > Call Trace: > [] __getblk+0x2cb/0x300 > [] ? _spin_unlock_irqrestore+0x38/0x80 > [] __breadahead+0x12/0x40 > [] fat_count_free_clusters+0x307/0x320 [fat] > [] ? check_object+0xd8/0x260 > [] ? trace_hardirqs_on+0xd/0x10 > [] fat_statfs+0xf5/0x110 [fat] > [] vfs_statfs+0x7c/0xa0 > [] vfs_statfs_native+0x20/0xb0 > [] sys_statfs+0x73/0xb0 > [] ? __up_write+0xcb/0x120 > [] ? sysret_check+0x27/0x62 > [] ? audit_syscall_entry+0x28b/0x2b0 > [] ? trace_hardirqs_on_caller+0x15d/0x1a0 > [] ? trace_hardirqs_on_thunk+0x3a/0x3f > [] system_call_fastpath+0x16/0x1b > getblk(): invalid block size 512 requested > logical block size: 27499 > > [] __breadahead+0x12/0x40 > [] fat_count_free_clusters+0x307/0x320 [fat] > [] ? check_object+0xd8/0x260 > [] ? trace_hardirqs_on+0xd/0x10 > [] fat_statfs+0xf5/0x110 [fat] > [] vfs_statfs+0x7c/0xa0 > [] vfs_statfs_native+0x20/0xb0 > [] sys_statfs+0x73/0xb0 > [] ? __up_write+0xcb/0x120 > [] ? sysret_check+0x27/0x62 > [] ? audit_syscall_entry+0x28b/0x2b0 > [] ? trace_hardirqs_on_caller+0x15d/0x1a0 > [] ? trace_hardirqs_on_thunk+0x3a/0x3f > [] system_call_fastpath+0x16/0x1b --=20 OGAWA Hirofumi