Hi,
I just patched my kernel and here are my results:
> systems. Please apply and give me the "IRQ to pin mappings:" part of the
> bootstrap log. I'm pretty confident we get everything fine there, but
> just in case...
0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ12 -> 0:12
IRQ16 -> 1:0
IRQ17 -> 1:1
IRQ20 -> 1:4
IRQ24 -> 1:8
IRQ25 -> 1:9
Just curious : what do these numbers on the right refer to ? Are they
real physical pins of the processor ?
> Patch-2.4.0-test11-pic_debug-0 fetches as much as possible from chips
> involved in IRQ handling. Most of the code is already in place -- the
> patch only adds another magic SysRq command (credit goes for Andrew Morton
> for the idea). Please apply the patch and provide me the output of
> SysRq+A (you need to have MAGIC_SYSRQ enabled) as caught just after a
> bootstrap and then after you notice the timer IRQ counter no longer
> advances. I strongly suspect some software (be it XFree86 or not) enables
> one of the 8259A inputs which should remain disabled. This would lead to
> symptoms as you describe due to the special 8259A setup we use when the
> workaround is in use.
Here are both outputs:
Just after bootstrap:
Nov 27 16:51:35 pc8-118 kernel: SysRq:
Nov 27 16:51:35 pc8-118 kernel: print_PIC()
Nov 27 16:51:35 pc8-118 kernel: printing PIC contents
Nov 27 16:51:35 pc8-118 kernel: print_IO_APIC()
Nov 27 16:51:35 pc8-118 kernel: testing the IO APIC.......................
Nov 27 16:51:35 pc8-118 kernel:
Nov 27 16:51:35 pc8-118 kernel:
Nov 27 16:51:35 pc8-118 kernel: .................................... done.
Nov 27 16:51:35 pc8-118 kernel: print_all_local_APICs()
Nov 27 16:51:35 pc8-118 kernel:
Nov 27 16:51:35 pc8-118 kernel: ... APIC ID: 03000000 (3)
Nov 27 16:51:35 pc8-118 kernel: ... APIC VERSION: 00040011
Nov 27 16:51:35 pc8-118 kernel: 00000000000000000000000000000000
Nov 27 16:51:35 pc8-118 last message repeated 9 times
Nov 27 16:51:35 pc8-118 kernel: 00000000010000000100000000000000
Nov 27 16:51:35 pc8-118 kernel: 00000000000000000000000000000000
Nov 27 16:51:35 pc8-118 last message repeated 2 times
Nov 27 16:51:35 pc8-118 kernel: 00000000000000000100000000000000
Nov 27 16:51:35 pc8-118 kernel: 00000000000000000000000000000000
Nov 27 16:51:35 pc8-118 last message repeated 4 times
Nov 27 16:51:35 pc8-118 kernel: 00000000000000010000000000000000
Nov 27 16:51:35 pc8-118 kernel:
Nov 27 16:51:35 pc8-118 kernel:
Nov 27 16:51:35 pc8-118 kernel: ... APIC ID: 00000000 (0)
Nov 27 16:51:35 pc8-118 kernel: ... APIC VERSION: 00040011
Nov 27 16:51:35 pc8-118 kernel: 00000000000000000000000000000000
Nov 27 16:51:35 pc8-118 last message repeated 9 times
Nov 27 16:51:35 pc8-118 kernel: 00000000010000000100000000000000
Nov 27 16:51:35 pc8-118 kernel: 00000000000000000000000000000000
Nov 27 16:51:35 pc8-118 last message repeated 8 times
Nov 27 16:51:35 pc8-118 kernel: 00000000000000010000000000000000
Nov 27 16:51:35 pc8-118 kernel:
And then a quite different one after the locks:
Nov 27 17:10:57 pc8-118 kernel: SysRq:
Nov 27 17:10:57 pc8-118 kernel: print_PIC()
Nov 27 17:10:57 pc8-118 kernel: printing PIC contents
Nov 27 17:10:57 pc8-118 kernel: print_IO_APIC()
Nov 27 17:10:57 pc8-118 kernel: testing the IO APIC.......................
Nov 27 17:10:57 pc8-118 kernel:
Nov 27 17:10:57 pc8-118 kernel:
Nov 27 17:10:57 pc8-118 kernel: .................................... done.
Nov 27 17:10:57 pc8-118 kernel: print_all_local_APICs()
Nov 27 17:10:57 pc8-118 kernel:
Nov 27 17:10:57 pc8-118 kernel: ... APIC ID: 00000000 (0)
Nov 27 17:10:57 pc8-118 kernel: ... APIC VERSION: 00040011
Nov 27 17:10:57 pc8-118 kernel: 00000000000000000000000000000000
Nov 27 17:10:57 pc8-118 last message repeated 9 times
Nov 27 17:10:57 pc8-118 kernel: 00000000010000000100000000000000
Nov 27 17:10:57 pc8-118 kernel: 00000000000000000000000000000000
Nov 27 17:10:57 pc8-118 last message repeated 9 times
Nov 27 17:10:57 pc8-118 kernel:
Nov 27 17:10:57 pc8-118 kernel:
Nov 27 17:10:57 pc8-118 kernel: ... APIC ID: 03000000 (3)
Nov 27 17:10:57 pc8-118 kernel: ... APIC VERSION: 00040011
Nov 27 17:10:57 pc8-118 kernel: 00000000000000000000000000000000
Nov 27 17:10:57 pc8-118 last message repeated 9 times
Nov 27 17:10:57 pc8-118 kernel: 00000000010000000100000000000000
Nov 27 17:10:57 pc8-118 kernel: 00000000000000000000000000000000
Nov 27 17:10:57 pc8-118 last message repeated 8 times
Nov 27 17:10:57 pc8-118 kernel: 00000000000000010000000000000000
Nov 27 17:10:57 pc8-118 kernel:
Now this looks really cryptic to me.
Both outputs are different.
- They are in displayed in a different order :
APIC 3 then 0 before lock and APIC 0 then 3 after the lock.
- Last line of the APIC 0 differ on one bit :
Before lock 00000000000000010000000000000000
After lock 00000000000000000000000000000000
- Line 15 of APIC 3 differ :
Before lock 00000000000000000100000000000000
After lock 00000000000000000000000000000000
> I am trying to pull documentation from ServerWorks -- they appear not to
> want to share them with everyone. From marketing brochures available on
> their web site I found out their chipsets feature integrated I/O APICs
> which makes me quite suspicious the original problem with the timer IRQ
> routing (i.e. not the secondary one you observe when the workaround gets
> activated) lies in the chipset setup.
The only informations that I can read in the manual are :
ServerWorks LE 3.0 Chipset: features the ServerWorks LE 3.0 North
Bridge and RCC Open South Bridge.
Integrated IOAPIC: Supports full 32-APIC entries and removes the need
for a separate IOAPIC chip. <<<< the source of the original problem ?
I will try to find some technical specification on the web.
Thank you.
-- | Benjamin Monate | LRI - Bât. 490 | Université de Paris-Sud- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 30 2000 - 21:00:17 EST