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 2. build Actual results: (I started with a previously built tree ...) [root@dell-pe2900-03 linux-2.6.18.x86_64]# make -j8 CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h Building modules, stage 2. Kernel: arch/x86_64/boot/bzImage is ready (#4) MODPOST [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 CONFIG_X86_PM_TIMER=y [root@dell-pe2900-03 linux-2.6.18.x86_64]# 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 /sys/devices/system/clocksource/clocksource0/available_clocksource 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. P.
RHTS job information that lead to this BZ being filed: http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=25597 P.
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 Makefile/Kconfig breakage. P.
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 i386. I'll see how big of a backport is required -- hopefully, not much. P.
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': /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64/kernel/timer.c:994: multiple definition of `do_gettimeofday' arch/x86_64/kernel/built-in.o:/usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64/arch/x86_64/kernel/time.c:137: 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': /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64/kernel/timer.c:1010: multiple definition of `do_settimeofday' arch/x86_64/kernel/built-in.o:/usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64/arch/x86_64/kernel/time.c:168: 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. Thoughts/concerns? P.