Bug 967363

Summary: [abrt] WARNING: at kernel/workqueue.c:752 wq_worker_waking_up+0x50/0x70()
Product: [Fedora] Fedora Reporter: godetskiy
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:2e75d064f011c2c3f521c85899e6af35aaa3f38a
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-24 18:52:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: dmesg none

Description godetskiy 2013-05-26 20:34:56 UTC 
Additional info:
WARNING: at kernel/workqueue.c:752 wq_worker_waking_up+0x50/0x70()
Hardware name: K42Jr
Modules linked in: fuse ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast 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 be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi arc4 ath9k ath9k_common ath9k_hw acpi_cpufreq snd_hda_codec_hdmi snd_hda_codec_realtek mperf ath coretemp snd_hda_intel btusb bluetooth mac80211 snd_hda_codec kvm_intel uvcvideo kvm videobuf2_vmalloc snd_hwdep iTCO_wdt iTCO_vendor_support videobuf2_memops videobuf2_core videodev cfg80211 asus_laptop snd_seq snd_seq_device snd_pcm sparse_keymap input_polldev media rfkill snd_page_alloc joydev snd_timer snd intel_ips microcode lpc_ich mei serio_raw i2c_i801 uinput mfd_core soundcore binfmt_misc radeon crc32c_intel i2c_algo_bit sdhci_pci drm_kms_helper jme sdhci ttm mii mmc_core drm i2c_core video sunrpc
Pid: 8, comm: migration/0 Not tainted 3.9.4-200.fc18.x86_64 #1
Call Trace:
 [<ffffffff8105f125>] warn_slowpath_common+0x75/0xa0
 [<ffffffff8105f16a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff8107e220>] wq_worker_waking_up+0x50/0x70
 [<ffffffff810918a9>] ttwu_do_activate.constprop.83+0x59/0x70
 [<ffffffff81093d4c>] try_to_wake_up+0x1dc/0x2d0
 [<ffffffff81093e52>] default_wake_function+0x12/0x20
 [<ffffffff8108b1c5>] __wake_up_common+0x55/0x90
 [<ffffffff81091c50>] ? __migrate_task+0x160/0x160
 [<ffffffff8108e9e7>] complete+0x47/0x60
 [<ffffffff81091c77>] ? migration_cpu_stop+0x27/0x30
 [<ffffffff810d739d>] cpu_stop_signal_done+0x2d/0x30
 [<ffffffff810d76e1>] cpu_stopper_thread+0xa1/0x130
 [<ffffffff8165f848>] ? __schedule+0x3d8/0x820
 [<ffffffff8108a92f>] smpboot_thread_fn+0x10f/0x1a0
 [<ffffffff8108a820>] ? lg_global_unlock+0x60/0x60
 [<ffffffff81082c70>] kthread+0xc0/0xd0
 [<ffffffff81010303>] ? perf_trace_xen_cpu_set_ldt+0x33/0xe0
 [<ffffffff81082bb0>] ? kthread_create_on_node+0x120/0x120
 [<ffffffff81669eac>] ret_from_fork+0x7c/0xb0
 [<ffffffff81082bb0>] ? kthread_create_on_node+0x120/0x120
Comment 1 godetskiy 2013-05-26 20:35:02 UTC 
Created attachment 753386 [details]
File: dmesg
Comment 2 Josh Boyer 2013-07-01 19:41:17 UTC 
This is most likely fallout from all of the [ 7008.852379] jme 0000:07:00.5 p5p1: UDP Checksum error errors you're getting.  You're hitting this WARN_ON:

void wq_worker_waking_up(struct task_struct *task, unsigned int cpu)
{
        struct worker *worker = kthread_data(task);

        if (!(worker->flags & WORKER_NOT_RUNNING)) {
                WARN_ON_ONCE(worker->pool->cpu != cpu);
                atomic_inc(&worker->pool->nr_running);
        }
}

which says the worker isn't running and is now being woken up on a CPU that isn't from it's pool.

I don't think there's much that can be done for that particular issue.

Do the jme errors happen all of the time or just when performing certain tasks on the machine?  Do they hit with a particular kernel version, or all of them?
Comment 3 Josh Boyer 2013-07-24 18:52:39 UTC 
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.