Description of problem:
The clocksource modules are supposed to built on x86_64. They are "y" in the
.config but are not being compiled for some reason. They are being correctly
built on i386.
Version-Release number of selected component (if applicable): 98.el5
How reproducible: AFAICT, 100%.
Steps to Reproduce:
1. unpack source
Actual results: (I started with a previously built tree ...)
[root@dell-pe2900-03 linux-2.6.18.x86_64]# make -j8
Building modules, stage 2.
Kernel: arch/x86_64/boot/bzImage is ready (#4)
[root@dell-pe2900-03 linux-2.6.18.x86_64]# cat drivers/clocksource/Makefile
obj-$(CONFIG_X86_CYCLONE_TIMER) += cyclone.o
obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
obj-$(CONFIG_SCx200HR_TIMER) += scx200_hrt.o
[root@dell-pe2900-03 linux-2.6.18.x86_64]# ls -l drivers/clocksource/*.o
ls: drivers/clocksource/*.o: No such file or directory
[root@dell-pe2900-03 linux-2.6.18.x86_64]# cat .config | grep PM_TIMER
Expected results: clocksource modules should compile and be included as built-in.
Additional info: AFAICT, this has very light functional impact. The x86_64
arch-specific time code (arch/x86_64/kernel/time.c) is the code currently being
used to decide what timer to use -- not the clocksource drivers.
However, as jburke will point out ;), the sysfs file
will not show the correct information. It is possible therefore that an
application may make an incorrect decision on performance based on reading the file.
Currently, x86_64 *always* will show "jiffies" as the value for
available_clocksource, whereas i386 will show all potential values for the
available_clocksource, ie) "acpi_pm jiffies hpet tsc".
I'm undecided as to how critical this. AFAICT, this has low impact in terms of
system behavior. OTOH, we are supposed to be building these modules.
Peter, Linda -- care to weigh in? I'm not sure what the impact of turning on
these drivers at this time will be.
RHTS job information that lead to this BZ being filed:
I would proceed with making the change, it is a known problem and we should
address the issue to keep x86/x86_64 in sync. I am not concerned with the clock
source selection code path, it should not be affected.
I'll take a look at the code this week. This is just some sort of
Well ... I figured out why this isn't building on x86_64. It's because
CONFIG_GENERIC_TIME isn't defined. Even with that, there are other functions
that are undefined on x86_64 (ex. mark_tsc_unstable() ) that are defined within
I'll see how big of a backport is required -- hopefully, not much.
There are a lot of conflicts between the the arch/x86_64 code and the
clocksource code -- it will take significant hacks to make this compile, and
even then, x86_64 only has code for the acpi_pm.
After fixing the issue with mark_tsc_unstable() we end up with
kernel/built-in.o: In function `do_gettimeofday':
multiple definition of `do_gettimeofday'
first defined here
ld: Warning: size of symbol `do_gettimeofday' changed from 143 in
arch/x86_64/kernel/built-in.o to 157 in kernel/built-in.o
kernel/built-in.o: In function `do_settimeofday':
multiple definition of `do_settimeofday'
first defined here
ld: Warning: size of symbol `do_settimeofday' changed from 215 in
arch/x86_64/kernel/built-in.o to 251 in kernel/built-in.o
drivers/built-in.o:(.data.read_mostly+0x28): multiple definition of `pmtmr_ioport'
arch/x86_64/kernel/built-in.o:(.data.read_mostly+0x5174): first defined here
make: *** [.tmp_vmlinux1] Error
I suggest changing this to WONTFIX. Unless we're willing to do a large backport
of code that has no purpose in RHEL, I can't see the benefit to fix the output
of that one /sys file.