Scientific Linux Forum.org



  Reply to this topicStart new topicStart Poll

> RHEL 6 bug sched_clock overflow after 208.5 days, also present in Scientific?
gargunkle
 Posted: Jan 24 2012, 07:02 PM
Quote Post


SLF Newbie


Group: Members
Posts: 9
Member No.: 902
Joined: 5-October 11









I'm not sure if I am legally allowed to copy and paste their article (probably not) :

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

The gist of it is that sched_clock() overflows after 208.5 days. Does anyone know if Scientific 6 is also susceptible? I would think so.
PM
^
synflag
 Posted: Feb 29 2012, 05:14 AM
Quote Post


SLF Rookie
*

Group: Members
Posts: 24
Member No.: 1281
Joined: 11-February 12









QUOTE (gargunkle @ Jan 24 2012, 04:02 PM)
I'm not sure if I am legally allowed to copy and paste their article (probably not) :

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

The gist of it is that sched_clock() overflows after 208.5 days.  Does anyone know if Scientific 6 is also susceptible?  I would think so.


No idea, but, i can't see the document ( i no have a RHEL account), only a FAS Fedora and bugzilla.
The RHEL guys are angry with this bug, i have a bugzilla account and i reported a lot of security bugs, but...

You are not authorized to access bug #765720. blink.gif

I read that is a bug introduced in 2.6.28 kernel and fixed in 2.6.32.50, and affect only Intel CPU and TSC clocksource.
Please, copy&paste the doc here, or PM or Mail.

The patch http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=patch;h=4cecf6d401a01d054afc1e5f605bcbfe553cb9b9

Actually fixed: https://rhn.redhat.com/errata/RHBA-2012-0124.html

Note: This update fixes the following bug:

* An insufficiently designed calculation in the CPU accelerator in the previous
kernel caused an arithmetic overflow in the sched_clock() function when system
uptime exceeded 208.5 days. This overflow led to a kernel panic on the systems
using the Time Stamp Counter (TSC) or Virtual Machine Interface (VMI) clock
source. This update corrects the aforementioned calculation so that this
arithmetic overflow and kernel panic can no longer occur under these
circumstances. (BZ#781974)

Red Hat Enterprise Linux Desktop (v. 6)
SRPMS:
kernel-2.6.32-220.4.2.el6.src.rpm MD5: 0a8fba184673bbd2add648e9c14cce28
SHA-256: 50e961d4633b83a79c77379e713b250ad4c1187bcd6b621ff7cac9e975d0e3c6

Is the actual kernel for SL6.1 and 6.2, fixed.
SynFlag


--------------------
AMD Phenom x4 945 3.0Ghz - 8Gb Ram DDR3-1600 GSKILL RIPJAWS - 2 HDD 500GB WD SATAII - Thermaltake Toughpower 700 - Thermaltake V9 Black - LG LED 19" // Windows 7 Ultimate x86_64 (for games only), Fedora 16 x86_64
-------------------------------------------------------------------------------------------------------------------------------
Lenovo Thinkpad T400 Intel P8600 - 500GB SATAII - 4GB DDR3-1066 // SL6.2, Windows 7 Ultimate x86_64 (games and security test)
PMUsers Website
^
lemonzest
 Posted: Feb 29 2012, 08:18 AM
Quote Post


SLF Member
***

Group: Members
Posts: 144
Member No.: 109
Joined: 29-April 11









this is fixed in kernel 2.6.32-220.4.2, its in fastbugs


--------------------
Desktop: Phenom II X6 1090T Hex-Core (Socket AM3), 16GB RAM, MSI 870-C45, 5x 1TB HDD, Radeon HD 6770 1GB, Mageia 2 x86_64

Test Box:Intel Pentium E2180 (Socket 775), 4GB DDR3, ASRock G41-VS3 2.0, 4x 1TB, 2x 500GB, Onboard GFX, Mageia 2 x86_64

Connection: Virgin Media XL 60Mb/s Down, 3Mb/s Up
PM
^
0 User(s) are reading this topic (0 Guests and 0 Anonymous Users)
0 Members:

Topic Options Reply to this topicStart new topicStart Poll