Bug 8048 - kernel >=2.6.20 breaks glibc-2.4 test for process and thread CPU clocks
Summary: kernel >=2.6.20 breaks glibc-2.4 test for process and thread CPU clocks
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Timers
Classification: Unclassified
Component: Realtime Clock (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Thomas Gleixner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-21 07:09 UTC by gabriele balducci
Modified: 2007-02-22 07:26 UTC (History)
0 users

See Also:
Kernel Version: 2.6.20.1
Tree: Mainline
Regression: ---


Attachments
test code from the glibc-2.4 distribution (18.90 KB, text/plain)
2007-02-21 07:11 UTC, gabriele balducci
Details
diff .config-2.6.19.2 .config-2.6.20.1 (1.85 KB, text/plain)
2007-02-21 07:13 UTC, gabriele balducci
Details

Description gabriele balducci 2007-02-21 07:09:14 UTC
Most recent kernel where this bug did *NOT* occur: 2.6.19.2
Distribution: Debian 3.4.3-13sarge1, redhat-7.1
Hardware Environment: AMD Sempron(tm)Processor3200+
                      Intel(R)Pentium(R)4CPU 2.40GHz
Software Environment:  Linux version 2.6.19.2/2.6.20/2.6.20.1
Problem Description:

The attached code is taken out of the glibc-2.4 distribution. It tests
for process and thread CPU clocks. It can be compiled with:

gcc  -DNOT_IN_libc=1  -D_LIBC_REENTRANT  tst-cpuclock2.c  \
-std=gnu99  -O2  -Wall  -Winline  -Wwrite-strings  \
-fmerge-all-constants  -g  -Wstrict-prototypes  \
-mpreferred-stack-boundary=2  -o tst-cpuclock2  -lrt -lpthread

on a system where glibc-2.4 is already installed, or, if glibc-2.4 is
not installed, it must be compiled and run taking the commands out of
the glibc compilation process.


Under kernel 2.6.20 or 2.6.20.1 (the latest stable version as of this
writing) the test fails with this output:

live thread clock fffd4106 resolution 0.000000001
live thread before sleep => 0.001102304
self thread before sleep => 0.001196569
live thread after sleep => 0.503401861
self thread after sleep => 0.503433057
self thread before - after 502236488 outside reasonable range
clock_nanosleep on process slept 415477963 (outside reasonable range)
clock_nanosleep on PROCESS_CPUTIME_ID slept 207755581 (outside reasonable range)


However, after rebooting with kernel-2.6.19.2 (all the rest unchanged), the
same executable succeeds with:

live thread clock ffffc32e resolution 0.000000001
live thread before sleep => 0.002691102
self thread before sleep => 0.000352153
live thread after sleep => 0.507034081
self thread after sleep => 0.000367131


This behaviour is reproducible and is obtained on two different
machines.

I attach also the 2.6.19.2/2.6.20.1 .config diffs, in case I have
misconfigured something during kernel upgrade.


From the above I tend to think that the problem might be on the kernel
side (as opposed to glibc side): unfortunately, I'm not in the
position to go deeper.

Steps to reproduce:

=> If glibc-2.4 is already installed:

   Compile the tst-cpuclock2.c code with:

     gcc  -DNOT_IN_libc=1  -D_LIBC_REENTRANT  tst-cpuclock2.c  \
     -std=gnu99  -O2  -Wall  -Winline  -Wwrite-strings  \
     -fmerge-all-constants  -g  -Wstrict-prototypes  \
     -mpreferred-stack-boundary=2  -o tst-cpuclock2  -lrt -lpthread

   and run it under kernel 2.6.19.2 and 2.6.20[.1]


=> If installed glibc version is < 2.4, build glibc-2.4 and run the
   tests:

     configure --enable-add-ons --prefix=/usr \
               --with-headers=/path/to/kernel/headers
     make
     make check
Comment 1 gabriele balducci 2007-02-21 07:11:37 UTC
Created attachment 10479 [details]
test code from the glibc-2.4 distribution
Comment 2 gabriele balducci 2007-02-21 07:13:18 UTC
Created attachment 10480 [details]
diff .config-2.6.19.2  .config-2.6.20.1
Comment 3 Thomas Gleixner 2007-02-21 15:57:28 UTC
Tracked it down. The cuplrit is commit:

b18ec80396834497933d77b81ec0918519f4e2a7

Need more sleep to look for a proper solution.

   tglx
Comment 4 Thomas Gleixner 2007-02-21 23:43:49 UTC
Can you please confirm, that it's solved ?
Comment 5 gabriele balducci 2007-02-22 00:04:37 UTC
Just recompiled [2.6.20.1 + patch] and rebooted: the test code runs without
problems, now.
Thanks

Note You need to log in before you can comment on or make changes to this bug.