Description of problem:
Maybe this bug report should be classified differently than abrt is going to suggest. Please feel free to re-classify it.

It happens about once every few weeks that my PC gets stuck when trying to unmount an external USB disk after the nightly backup. "Every few weeks" means a month or maybe only one week passes. When a lockup happens, I can't use the machine anymore (including not being able to log in via ssh) and have to switch the machine off and on. Every time this lockup happens, when I get to the machine, its fan(s) is/are running louder as if under a high CPU load (which might actually be the case and would be in line with the "soft lockup" messages).

This is the first time I was notified about soft lockups by abrt and in /var/log/messages. I'll attach the section from /var/log/messages which has lots of "soft lockup" messages which occurred this morning.

Some more info on the backup problem: After having activated the MARK facility in syslog recently, I noticed that the lockups happen when my backup script tries to unmount the external disk after the backup. Using sync in the shell script has the same effect. I know the time the backup finished by the log message "/usr/bin/rsnapshot -v daily: completed successfully". I added a sleep command between the time the backup finishes and the unmount invocation. But even increasing this time to 2 or 3 hours still gives me occasional lockups. (I think setting the time to 2 hours helped a bit, but it's difficult to tell. I increased only recently to 3 hours, so can't tell anything about the effectiveness.) Two recent lockups happened with Fedora 19, but if I remember correctly, I had this problem also with Ubuntu.

There are two disks which are used alternatingly by the backup script, both are Western Digital My Book 1.5 TB devices. The output of lsusb is:
Bus 002 Device 004: ID 1058:1123 Western Digital Technologies, Inc. My Book 3.0
Bus 002 Device 003: ID 1058:1123 Western Digital Technologies, Inc. My Book 3.0

In another bug report, https://bugzilla.redhat.com/show_bug.cgi?id=951089 , there's a mention of SMART problems, but for both of my disks smartctl tells me "SMART overall-health self-assessment test result: PASSED" and for the short test "The previous self-test routine completed without error". That said, the disks may be a few years old by now, and if you think it's likely to help, I'll replace them. (That said, I think even if the disks were faulty, the kernel shouldn't lock up.)

Please let me know if you need more information.

By the way, even if there's no real fix available, it would already help me a lot if the system rebooted in such a lockup situation. Then I could at least again log into the system remotely after it's rebooted.

Additional info:
reporter:       libreport-2.1.6
BUG: soft lockup - CPU#7 stuck for 22s! [umount:969]
Modules linked in: fuse bnep bluetooth rfkill nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_nat nf_nat_ipv6 ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek acpi_cpufreq dcdbas mperf snd_hda_intel snd_hda_codec iTCO_wdt coretemp kvm_intel iTCO_vendor_support snd_ctxfi snd_hwdep snd_seq snd_seq_device broadcom snd_pcm kvm crc32c_intel snd_page_alloc joydev tg3 snd_timer snd soundcore i7core_edac i2c_i801 edac_core mei_me ptp pps_core microcode mei lpc_ich mfd_core serio_raw usblp uinput radeon i2c_algo_bit drm_kms_helper ttm drm usb_storage i2c_core
CPU: 7 PID: 969 Comm: umount Not tainted 3.10.5-201.fc19.x86_64 #1
Hardware name: Dell Inc. Vostro 430/054KM3, BIOS 2.4.0 01/13/2011
task: ffff880041566320 ti: ffff8801028be000 task.ti: ffff8801028be000
RIP: 0010:[<ffffffff8163ef23>]  [<ffffffff8163ef23>] _raw_spin_lock+0x13/0x30
RSP: 0018:ffff8801028bfe18  EFLAGS: 00000206
RAX: 0000000000005050 RBX: ffffffff81138e2b RCX: 0000000000000002
RDX: 000000000000004f RSI: ffff88010b016a38 RDI: ffff88010b016678
RBP: ffff8801028bfe18 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000100 R11: 0000000000000005 R12: 0000000000000000
R13: ffffffff812c5ad4 R14: ffff8801028bfd88 R15: 0000000000000000
FS:  00007f06cb431880(0000) GS:ffff8801bfdc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f5ae259d000 CR3: 000000014e432000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
 ffff8801028bfe60 ffffffff811d6edb ffff8801643bf800 ffff8801643bf8a0
 ffff8801643bf800 ffff8801643bf8a0 ffffffff81825320 ffff88016e432c40
 ffff88016e432c20 ffff8801028bfe88 ffffffff81199ae0 ffff8801b53c09c0
Call Trace:
 [<ffffffff811d6edb>] fsnotify_unmount_inodes+0x8b/0x1c0
 [<ffffffff81199ae0>] generic_shutdown_super+0x40/0xd0
 [<ffffffff81199d87>] kill_block_super+0x27/0x70
 [<ffffffff8119a0fd>] deactivate_locked_super+0x3d/0x60
 [<ffffffff8119a166>] deactivate_super+0x46/0x60
 [<ffffffff811b5075>] mntput_no_expire+0xc5/0x120
 [<ffffffff811b5e51>] SyS_umount+0x91/0x3a0
 [<ffffffff81647559>] system_call_fastpath+0x16/0x1b
Code: 75 e6 b8 01 00 00 00 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 b8 00 01 00 00 f0 66 0f c1 07 <0f> b6 d4 38 c2 74 0f 66 0f 1f 44 00 00 f3 90 0f b6 07 38 d0 75