Bug 1081470 - soft lockup - CPU#1 stuck for 23s! [rsync:17305]
Summary: soft lockup - CPU#1 stuck for 23s! [rsync:17305]
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rsync
Version: 20
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Michal Luscon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-27 12:13 UTC by Wojciech Błaszkowski
Modified: 2014-09-16 11:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-16 11:18:08 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Wojciech Błaszkowski 2014-03-27 12:13:12 UTC
Description of problem:

[1043846.943576] BUG: soft lockup - CPU#1 stuck for 23s! [rsync:17305]
[1043846.943582] Modules linked in: usb_storage xfs libcrc32c dm_crypt bnep bluetooth cfg80211 rfkill ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm coretemp snd_page_alloc r8169 snd_timer joydev iTCO_wdt gpio_ich iTCO_vendor_support snd mii shpchp ppdev lpc_ich raid1 microcode soundcore i2c_i801 mfd_core serio_raw parport_pc parport acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd sunrpc i915 ata_generic video
[1043846.943651]  pata_acpi i2c_algo_bit drm_kms_helper drm i2c_core
[1043846.943659] CPU: 1 PID: 17305 Comm: rsync Tainted: G        W    3.13.6-200.fc20.x86_64 #1
[1043846.943662] Hardware name: Gigabyte Technology Co., Ltd. G31M-S2L/G31M-S2L, BIOS F4 01/02/2008
[1043846.943666] task: ffff880000199140 ti: ffff88001eed6000 task.ti: ffff88001eed6000
[1043846.943668] RIP: 0010:[<ffffffff811cdf10>]  [<ffffffff811cdf10>] d_shrink_del+0x0/0x80
[1043846.943676] RSP: 0018:ffff88001eed7868  EFLAGS: 00000246
[1043846.943679] RAX: ffff880004493e00 RBX: 0000000000000000 RCX: dead000000200200
[1043846.943681] RDX: 000000000000346d RSI: 0000000000000000 RDI: ffff880004493d80
[1043846.943684] RBP: ffff88001eed7898 R08: ffff880004493e00 R09: 00000000000006c4
[1043846.943687] R10: 0000000000000000 R11: ffff88001eed752e R12: 0000000000000000
[1043846.943689] R13: ffff88001eed7860 R14: 8149431e54e08530 R15: ffff88001eed7860
[1043846.943692] FS:  00007f501f24e740(0000) GS:ffff88007f280000(0000) knlGS:0000000000000000
[1043846.943695] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[1043846.943698] CR2: 00007fbbdb453000 CR3: 00000000486a2000 CR4: 00000000000007e0
[1043846.943700] Stack:
[1043846.943702]  ffffffff811cf258 ffff880004493e00 ffff88001eed78b0 00000000000000f8
[1043846.943707]  ffff88003373b800 0000000000000000 ffff88001eed78d0 ffffffff811d08f7
[1043846.943711]  0000000000000000 ffff880073c30500 ffff880004493e00 ffff88001eed7aa0
[1043846.943715] Call Trace:
[1043846.943721]  [<ffffffff811cf258>] ? shrink_dentry_list+0x68/0xd0
[1043846.943726]  [<ffffffff811d08f7>] prune_dcache_sb+0x47/0x60
[1043846.943730]  [<ffffffff811bc1e7>] super_cache_scan+0xe7/0x160
[1043846.943735]  [<ffffffff8115c1df>] shrink_slab+0x1cf/0x380
[1043846.943740]  [<ffffffff8115f3e1>] do_try_to_free_pages+0x491/0x670
[1043846.943744]  [<ffffffff8115f6af>] try_to_free_pages+0xef/0x170
[1043846.943749]  [<ffffffff81153d7c>] __alloc_pages_nodemask+0x70c/0xa80
[1043846.943756]  [<ffffffff815745e1>] ? __kmalloc_reserve.isra.25+0x31/0x90
[1043846.943761]  [<ffffffff811929e3>] alloc_pages_current+0xa3/0x170
[1043846.943765]  [<ffffffff815700bc>] sock_alloc_send_pskb+0x21c/0x3d0
[1043846.943771]  [<ffffffff810ae7d0>] ? __wake_up_sync_key+0x50/0x60
[1043846.943776]  [<ffffffff81627c0e>] unix_stream_sendmsg+0x26e/0x400
[1043846.943781]  [<ffffffff8156ad7e>] sock_aio_write+0xfe/0x130
[1043846.943786]  [<ffffffff811b83da>] do_sync_write+0x5a/0x90
[1043846.943791]  [<ffffffff811b8c2d>] vfs_write+0x1ad/0x1f0
[1043846.943794]  [<ffffffff811b8a0e>] ? vfs_read+0xee/0x160
[1043846.943798]  [<ffffffff811b9569>] SyS_write+0x49/0xa0
[1043846.943803]  [<ffffffff810fc2a6>] ? __audit_syscall_exit+0x1f6/0x2a0
[1043846.943809]  [<ffffffff816962e9>] system_call_fastpath+0x16/0x1b
[1043846.943811] Code: 83 80 3d 72 1a b1 00 00 75 82 be 3e 06 00 00 48 c7 c7 87 02 a2 81 e8 40 f6 e9 ff c6 05 58 1a b1 00 01 e9 65 ff ff ff 0f 1f 40 00 <66> 66 66 66 90 55 48 89 e5 41 54 53 8b 07 48 89 fb 25 00 04 08 

Version-Release number of selected component (if applicable):
Fedora 20, 3.13.6-200.fc20.x86_64
rsync-3.1.0-2.fc20.x86_64
glibc-2.18-12.fc20.x86_64

Steps to Reproduce:

2xSATA in RAID1 and USB drive
rsync -aPv /raid1/luks/partition /usb-drive/luks/partition/

luksDump (both the same):
Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha512
Payload offset: 4096
MK bits:        512

1. create raid1 with mdadm, crypt it with luks, mount
2. crypt USB drive, mount
3. rsync a lot of files (kmail directory)

How reproducible:
for now: several times

Actual results:
copying is stopped.

Expected results:
copy of files

Additional info:

Comment 1 Michal Luscon 2014-08-22 07:51:06 UTC
Unfortunately, provided information is not sufficient for reproduction of this bug. You can try to run rsync in verbose mode or use gdb to determine which part of code is responsible for CPU overload.

Comment 2 Michal Luscon 2014-09-16 11:18:08 UTC
Feel free to reopen with additional info.


Note You need to log in before you can comment on or make changes to this bug.