Quoting joe@smittys.pointclark.net:
Quoting Stefan Reinauer stepan@coresystems.de:
Uwe Hermann wrote:
On Tue, Oct 16, 2007 at 06:31:19PM +0200, Stefan Reinauer wrote:
ron minnich wrote:
Factory bioses frequently ship with broken IRQ tables. The 'hlt' problem is a classic 'clock interrupts are not working' symptom. This is good (it's basic) and bad (it can be a bear to debug).
how do vendors get around their own broken tables in the fuctory bios? It appears they ignore them and just jam the correct bits into correct places. sad, but true. We see it all the time.
Vendors also ship with ACPI. As soon as Linux detects a reasonably complete ACPI implementation, it will not even look at IRQ tables anymore.
I'm curious, can we make the same assumptions for other payloads/OSes? Windows, *BSD, Solaris, Plan 9, OS/2 (yuck), DOS, OFW(?), whatever...
The assumption we can make is: either ACPI or MP+PIRQ have to be there. The other assumption is no "legacy" BIOS supports MP+PIRQ anymore. So the "legacy" stuff is only actively maintained in LinuxBIOS ;-)
Stefan
Ok, So I will dig into the irq tables and see what I can find. But, how do I now this isn't just related to a Read issue with the Upper Bios Area 0x0F0000(960K) - 0x0FFFFF(1MB)?? That is why I would like to diagnos that first. So I ask is there a way to dump (printk) this area in human readable format right after the check_pirq_routing_table() function?? Or if I can fudge my way to a linux command line with a whole bunch of work arounds can I dump it then to see the issue?
FYI: The original Bios does use ACPI for interrupt & irq routing. From the kernel booting:
ACPI: Subsystem revision 20040816 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 7 ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 7 (level, low) -> IRQ 7 ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 7 (level, low) -> IRQ 7 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5 ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 5 (level, low) -> IRQ 5 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9 ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 9 (level, low) -> IRQ 9 ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 10 ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 9 (level, low) -> IRQ 9 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 ACPI: PCI interrupt 0000:00:1f.3[B] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11 ACPI: PCI interrupt 0000:01:08.0[A] -> GSI 11 (level, low) -> IRQ 11
Thanks - Joe
Another quick thought. According to irc_tables.c the LPC Bridge is where
(0x1f<<3)|0x0, /* Where the interrupt router lies (dev) */
the interrupt router lies. Could there be a bad register setting messing this up??
Thanks - Joe