Stephen Rothwell | 1 Jul 01:30 2008

Re: linux-next: build failure

Hi Randy,

On Mon, 30 Jun 2008 08:49:12 -0700 Randy Dunlap <randy.dunlap <at>> wrote:
> On Mon, 30 Jun 2008 08:12:39 -0700 Randy Dunlap wrote:
> > All (ALL) of my randconfig builds on i386 and x86_64 are failing like this.
> I should have said:
> I'm using the daily patch*bz2 file, not git.
> And I'm using O= for output.
> When not using O=, the build does not have this problem.

Thanks for the report.  The patches are generated from the git tree so
should give you a tree with identical content.

I also use O= for all my builds.  Though my x86_64 allmodconfig builds


Stephen Rothwell                    sfr <at>
Maciej W. Rozycki | 1 Jul 02:11 2008

[PATCH 1/2] mpparse: Add a knob to disable IRQ 0 through I/O APIC

 As discovered recently some systems exhibit problems when the 8254 timer 
IRQ is routed through the I/O APIC.  These problems do not affect the 
timer IRQ itself and therefore cannot be detected when the correctness of 
operation of the interrupt is verified in check_timer().  Therefore the 
I/O APIC path of the timer IRQ has to be disabled entirely.

 This is a change that lets platforms ask for the timer IRQ not to be 
registered in the I/O APIC interrupt tables.  The local APIC and ExtINTA 
paths are unaffected.  This request is only taken into account for ACPI 
platforms as MP table systems seem unaffected so far.

Signed-off-by: Maciej W. Rozycki <macro <at>>
diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/mpparse.c linux-2.6.26-rc1-20080505/arch/x86/kernel/mpparse.c
--- linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/mpparse.c	2008-05-05 02:56:19.000000000 +0000
+++ linux-2.6.26-rc1-20080505/arch/x86/kernel/mpparse.c	2008-06-30 21:53:33.000000000 +0000
 <at>  <at>  -50,6 +50,8  <at>  <at>  static int mp_current_pci_id;

 int pic_mode;

