Red Hat Bugzilla – Bug 125774
Typographical error in hardirq.h kernel source file
Last modified: 2007-04-18 13:08:49 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; T312461) Description of problem: if instead of ifdef used in linux-2.4.20-31.9/include/asm- i386/hardirq.h following is a patch --- linux-2.4.20-31.9/include/asm-i386/hardirq.h.orig Fri Jun 11 11:28:18 2004+++ linux-2.4.20-31.9/include/asm-i386/hardirq.h Fri Jun 11 11:28:22 2004@@ -14,7 +14,7 @@ struct task_struct * __ksoftirqd_task; /* waitqueue is too large */ unsigned long idle_timestamp; unsigned int __nmi_count; /* arch dependent */ -#if CONFIG_X86_LOCAL_APIC +#ifdef CONFIG_X86_LOCAL_APIC unsigned int apic_timer_irqs; /* arch dependent */ #endif } ____cacheline_aligned irq_cpustat_t; Version-Release number of selected component (if applicable): 2.4.20-31.9 How reproducible: Always Steps to Reproduce: 1.compile something that needs hardirq.h included 2. 3. Actual Results: wouldn't compile Expected Results: shaould have compiled Additional info: Patch as above in kernel source tree
RHL9 is no longer supported, sorry. Also, it does compile just fine using gcc. In fact, many of the drivers shipped in RHL9 included hardirq.h and they all compiled fine. You're not using icc, are you ? ;)
Interesting then that using gcc gives this error "/lib/modules/2.4.20- 31.9/build/include/asm/hardirq.h:17:33: #if with no expression" when compiling isn't it? I just thought that since it was your release of the kernel code that gives the error someone else might have encountered the same problem and wanted a quick fix. This error didn't occur while compiling the same modules (Compaq's cpqasm and cpqevt modules for the Proliant server series) with the 2.2 series of kernel (both RedHat's and kernel.org) or 2.4.7-10 (RedHat). The include file is wrong since adding three characters allows these modules to compile successfully....just my opinion of course, but that's the nature of GPL isn't it? And it's not a Redhat 9 issue per- se (unless RedHat now owns the kernel source code ;) ), but a kernel- 2.4.20 issue you'll probably find the same error in all 2.4.20 sources.