Some systems incorrectly report the ExtINTA pin of the I/O APIC as the

genuine target of the timer interrupt.  Here is a change that copies timer

pin information found to the other pin if one has been found only.  This

way both a direct and a through-8259A route is tested with the pin letting

these problematic systems work well enough.  If no timer pin information

has been found for the I/O APIC, then local APIC variations are tried

only, similarly to what is done without the change (except without the

misleading messages).
 Obviously if we try the first-chance path without being told by the BIOS

to do so, we should not complain either, so do not print the message in

this case.
 The 64-bit variation should be updated with a call to

replace_pin_at_irq() which can be done with the upcoming merge.  Since

add_pin_to_irq() is now always called in the first-chance path, the

condition to require it in the second-chance path no longer happens.  
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>

---

Ingo,
 Despite looking quite innocent, this is the most intrusive modification

in the series.  I tested this change (on top of all the other 14 ones)

with as many variations of interrupt wiring configuration as I could

imagine and simulate with my system.  Of course my machine is perfectly

unbroken, :) so chances are more exotic convolutions may have escaped my

attention.  Also I tested the 32-bit variation only.  So again, I

recommend a good amount of testing in the field before this patch is

propagated upstream.
  Maciej
patch-2.6.26-rc1-20080505-timer-pins-2

diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_32.c linux-2.6.26-rc1-20080505/arch/x86/kernel/io_apic_32.c

--- linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_32.c	2008-05-25 22:24:53.000000000 +0000

+++ linux-2.6.26-rc1-20080505/arch/x86/kernel/io_apic_32.c	2008-05-27 19:42:31.000000000 +0000

@@ -2122,6 +2122,7 @@ static inline void __init unlock_ExtINT_

 stati...
[ message continues ]

applied all 15 APIC patches of yours to tip/x86/apic, thanks Maciej!
	Ingo

--

Maciej,
-tip testing found an IO-APIC related hang, and i bisected it down to

the problem below. What do you think about my solution? Another option

would be to add the lapic as a clockevent device in the failure path.

(since we know the NMI watchdog wont work)
	Ingo
------------>

Subject: x86, io-apic: fix nmi_watchdog=1 bootup hang

From: Ingo Molnar <mingo@elte.hu>
nmi_watchdog=1 hangs on 64-bit:
[    0.250000] Detected 12.564 MHz APIC timer.

[    0.254178] APIC timer registered as dummy, due to nmi_watchdog=1!

[    0.260366] Testing NMI watchdog ... <4>WARNING: CPU#0: NMI appears to be stuck (0->0)!

[    ...     ]

[    0.470003] calling  genl_init+0x0/0xd0

[  hard hang ]
bisected it down to:
 git-bisect start

 git-bisect good 1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2

 git-bisect bad 11582ece0aaa2d0f94f345c08a4ab9997078a083

 git-bisect bad 5479c623bb44089844022c03d4c0eb16d5b7a15f

 git-bisect bad cfb4c7fabeb499e1c29f9d1878968e37a938e28a

 git-bisect good 246dd412d31e4f5de1d43aa6422a325b785f36e4

 git-bisect bad 3f8237eaff7dc1e35fa791dae095574fd974e671

 git-bisect good 90e23b13ab849e2a11f00c655eb3a2011b4623be

 git-bisect bad 833526a34eeefc117df3191a594c3c3a4f15a9ac

 git-bisect good 791b93d3dfaf16c23e978bec0cc0a3dd9d855d63

 git-bisect bad 65767c64068f2c93e56a1accfed5c78230ac12d7

 git-bisect bad 2abc5c05dd82c188e3bdf6641a274f013348d14b

 git-bisect bad 317e1f2597ffb4d4db940577bbe56dc6e881ef07
| 317e1f2597ffb4d4db940577bbe56dc6e881ef07 is first bad commit

| commit 317e1f2597ffb4d4db940577bbe56dc6e881ef07

| Author: Maciej W. Rozycki <macro@linux-mips.org>

| Date:   Wed May 21 22:10:22 2008 +0100

|     x86: I/O APIC: clean up the 8259A on a NMI watchdog failure
the problem is that in the dummy-lapic branch we rely on the i8259A

but if the NMI watchdog fails we turn off IRQ 0 - which doesnt work

too well ;-)
Signed-off-by: Ingo Molnar <mingo@elte.hu>

---

 arch/x86/kernel/apic_32.c |    6 ++++--

 arch/x86/kernel/apic_64.c |    6 ...
[ message continues ]

It seems wrong to me to set timer_through_8259 in apic_{32,64}.c -- can I

get .config for this setup as well as the bootstrap log?  Why is the 8259A

needed here to supply the timer interrupt?  It shouldn't be needed except

as arranged in check_timer() -- elsewhere the corresponding I/O APIC input

is not set up correctly.
 Note I have chosen the default value of timer_through_8259 deliberately

to trigger dodgy cases like this ;) so that they can be investigated.
  Maciej

--

find them here:
 http://redhat.com/~mingo/misc/config-Thu_Jun__5_16_40_50_CEST_2008.bad

 http://redhat.com/~mingo/misc/log-Thu_Jun__5_16_40_50_CEST_2008.bad
NOTE: you need to copy out and use the boot parameters from the boot

log:
 [ 0.000000] Command line: root=/dev/sda6 console=ttyS0,115200

 earlyprintk=se rial,ttyS0,115200 debug initcall_debug apic=verbose

 sysrq_always_enabled ignore _loglevel selinux=0 nmi_watchdog=1

 profile=0 maxcpus=1 nosmp no_hz=off highres =0 noapic nolapic_timer

 hpet=disable idle=mwait
