Bug 456225

Summary: clocksource modules not built on x86_64
Product: Red Hat Enterprise Linux 5 Reporter: Prarit Bhargava <prarit>
Component: kernelAssignee: Prarit Bhargava <prarit>
Status: CLOSED WONTFIX QA Contact: Martin Jenner <mjenner>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: bmaly, dzickus, jburke, lwang, peterm
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-23 17:54:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Prarit Bhargava 2008-07-22 12:12:15 UTC
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.

Comment 2 Prarit Bhargava 2008-07-22 12:16:20 UTC
RHTS job information that lead to this BZ being filed:

http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=25597

P.

Comment 3 Peter Martuccelli 2008-07-22 16:40:20 UTC
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.

Comment 4 Prarit Bhargava 2008-07-22 16:58:27 UTC
I'll take a look at the code this week.  This is just some sort of
Makefile/Kconfig breakage.

P.

Comment 5 Prarit Bhargava 2008-07-23 15:23:29 UTC
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.

Comment 6 Prarit Bhargava 2008-07-23 15:40:19 UTC
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.