RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 770228 - 6.2 kernel shows WARNING: at kernel/sched.c:5914
Summary: 6.2 kernel shows WARNING: at kernel/sched.c:5914
Keywords:
Status: CLOSED DUPLICATE of bug 766051
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
: 770431 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-24 13:59 UTC by Rik Theys
Modified: 2012-01-16 09:53 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-04 20:23:55 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
my bug report (970.00 KB, application/x-tar)
2012-01-01 17:58 UTC, osbugs 		no flags Details
View All

Description Rik Theys 2011-12-24 13:59:13 UTC 
Description of problem:

After a few minutes to an hour uptime, our systems are logging the following kernel WARNING:

------------[ cut here ]------------
WARNING: at kernel/sched.c:5914 thread_return+0x232/0x79d() (Not tainted)
Hardware name: ProLiant DL380 G5
Modules linked in: ip6_tables ebtable_nat ebtables ipmi_devintf bridge 8021q garp stp llc bonding ipv6 ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables ext3 jbd vhost_net macvtap macvlan tun kvm_intel kvm ses enclosure ipmi_si ipmi_msghandler hpilo hpwdt bnx2 e1000e sg iTCO_wdt iTCO_vendor_support i5000_edac edac_core i5k_amb shpchp ext4 mbcache jbd2 dm_round_robin sd_mod crc_t10dif hpsa cciss lpfc scsi_transport_fc scsi_tgt sr_mod cdrom pata_acpi ata_generic ata_piix radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_multipath dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
Pid: 6250, comm: qemu-kvm Not tainted 2.6.32-220.2.1.el6.x86_64 #1
Call Trace:
 [<ffffffff81069997>] ? warn_slowpath_common+0x87/0xc0
 [<ffffffff810699ea>] ? warn_slowpath_null+0x1a/0x20
 [<ffffffff814eccc5>] ? thread_return+0x232/0x79d
 [<ffffffff810958e3>] ? __hrtimer_start_range_ns+0x1a3/0x460
 [<ffffffff81094dc1>] ? lock_hrtimer_base+0x31/0x60
 [<ffffffff8100bc0e>] ? apic_timer_interrupt+0xe/0x20
 [<ffffffff814ee498>] ? schedule_hrtimeout_range+0xc8/0x160
 [<ffffffff81094b70>] ? hrtimer_wakeup+0x0/0x30
 [<ffffffff81095bd4>] ? hrtimer_start_range_ns+0x14/0x20
 [<ffffffff8118b079>] ? poll_schedule_timeout+0x39/0x60
 [<ffffffff8118b6e8>] ? do_select+0x578/0x6b0
 [<ffffffff8118b820>] ? __pollwait+0x0/0xf0
 [<ffffffff8118b910>] ? pollwake+0x0/0x60
 [<ffffffff8118b910>] ? pollwake+0x0/0x60
 [<ffffffff8118b910>] ? pollwake+0x0/0x60
 [<ffffffff8118b910>] ? pollwake+0x0/0x60
 [<ffffffff8118b910>] ? pollwake+0x0/0x60
 [<ffffffff8118b910>] ? pollwake+0x0/0x60
 [<ffffffff8118b910>] ? pollwake+0x0/0x60
 [<ffffffff8118b910>] ? pollwake+0x0/0x60
 [<ffffffff8118b910>] ? pollwake+0x0/0x60
 [<ffffffff8118c30a>] ? core_sys_select+0x18a/0x2c0
 [<ffffffff81090a10>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff81012b59>] ? read_tsc+0x9/0x20
 [<ffffffff8109b629>] ? ktime_get_ts+0xa9/0xe0
 [<ffffffff8118c697>] ? sys_select+0x47/0x110
 [<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b
---[ end trace deedc66cc8041667 ]---

We see this error on a lot of our servers and workstations.

Version-Release number of selected component (if applicable):

kernels 2.6.32-220.el6 and up (220.2.1.el6)

RHEL 6.1 kernels did not show this message.

How reproducible:

always on those machines

Steps to Reproduce:
1. boot the system with the 6.2 kernel and let it run it's normal tasks
2. wait and the error will appear
3.
  
Actual results:

WARNING message as shown above.

Expected results:

No warning message

Additional info:

So far the systems seem to be working OK after printing the warning.
Comment 2 Madison Kelly 2011-12-25 21:30:58 UTC 
I posted this on rhbz#767127, which this may or may not be a dupe of. As with Rik, I am seeing this oops fairly often, but I am running a fully up to date RHEL 6.2. I am seeing this on both nodes in my cluster (identical hardware).

Dec 25 15:40:12 an-node01 kernel: ------------[ cut here ]------------
Dec 25 15:40:12 an-node01 kernel: WARNING: at kernel/sched.c:5914 thread_return+0x232/0x79d() (Tainted: G        W  ----------------  )
Dec 25 15:40:12 an-node01 kernel: Hardware name: empty
Dec 25 15:40:12 an-node01 kernel: Modules linked in: gfs2 iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 drbd(U) dlm configfs ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bridge stp llc bonding ipv6 vhost_net macvtap macvlan tun kvm_intel kvm microcode shpchp i2c_i801 i2c_core sg iTCO_wdt iTCO_vendor_support e1000e ext4 mbcache jbd2 sd_mod crc_t10dif ahci dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
Dec 25 15:40:12 an-node01 kernel: Pid: 1343, comm: bond1 Tainted: G        W  ----------------   2.6.32-220.2.1.el6.x86_64 #1
Dec 25 15:40:12 an-node01 kernel: Call Trace:
Dec 25 15:40:12 an-node01 kernel: [<ffffffff81069997>] ? warn_slowpath_common+0x87/0xc0
Dec 25 15:40:12 an-node01 kernel: [<ffffffff810699ea>] ? warn_slowpath_null+0x1a/0x20
Dec 25 15:40:12 an-node01 kernel: [<ffffffff814eccc5>] ? thread_return+0x232/0x79d
Dec 25 15:40:12 an-node01 kernel: [<ffffffff8107d068>] ? add_timer+0x18/0x30
Dec 25 15:40:12 an-node01 kernel: [<ffffffff8108be79>] ? queue_delayed_work_on+0xb9/0x120
Dec 25 15:40:12 an-node01 kernel: [<ffffffffa0269650>] ? bond_mii_monitor+0x0/0x610 [bonding]
Dec 25 15:40:12 an-node01 kernel: [<ffffffff8108b15c>] ? worker_thread+0x1fc/0x2a0
Dec 25 15:40:12 an-node01 kernel: [<ffffffff81090a10>] ? autoremove_wake_function+0x0/0x40
Dec 25 15:40:12 an-node01 kernel: [<ffffffff8108af60>] ? worker_thread+0x0/0x2a0
Dec 25 15:40:12 an-node01 kernel: [<ffffffff810906a6>] ? kthread+0x96/0xa0
Dec 25 15:40:12 an-node01 kernel: [<ffffffff8100c14a>] ? child_rip+0xa/0x20
Dec 25 15:40:12 an-node01 kernel: [<ffffffff81090610>] ? kthread+0x0/0xa0
Dec 25 15:40:12 an-node01 kernel: [<ffffffff8100c140>] ? child_rip+0x0/0x20
Dec 25 15:40:12 an-node01 kernel: ---[ end trace 705d5c1db0fb1e00 ]---

The nodes are also Intel Xeons, but they are the much more modest E3-1220. The mainboard is a Tyan S5510 with 8GB of DDR3 ECC memory.
Comment 3 Phil Anderson 2011-12-27 02:13:03 UTC 
Also getting this on most of my boxes after rebooting to kernel-2.6.32-220.2.1.el6.x86_64.  Different stacks each time, triggered by different processes (bash, squid, cpuspeed, java, etc).  All stacks have warn_slowpath_common at the top.
Comment 4 Ralph Angenendt 2011-12-28 09:19:49 UTC 
There are also several reports on that on the CentOS bug tracker, see http://bugs.centos.org/view.php?id=5371
Comment 5 daryl herzmann 2011-12-28 19:21:31 UTC 
Red Hat has a KB article on this now:

https://access.redhat.com/kb/docs/DOC-68014

which references this BZ:

https://bugzilla.redhat.com/show_bug.cgi?id=766051

private BZ, grrrrrrrrrrrrrrr
Comment 6 Colin.Simpson 2011-12-30 11:41:27 UTC 
Thanks for the KB article. 

Can the above referenced bug be made open?
Comment 7 daryl herzmann 2011-12-31 13:09:46 UTC 
It is starting to get old having all these abortd emails coming to me (since I forward all root emails from all my machines to me :) )
Comment 8 osbugs 2012-01-01 17:58:32 UTC 
Created attachment 550159 [details]
my bug report
Comment 9 osbugs 2012-01-01 18:00:44 UTC 
Comment on attachment 550159 [details]
my bug report

