Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934148Ab3HHJR7 (ORCPT ); Thu, 8 Aug 2013 05:17:59 -0400 Received: from mail-we0-f172.google.com ([74.125.82.172]:57340 "EHLO mail-we0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757710Ab3HHJRz (ORCPT ); Thu, 8 Aug 2013 05:17:55 -0400 MIME-Version: 1.0 Reply-To: sedat.dilek@gmail.com In-Reply-To: References: <2146168.3J7W6RtiZr@vostro.rjw.lan>

Date: Thu, 8 Aug 2013 11:17:53 +0200 Message-ID: Subject: Re: linux-next: Tree for Aug 7 [ call-trace on suspend: ext4 | pm related ? ] From: Sedat Dilek To: Colin Cross Cc: "Rafael J. Wysocki" , Stephen Rothwell , linux-next@vger.kernel.org, lkml , Ext4 Developers List , "Theodore Ts'o" , Linux PM List , Tejun Heo , Miklos Szeredi , fuse-devel@lists.sourceforge.net Content-Type: multipart/mixed; boundary=047d7b45105e084fad04e36c22b3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 13141 Lines: 271 --047d7b45105e084fad04e36c22b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 8, 2013 at 10:46 AM, Sedat Dilek wrote: > On Thu, Aug 8, 2013 at 3:12 AM, Colin Cross wrote: >> On Wed, Aug 7, 2013 at 6:01 PM, Sedat Dilek wrot= e: >>> On Thu, Aug 8, 2013 at 1:34 AM, Colin Cross wrote: >>>> On Wed, Aug 7, 2013 at 4:15 PM, Sedat Dilek wr= ote: >>>>> On Thu, Aug 8, 2013 at 12:58 AM, Colin Cross wro= te: >>>>>> Can you try add a call to show_state_filter(TASK_UNINTERRUPTIBLE) in >>>>>> the error path of try_to_freeze_tasks(), where it prints the "refusi= ng >>>>>> to freeze" message? It will print the stack trace of every thread >>>>>> since they are all in the freezer, so the output will be very long. >>>>>> >>>>> >>>>> If you provide a patch, I will give it a try. >>>> >>>> Try the attached patch. >>> >>> This time I do not see ext4 related messages. >>> >>> - Sedat - >> >> Can you describe your filesystem setup? It looks like you have an >> ntfs fuse filesystem and a loopback ext4 mount? Is the file backing >> the loopback ext4 filesystem located on the ntfs filesystem? >> > > [ CC fuse folks ] > > This is a Ubuntu/precise AMD64 installed in a WUBI environment (rootfs > is an image on my Win7-partition and thus uses fuse/ntfs/loop). > > $ cat /etc/fstab > # /etc/fstab: static file system information. > > # Use 'blkid' to print the universally unique identifier for a > # device; this may be used with UUID=3D as a more robust way to name devi= ces > # that works even if disks are added and removed. See fstab(5). > > # > > proc /proc proc > nodev,noexec,nosuid 0 0 > /host/ubuntu/disks/root.disk / ext4 > loop,errors=3Dremount-ro 0 1 > /host/ubuntu/disks/swap.disk none swap loop,sw > 0 0 > > $ df -T > Dateisystem Typ 1K-Bl=C3=B6cke Benutzt Verf=C3=BCgbar Verw% Ein= geh=C3=A4ngt auf > rootfs rootfs 17753424 11598008 5230540 69% / <--- > 18GiB file-image > udev devtmpfs 1969240 4 1969236 1% /dev > tmpfs tmpfs 789036 884 788152 1% /run > /dev/sda2 fuseblk 465546236 107358584 358187652 24% /host <--- Wi= n7-OS > /dev/loop0 ext4 17753424 11598008 5230540 69% / > none tmpfs 5120 0 5120 0% /run/lock > none tmpfs 1972588 200 1972388 1% /run/shm > > $ sudo LC_ALL=3DC fdisk -l /dev/sda > > Disk /dev/sda: 500.1 GB, 500107862016 bytes > 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors > Units =3D sectors of 1 * 512 =3D 512 bytes > Sector size (logical/physical): 512 bytes / 4096 bytes > I/O size (minimum/optimal): 4096 bytes / 4096 bytes > Disk identifier: 0xcb9885ab > > Device Boot Start End Blocks Id System > /dev/sda1 * 2048 206847 102400 7 HPFS/NTFS/exFAT > /dev/sda2 206848 931299327 465546240 7 HPFS/NTFS/exFAT > /dev/sda3 931299328 976773119 22736896 27 Hidden NTFS WinRE > > [ /etc/grub.d/40_custom ] > ... > menuentry "Ubuntu/precise AMD64, WUBI-system with Ubuntu-kernel" > --class ubuntu --class gnu-linux --class gnu --class os { > insmod part_msdos > insmod ntfs > set root=3D'(hd0,msdos2)' > search --no-floppy --fs-uuid --set=3Droot 001AADA61AAD9964 > loopback loop0 /ubuntu/disks/root.disk > set root=3D(loop0) > linux /vmlinuz root=3DUUID=3D001AADA61AAD9964 > loop=3D/ubuntu/disks/root.disk ro > initrd /initrd.img > } > ... > > So, no "native" Linux installation here. > > - Sedat - > > [1] https://wiki.ubuntu.com/WubiGuide > >> This looks like the interesting part, the process backing the fuse >> filesystem is frozen (through the normal freeze path, not any of my >> new freeze points), and the loop0 processes are blocked on it. It >> doesn't seem related to my patches. >> >> [ 125.336205] mount.ntfs D ffffffff81811820 0 303 1 0x0= 0000004 >> [ 125.336209] ffff8800d3e95d18 0000000000000002 0000000037a6b000 >> ffff8800d57a66b8 >> [ 125.336212] ffff8801185286c0 ffff8800d3e95fd8 ffff8800d3e95fd8 >> ffff8800d3e95fd8 >> [ 125.336214] ffffffff81c144a0 ffff8801185286c0 ffff8800d3e95d08 >> ffff8801185286c0 >> [ 125.336217] Call Trace: >> [ 125.336225] [] schedule+0x29/0x70 >> [ 125.336230] [] __refrigerator+0x43/0xe0 >> [ 125.336234] [] get_signal_to_deliver+0x5b9/0x600 >> [ 125.336238] [] ? fuse_dev_read+0x68/0x80 >> [ 125.336242] [] do_signal+0x58/0x8f0 >> [ 125.336246] [] ? acct_account_cputime+0x1c/0x20 >> [ 125.336249] [] ? do_raw_spin_unlock+0x5d/0xb0 >> [ 125.336252] [] ? _raw_spin_unlock+0xe/0x10 >> [ 125.336255] [] ? vtime_account_user+0x6d/0x80 >> [ 125.336258] [] do_notify_resume+0x88/0xc0 >> [ 125.336261] [] int_signal+0x12/0x17 >> [ 125.336263] loop0 D ffffffff81811820 0 310 2 0x0= 0000000 >> [ 125.336265] ffff8800d573d968 0000000000000002 0000000000000000 >> ffff8800d57aeb80 >> [ 125.336268] ffff880118bda740 ffff8800d573dfd8 ffff8800d573dfd8 >> ffff8800d573dfd8 >> [ 125.336270] ffff880119f98340 ffff880118bda740 ffff8800d573d968 >> ffff88011fad5118 >> [ 125.336273] Call Trace: >> [ 125.336278] [] ? __lock_page+0x70/0x70 >> [ 125.336280] [] schedule+0x29/0x70 >> [ 125.336283] [] io_schedule+0x8f/0xd0 >> [ 125.336286] [] sleep_on_page+0xe/0x20 >> [ 125.336288] [] __wait_on_bit_lock+0x5d/0xc0 >> [ 125.336291] [] __lock_page+0x67/0x70 >> [ 125.336294] [] ? wake_atomic_t_function+0x40/0x40 >> [ 125.336298] [] __generic_file_splice_read+0x59f/0x= 5d0 >> [ 125.336302] [] ? cpumask_next_and+0x38/0x50 >> [ 125.336305] [] ? update_sd_lb_stats+0x123/0x610 >> [ 125.336309] [] ? x2apic_send_IPI_mask+0x13/0x20 >> [ 125.336312] [] ? native_smp_send_reschedule+0x4b/0= x60 >> [ 125.336315] [] ? resched_task+0x76/0x80 >> [ 125.336318] [] ? page_cache_pipe_buf_release+0x30/= 0x30 >> [ 125.336321] [] generic_file_splice_read+0x3e/0x80 >> [ 125.336324] [] do_splice_to+0x7b/0xa0 >> [ 125.336326] [] splice_direct_to_actor+0xa7/0x1c0 >> [ 125.336330] [] ? loop_thread+0x2a0/0x2a0 >> [ 125.336333] [] do_bio_filebacked+0xf2/0x340 >> [ 125.336336] [] ? do_raw_spin_lock+0x4c/0x120 >> [ 125.336339] [] loop_thread+0xe5/0x2a0 >> [ 125.336341] [] ? __init_waitqueue_head+0x40/0x40 >> [ 125.336344] [] ? do_bio_filebacked+0x340/0x340 >> [ 125.336346] [] kthread+0xd8/0xe0 >> [ 125.336348] [] ? flush_kthread_worker+0xe0/0xe0 >> [ 125.336351] [] ret_from_fork+0x7c/0xb0 >> [ 125.336353] [] ? flush_kthread_worker+0xe0/0xe0 >> [ 125.336354] jbd2/loop0-8 D 0000000000000000 0 312 2 0x0= 0000000 >> [ 125.336357] ffff8800d56c7b08 0000000000000002 ffff8800d56c7ab8 >> ffffffff8137a90d >> [ 125.336359] ffff880037ba4240 ffff8800d56c7fd8 ffff8800d56c7fd8 >> ffff8800d56c7fd8 >> [ 125.336362] ffff88010d33e5c0 ffff880037ba4240 ffff8800d56c7b08 >> ffff88011fad5118 >> [ 125.336364] Call Trace: >> [ 125.336367] [] ? do_raw_spin_unlock+0x5d/0xb0 >> [ 125.336369] [] ? __wait_on_buffer+0x30/0x30 >> [ 125.336371] [] schedule+0x29/0x70 >> [ 125.336374] [] io_schedule+0x8f/0xd0 >> [ 125.336376] [] sleep_on_buffer+0xe/0x20 >> [ 125.336378] [] __wait_on_bit+0x62/0x90 >> [ 125.336380] [] ? __wait_on_buffer+0x30/0x30 >> [ 125.336382] [] out_of_line_wait_on_bit+0x7c/0x90 >> [ 125.336384] [] ? wake_atomic_t_function+0x40/0x40 >> [ 125.336386] [] __wait_on_buffer+0x2e/0x30 >> [ 125.336390] [] >> jbd2_journal_commit_transaction+0x1051/0x1c60 >> [ 125.336393] [] ? load_balance+0x14b/0x870 >> [ 125.336397] [] ? _raw_spin_lock_irqsave+0x24/0x30 >> [ 125.336399] [] ? try_to_del_timer_sync+0x4f/0x70 >> [ 125.336402] [] kjournald2+0x11b/0x350 >> [ 125.336405] [] ? __schedule+0x3e5/0x850 >> [ 125.336407] [] ? __init_waitqueue_head+0x40/0x40 >> [ 125.336410] [] ? jbd2_journal_clear_features+0x90/= 0x90 >> [ 125.336412] [] kthread+0xd8/0xe0 >> [ 125.336414] [] ? flush_kthread_worker+0xe0/0xe0 >> [ 125.336416] [] ret_from_fork+0x7c/0xb0 >> [ 125.336418] [] ? flush_kthread_worker+0xe0/0xe0 My 1st suspend try with next-20130808 shows same isssue (w/o your "hack" pa= tch): [ 98.026982] PM: Syncing filesystems ... done. [ 98.321181] PM: Preparing system for mem sleep [ 98.321736] Freezing user space processes ... [ 118.320817] Freezing of tasks failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=3D0): [ 118.320838] apt-check D 0000000000000000 0 2636 2456 0x0000= 0004 [ 118.320841] ffff880109631c98 0000000000000002 0000000000000000 ffff88005c044280 [ 118.320845] ffff88005c1d4640 ffff880109631fd8 ffff880109631fd8 ffff880109631fd8 [ 118.320847] ffff880119f440c0 ffff88005c1d4640 ffff880109631c98 ffff88011fa15118 [ 118.320850] Call Trace: [ 118.320859] [] ? sleep_on_page+0x20/0x20 [ 118.320863] [] schedule+0x29/0x70 [ 118.320865] [] io_schedule+0x8f/0xd0 [ 118.320868] [] sleep_on_page_killable+0xe/0x40 [ 118.320871] [] __wait_on_bit_lock+0x5d/0xc0 [ 118.320874] [] __lock_page_killable+0x67/0x70 [ 118.320877] [] ? wake_atomic_t_function+0x40/0x40 [ 118.320880] [] generic_file_aio_read+0x47e/0x720 [ 118.320883] [] do_sync_read+0x5a/0x90 [ 118.320885] [] vfs_read+0xb4/0x180 [ 118.320887] [] SyS_read+0x52/0xa0 [ 118.320891] [] tracesys+0xe1/0xe6 [ 118.320892] [ 118.320893] Restarting tasks ... done. I walked trough my scripts-dir... is run_pm-test.sh an appropriate test-case/use-case? - Sedat - --047d7b45105e084fad04e36c22b3 Content-Type: application/x-sh; name="run_pm-test.sh" Content-Disposition: attachment; filename="run_pm-test.sh" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hk3r52kq0 IyEvYmluL2Jhc2gKCiMjIyBOT1RFOiBSdW4gYXMgcm9vdAoKIyMjIEhFTFAKIyBbMV0gaHR0cDov L2dpdC5rZXJuZWwub3JnLz9wPWxpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0O2E9 YmxvYjtmPURvY3VtZW50YXRpb24vcG93ZXIvYmFzaWMtcG0tZGVidWdnaW5nLnR4dAojIFsyXSBo dHRwOi8vZ2l0Lmtlcm5lbC5vcmcvP3A9bGludXgva2VybmVsL2dpdC90b3J2YWxkcy9saW51eC5n aXQ7YT1ibG9iO2Y9RG9jdW1lbnRhdGlvbi9wb3dlci9mcmVlemluZy1vZi10YXNrcy50eHQKCiMj IyBQUkVSRVE6IEtlcm5lbCBERUJVRyBvcHRpb25zCiMgKyBDT05GSUdfUE1fREVCVUc9eQojICsg Q09ORklHX0VYVDRfREVCVUc9eQojICsgQ09ORklHX0pCRDJfREVCVUc9eQoKZXhwb3J0IExBTkc9 QwpleHBvcnQgTENfQUxMPUMKCiMjIyBEZWZhdWx0IHZhbHVlIG9mIGh1bmdfdGFza190aW1lb3V0 X3NlY3MgaXMgMTIwIFtzZWNzXQpTRUNTPSIwIgoKIyMjIFBvc3NpYmxlIHR5cGVzOiBub25lIGNv cmUgcHJvY2Vzc29ycyBwbGF0Zm9ybSBkZXZpY2VzIGZyZWV6ZXIKUE1fVEVTVF9UWVBFPSJmcmVl emVyIgoKIyMjIENvdW50ZXIgYW5kIGxvb3BzCkNPVU5URVI9IjAiCkxPT1BTPSIxMCIKCmVjaG8g IiRTRUNTIiA+IC9wcm9jL3N5cy9rZXJuZWwvaHVuZ190YXNrX3RpbWVvdXRfc2VjcwplY2hvICJo dW5nX3Rhc2tfdGltZW91dF9zZWNzIFtzZWNzXSBpcyBub3cgLi4uIgpjYXQgL3Byb2Mvc3lzL2tl cm5lbC9odW5nX3Rhc2tfdGltZW91dF9zZWNzCgplY2hvICIkUE1fVEVTVF9UWVBFIiA+IC9zeXMv cG93ZXIvcG1fdGVzdAplY2hvICJwbS10ZXN0IHR5cGUgW3N0cmluZ10gaXMgbm93IC4uLiIKY2F0 IC9zeXMvcG93ZXIvcG1fdGVzdAoKZWNobyAicG1fdGVzdC8kUE1fVEVTVF9UWVBFOiBSdW5uaW5n IC4uLiIKd2hpbGUgWyAkQ09VTlRFUiAtbHQgJExPT1BTIF07IGRvCiAgICBlY2hvIFsgUnVubmlu ZyAuLi4gJENPVU5URVIgXQogICAgZWNobyBtZW0gPiAvc3lzL3Bvd2VyL3N0YXRlICYmIHNsZWVw IDEKICAgIGVjaG8gWyBEb25lIC4uLi4uLiAkQ09VTlRFUiBdCiAgICBsZXQgQ09VTlRFUj1DT1VO VEVSKzEKZG9uZQplY2hvICJwbV90ZXN0LyRQTV9URVNUX1RZUEU6IEVORC4iCg== --047d7b45105e084fad04e36c22b3-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/