abrt version: 2.0.1 architecture: x86_64 cmdline: ro root=/dev/mapper/vg_forbiddencity-lv_root rd_LVM_LV=vg_forbiddencity/lv_root rd_LVM_LV=vg_forbiddencity/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet comment: Another attempt at running amdump. I believe is running when this happens. component: kernel kernel: 2.6.38.6-27.fc15.x86_64 os_release: Fedora release 15 (Lovelock) package: kernel reason: BUG: soft lockup - CPU#1 stuck for 67s! [md0_raid5:697] reported_to: kerneloops: URL=http://submit.kerneloops.org/submitoops.php time: Mon Jun 6 00:23:58 2011 backtrace: :BUG: soft lockup - CPU#1 stuck for 67s! [md0_raid5:697] :Modules linked in: cpufreq_ondemand powernow_k8 freq_table mperf ts_kmp ip6t_REJECT nf_conntrack_amanda nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables raid456 async_raid6_recov async_pq snd_hda_codec_realtek raid6_pq async_xor xor async_memcpy async_tx snd_hda_codec_hdmi snd_hda_intel snd_hda_codec eeepc_wmi snd_hwdep snd_seq sparse_keymap rfkill snd_seq_device snd_pcm r8169 mii sp5100_tco k10temp i2c_piix4 snd_timer snd wmi soundcore snd_page_alloc ipv6 radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] :CPU 1 :Modules linked in: cpufreq_ondemand powernow_k8 freq_table mperf ts_kmp ip6t_REJECT nf_conntrack_amanda nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables raid456 async_raid6_recov async_pq snd_hda_codec_realtek raid6_pq async_xor xor async_memcpy async_tx snd_hda_codec_hdmi snd_hda_intel snd_hda_codec eeepc_wmi snd_hwdep snd_seq sparse_keymap rfkill snd_seq_device snd_pcm r8169 mii sp5100_tco k10temp i2c_piix4 snd_timer snd wmi soundcore snd_page_alloc ipv6 radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] :Pid: 697, comm: md0_raid5 Not tainted 2.6.38.6-27.fc15.x86_64 #1 System manufacturer System Product Name/E35M1-M PRO :RIP: 0010:[<ffffffff813daa0c>] [<ffffffff813daa0c>] eth_type_trans+0x0/0x111 :RSP: 0018:ffff8800b7903d88 EFLAGS: 00000282 :RAX: ffff880124901040 RBX: ffffffff81475dd3 RCX: 00000000000005ea :RDX: 000000000000062a RSI: ffff8801237c2000 RDI: ffff88011a7e6600 :RBP: ffff8800b7903e00 R08: ffff880124901000 R09: ffff8800b7b89000 :R10: ffffffff81b40d00 R11: ffffffff81b40d00 R12: ffffffff8100a593 :R13: ffff8800b7903cf8 R14: ffff8801237c26c0 R15: ffff8801237c2000 :FS: 00007f74f4c9d7e0(0000) GS:ffff8800b7900000(0000) knlGS:0000000000000000 :CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b :CR2: 000000000064a000 CR3: 0000000125b48000 CR4: 00000000000006e0 :DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 :DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 :Process md0_raid5 (pid: 697, threadinfo ffff88011b49a000, task ffff88012358ae40) :Stack: : ffffffffa01d7ae2 ffffffff8147bec6 ffff8801237c26d8 00000000b4284000 : 000005ea00000001 ffff880127eee090 ffff88011b6b8000 00000000000005ea : 0090e5810000002a 00000001028311c3 ffff8801237c26d8 ffff8801237c2000 :Call Trace:
I switched Realtek 8169 to Intel e100e PCIe card. I have not been able to duplicate any of these problems since, even under very heavy load. The process is also much more idle (nearly completely used w/ 8169 and about 30-70% idle most of the time, more than 50 quite often, with the later card). I do not know if the 8169 chipset is just broken or if the driver is, but the problem lies with one of the two.
*** This bug has been marked as a duplicate of bug 710841 ***