I hope more info will help. Thanks.
Comment 10 osbugs 2012-01-01 18:01:39 UTC 
I uploaded my report. I hope this issue will be fixed :) Thanks!
Comment 11 Colin.Simpson 2012-01-01 20:33:14 UTC 
On 6.1 we get spammed with: 

/etc/cron.hourly/mcelog.cron:

read: No such device

, every time a system is reboooted (which I hope is fixed in 6.2). But now in 6.2 we get spammed with "[abrt] full crash report"s everytime a system is rebooted. 

It would nice for this to be fixed so we get "quiet" RHEL6 systems.
Comment 13 Jeremy West 2012-01-04 20:23:55 UTC 

*** This bug has been marked as a duplicate of bug 766051 ***
Comment 14 daryl herzmann 2012-01-04 20:30:36 UTC 
that is a private bug!
Comment 15 Madison Kelly 2012-01-04 20:32:19 UTC 
Jeremy,

  Can you clone the private bug (minus customer data) so that those of us also affected by this issue can track it? It would be much appreciated.
Comment 16 Matthew Garrett 2012-01-06 14:26:01 UTC 
*** Bug 770431 has been marked as a duplicate of this bug. ***
Comment 17 daryl herzmann 2012-01-06 14:59:05 UTC 
Why is redhat closing other bugs in reference to this one, when this one is closed and references a private bug?  I do see redhat removed the link from the KB article at least.
Note You need to log in before you can comment on or make changes to this bug.