[rhelv6-list] A kernel bug that causes a system crash when the uptime is longer than 208.5 days

[GOLLSCHEWSKY, Tim]

Think a lot of people would like to know specifically which kernel version(s) are affected.  It would be great if that was included in the KB article.

Does this only affect RHEL6.1?

I have RHEL6.0 machines with uptime > 208.5 days:

 $ cat /etc/redhat-release; uname -r; uptime
 Red Hat Enterprise Linux Server release 6.0 (Santiago)
 2.6.32-71.14.1.el6.x86_64
 08:15:38 up 238 days, 15:50,  1 user,  load average: 0.00, 0.00, 0.00

Yet they meet the vulnerability requirements in that KB article (so far, with no kernel information included):

 $ dmesg | grep tsc
 Switching to clocksource tsc
 $ cat /proc/cpuinfo | grep flags
 flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx  rdtscp lm constant_tsc up arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida

So does this mean kernel 2.6.32-71.14.1.el6.x86_64 is not affected?

Cheers,
Tim.


-----Original Message-----
From: rhelv6-list-bounces at redhat.com [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Musayev, Ilya
Sent: Wednesday, 25 January 2012 3:41 AM
To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list
Subject: Re: [rhelv6-list] A kernel bug that causes a system crash when the uptime is longer than 208.5 days
Importance: High

Akemi,

Which kernels are affected?

I'm about to go large on latest 6.2 kernel and curious if I need to wait until this bug is resolved. I also see that for non-vmware servers I can use "notsc", can this be done online?



-----Original Message-----
From: rhelv6-list-bounces at redhat.com [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Akemi Yagi
Sent: Tuesday, January 24, 2012 4:03 AM
To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list
Subject: Re: [rhelv6-list] A kernel bug that causes a system crash when the uptime is longer than 208.5 days

On Fri, Jan 6, 2012 at 8:55 AM, Akemi Yagi <amyagi at gmail.com> wrote:
> On Fri, Jan 6, 2012 at 8:55 AM, Robin Price II <rprice at redhat.com> wrote:
>> Bugzilla:  https://bugzilla.redhat.com/show_bug.cgi?id=765720
>>
>> This is private due to private information from customer use cases.
>> If you need further details, I would highly encourage you to contact
>> Red Hat support or your TAM.
>>
>> Here is the initial information opened in the BZ:
>>
>> "The following patch is in urgent fix for Linus branch, which avoid
>> the unnecessary overflow in sched_clock otherwise kernel will crash
>> after
>> 209~250 days.
>>
>> http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=patch;h=4cecf
>> 6d401a01d054afc1e5f605bcbfe553cb9b9
>>
>> In hundreds of days, the __cycles_2_ns calculation in sched_clock has
>> an overflow.  cyc * per_cpu(cyc2ns, cpu) exceeds 64 bits, causing the
>> final value to become zero.  We can solve this without losing any precision.
>> We can decompose TSC into quotient and remainder of division by the
>> scale factor, and then use this to convert TSC into nanoseconds."
>>
>> ~rp
>
> Thank you for this post to let us know that Red Hat is now taking care
> of this issue.

Just a note to add that there is a KB article for this issue:

https://access.redhat.com/kb/docs/DOC-69254
"sched_clock() overflow after 208.5 days in Linux Kernel"

Akemi


________________________________

This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp".
Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au.
The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.