Quoting [EMAIL PROTECTED]: > Quoting Stefan Reinauer <[EMAIL PROTECTED]>: > >> 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 -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