+int disable_irq0_through_ioapic __initdata;
  * Intel MP BIOS table parsing routines:
 <at>  <at>  -887,6 +889,10  <at>  <at>  void __init mp_override_legacy_irq(u8 bu
 	int ioapic = -1;
 	int pin = -1;

(Continue reading)

Maciej W. Rozycki | 1 Jul 02:12 2008

[PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for some HP systems

From: Matthew Garrett <mjg59 <at>>

 Some HP laptops have a problem with their DSDT reporting as
HP/SB400/10000, which includes some code which overrides all temperature
trip points to 16C if the INTIN2 input of the I/O APIC is enabled.  This
input is incorrectly designated the ISA IRQ 0 via an interrupt source
override even though it is wired to the output of the master 8259A and
INTIN0 is not connected at all.  So far two models have been identified, 
namely nx6125 and nx6325.

 Use a knob provided by the I/O APIC interrupt registration code to
abandon any attempts to route IRQ 0 through the I/O APIC for these

Signed-off-by: Maciej W. Rozycki <macro <at>>

 Matthew, you have not added your sign-off with the original patch, please 
do so now.

 Rafael, please try this change together with 
patch-2.6.26-rc1-20080505-mpparse-acpi-noirq0-2 and see if this fixes your 

 I have tried the patches with a wildcard entry added to acpi_dmi_table[]
so that it trips for my system.  The result is as follows:

..TIMER: vector=0x31 apic1=-1 pin1=-1 apic2=-1 pin2=-1
(Continue reading)

Matthew Garrett | 1 Jul 02:17 2008

Re: [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for some HP systems

Assuming it works for Rafael (still haven't had time to pull my nx6125 
out of storage):

Signed-off-by: mjg <at>


Matthew Garrett | mjg59 <at>
Stephen Rothwell | 1 Jul 02:28 2008

Re: linux-next: ide tree build failure

hi Bart,

On Mon, 30 Jun 2008 20:38:20 +0200 Bartlomiej Zolnierkiewicz <bzolnier <at>> wrote:
> Thanks, I fixed the guilty patch.
> ditto :)



Stephen Rothwell                    sfr <at>
Stephen Rothwell | 1 Jul 02:34 2008

Re: [PATCH -next] fork and exit: need to include iocontext.h

On Mon, 30 Jun 2008 20:33:37 +0200 Ingo Molnar <mingo <at>> wrote:
> normally there's an easy way to find out the source commit of build 
> failures. Try something like:
>  git-bisect reset
>  git-bisect start
>  git-bisect good v2.6.26-rc8

More generally "git-bisect good linux-next/stable" - the stable branch is
just where I started on Linus' tree and that is always good :-)

>  git-bisect bad linux-next/master
>  git-bisect run make kernel/fork.o
> ... this should lead you to the commit that broke the build 
> automatically. (as long as everyone keeps make oldconfig compatibility)

Nice, I must try this.


Stephen Rothwell                    sfr <at>
Tony Breeds | 1 Jul 03:34 2008

Re: [BUILD-FAILURE] linux-next: Tree for June 30 - powerpc - build failure at arch_add_memory()

On Mon, Jun 30, 2008 at 11:55:02PM +0530, Kamalesh Babulal wrote:
> Hi Stephen,
> next-20080630 kernel build fails on powerpc, with randconfig
>   CC      arch/powerpc/mm/mem.o
> arch/powerpc/mm/mem.c: In function ‘arch_add_memory’:
> arch/powerpc/mm/mem.c:130: error: implicit declaration of function ‘create_section_mapping’
> make[1]: *** [arch/powerpc/mm/mem.o] Error 1
> make: *** [arch/powerpc/mm] Error 2

This problem exists in in 2.6.26-rc8, so it's not specifially linux-next
realted.  The patch at:
should fix it but is un-ACK'd ;P

Yours Tony
  Jan 19 - 24 2009 The Australian Linux Technical Conference!

To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo <at>
More majordomo info at

Vivek Goyal | 1 Jul 04:10 2008

Re: [BUILD-FAILURE] linux-next: Tree for June 30

On Mon, Jun 30, 2008 at 02:46:49PM -0700, H. Peter Anvin wrote:
> Here is a patch to replace the hard-coded limit with dynamic allocation.  
>  I have only build-tested it, but it seems to work.
> Please try it out; barring any screams to the contrary I'll add it to -tip.
> 	-hpa

I think there was no specific reason for limit 100. Just that probably at
that point Eric thought 100 is sufficient. Dynamic allocation is much

This patch looks good. Thanks.

Stephen Rothwell | 1 Jul 04:42 2008

linux-next: manual merge of the sched tree

Hi all,

Today's linux-next merge of the sched tree got a conflict in
kernel/sched.c between commit 040ec23d07f95285e9777a85cda29cb339a3065b
("sched: sched_clock() lockdep fix") from the  tree and commit
76a2a6ee8a0660a29127f05989ac59ae1ce865fa ("sched: sched_clock_cpu() based
cpu_clock()") from the sched tree.

The former updated some code that the latter removed.  I used the version
from the sched tree.

There was also a conflict in kernel/sched_rt.c between commit
363ab6f1424cdea63e5d182312d60e19077b892a ("core: use performance variant
for_each_cpu_mask_nr") from the cpus4096 tree and commit
eff6549b957d15d1ad168d90b8c1eb643b9c163f ("sched: rt: move some code
around") from the sched tree.

Again I took the version from the sched tree except for the
for_each_cpu_mask -> for_each_cpu_mask_nr transformation.


Stephen Rothwell                    sfr <at>
Stephen Rothwell | 1 Jul 04:56 2008

[PATCH] Introduce rculist.h

In linux-next there is a commit ("rcu: split list.h and move rcu-protected
lists into rculist.h") that moved the rcu related list iterators from
list.h to rculist.h.  Add a trivial version of the file now so that
various subsystem trees can start using it now for -next changes and so
reduce the build errors caused by adding uses of the moved functions.

Cc: Franck Bui-Huu <fbuihuu <at>>
Cc: Paul E. McKenney <paulmck <at>>
Cc: Josh Triplett <josh <at>>
Cc: Andrew Morton <akpm <at>>
Cc: Ingo Molnar <mingo <at>>
Signed-off-by: Stephen Rothwell <sfr <at>>
 include/linux/rculist.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/rculist.h

Linus, would you consider patches like this for 2.6.26 that have no
effect on the current tree but help with conflicts in various subsystems
during the next merge window?  I already have three build fixups for this
one in particular.

diff --git a/include/linux/rculist.h b/include/linux/rculist.h
new file mode 100644
index 0000000..bde4586
--- /dev/null
+++ b/include/linux/rculist.h
 <at>  <at>  -0,0 +1,6  <at>  <at> 
(Continue reading)