as -tip testing occasionally randomizes boot parameters too. (to find

regressions like this) Let me know if you cannot reproduce this.
	Ingo

--

Thanks.  I figured out I cannot build an x86-64 kernel, because my i386

compiler does not support the target.  Probably because of target library

dependencies at the time I built my compiler.  I would have to build a

bare-iron cross-compiler for the x86-64 which I'd rather not to just to

fix this small problem -- it usually takes a few days to sort out all the

pesky details when doing such a build from scratch, so it better be well

justified.
 However, the reason is quite clear to me -- the command line specifies

"noapic" among others (there is also "nosmp", but probably overridden by

"maxcpus=1" -- I am afraid there is no clear precedence among these

options), so the bug is the I/O APIC NMI watchdog is tried at all.  This

is also clearly seen from the log where the I/O APIC is not set up at all.  
 A fix along the lines of what I implemented for "nosmp" in the

"nosmp-watchdog" patch is needed which I will post shortly.  It's needed

both for the i386 and the x86-64 target; hopefully the latter does not

differ too much from the former.
  Maciej

--

[Maciej W. Rozycki - Thu, Jun 05, 2008 at 07:33:04PM +0100]

| On Thu, 5 Jun 2008, Ingo Molnar wrote:

|

| > NOTE: you need to copy out and use the boot parameters from the boot

| > log:

| >

| >  [ 0.000000] Command line: root=/dev/sda6 console=ttyS0,115200

| >  earlyprintk=se rial,ttyS0,115200 debug initcall_debug apic=verbose

| >  sysrq_always_enabled ignore _loglevel selinux=0 nmi_watchdog=1

| >  profile=0 maxcpus=1 nosmp no_hz=off highres =0 noapic nolapic_timer

| >  hpet=disable idle=mwait

| >

| > as -tip testing occasionally randomizes boot parameters too. (to find

| > regressions like this) Let me know if you cannot reproduce this.

|

|  Thanks.  I figured out I cannot build an x86-64 kernel, because my i386

| compiler does not support the target.  Probably because of target library

| dependencies at the time I built my compiler.  I would have to build a

| bare-iron cross-compiler for the x86-64 which I'd rather not to just to

| fix this small problem -- it usually takes a few days to sort out all the

| pesky details when doing such a build from scratch, so it better be well

| justified.

|

|  However, the reason is quite clear to me -- the command line specifies

| "noapic" among others (there is also "nosmp", but probably overridden by

| "maxcpus=1" -- I am afraid there is no clear precedence among these

| options), so the bug is the I/O APIC NMI watchdog is tried at all.  This

| is also clearly seen from the log where the I/O APIC is not set up at all.

|

|  A fix along the lines of what I implemented for "nosmp" in the

| "nosmp-watchdog" patch is needed which I will post shortly.  It's needed

| both for the i386 and the x86-64 target; hopefully the latter does not

| differ too much from the former.

|

|   Maciej

| 
Btw, just for the record: my hang was exactly on same line as Ingo reported:
static int __init pci_acpi_init(void) {

...

	printk(KERN_INFO "PCI: Using ACPI for IRQ routing\n");

...

}
well, Ingo had a few...
[ message continues ]

[Maciej W. Rozycki - Thu, Jun 05, 2008 at 07:33:04PM +0100]

| On Thu, 5 Jun 2008, Ingo Molnar wrote:

|

| > NOTE: you need to copy out and use the boot parameters from the boot

| > log:

| >

| >  [ 0.000000] Command line: root=/dev/sda6 console=ttyS0,115200

| >  earlyprintk=se rial,ttyS0,115200 debug initcall_debug apic=verbose

| >  sysrq_always_enabled ignore _loglevel selinux=0 nmi_watchdog=1

| >  profile=0 maxcpus=1 nosmp no_hz=off highres =0 noapic nolapic_timer

| >  hpet=disable idle=mwait

| >

| > as -tip testing occasionally randomizes boot parameters too. (to find

| > regressions like this) Let me know if you cannot reproduce this.

|

|  Thanks.  I figured out I cannot build an x86-64 kernel, because my i386

| compiler does not support the target.  Probably because of target library

| dependencies at the time I built my compiler.  I would have to build a

| bare-iron cross-compiler for the x86-64 which I'd rather not to just to

| fix this small problem -- it usually takes a few days to sort out all the

| pesky details when doing such a build from scratch, so it better be well

| justified.

|

|  However, the reason is quite clear to me -- the command line specifies

| "noapic" among others (there is also "nosmp", but probably overridden by

| "maxcpus=1" -- I am afraid there is no clear precedence among these

| options), so the bug is the I/O APIC NMI watchdog is tried at all.  This

| is also clearly seen from the log where the I/O APIC is not set up at all.

|

|  A fix along the lines of what I implemented for "nosmp" in the

| "nosmp-watchdog" patch is needed which I will post shortly.  It's needed

| both for the i386 and the x86-64 target; hopefully the latter does not

| differ too much from the former.

|

|   Maciej

| 
Since I've got the same hang by using qemu - i think i could test ;)
		- Cyrill -

--

I can reproduce the hang, except with a slightly different options.  I

have spotted the places where the watchdog is set up incorrectly.  I shall

post fixes shortly, once I have got them polished and tested.  Feel free

to throw them at your qemu.
 Also it's worth noting there's more breakage of the NMI watchdog for this

configuration ("maxcpus=1 noapic") -- it fails to tick on the CPU #0 on my

system for some reason, but that's well beyond the scope of this series,

so I am not going to look into it.
  Maciej

--