The URL for the Cox/Weinigel thread about PIRQ tables on the geode gx1 is at: http://lkml.org/lkml/2002/7/5/104
I'm doing a little bit more analysis of the problem now. I've been looking at the following block of code from 2.6.10's pci/irq.c. First of all, LB states this during bootup: --- Checking IRQ routing tables... /bios/freebios/src/arch/i386/lib/pirq_routing.c: 30:check_pirq_routing_table() - irq_routing_table located at: 0x00008740 done. Copying IRQ routing tables to 0xf0000...done. Verifing priq routing tables copy at 0xf0000...failed Wrote linuxbios table at: 00000500 - 00000664 checksum f9fe --- I'm not sure why the copy to 0xf0000 failed. That's kinda odd but I'll live with it for now. Now, I put some debug in the kernel code to see whether it found the pirq table and I saw: --- no pirq_table so calling pcibios_get_irq_routing_table pirq_table=00000000 --- coming from pcibios_irq_init. So based on the code appended below, I believe that the kernel isn't finding the pirq table. And I think this is because the kernel's pirq_find_routing_table function only looks from __va(0xf0000) to __va(0x100000) whereas LB puts it at 0000500. The second attempt that the kernel makes to get the PIRQ table is with pcibios_get_irq_routing_table and that fails too. I need to look at that, but first I think I'll look into why the copy to f0000 fails. In the meantime, any advice? --- static int __init pcibios_irq_init(void) { DBG("PCI: IRQ init\n"); if (pcibios_enable_irq || raw_pci_ops == NULL) return 0; dmi_check_system(pciirq_dmi_table); pirq_table = pirq_find_routing_table(); #ifdef CONFIG_PCI_BIOS if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN)) { printk(KERN_WARNING "no pirq_table so calling pcibios_get\n"); pirq_table = pcibios_get_irq_routing_table(); printk(KERN_WARNING "pirq_table=%p\n",pirq_table); } #endif if (pirq_table) { printk(KERN_WARNING "had pirq_table\n"); pirq_peer_trick(); pirq_find_router(&pirq_router); if (pirq_table->exclusive_irqs) { int i; for (i=0; i<16; i++) if (!(pirq_table->exclusive_irqs & (1 << i))) pirq_penalty[i] += 100; } /* If we're using the I/O APIC, avoid using the PCI IRQ routing table */ if (io_apic_assign_pci_irqs) { printk(KERN_WARNING "using io_apic to assign irqs\n"); pirq_table = NULL; } } pcibios_enable_irq = pirq_enable_irq; pcibios_fixup_irqs(); return 0; } --- --- "Ronald G. Minnich" <rminnich@lanl.gov> wrote: > > > On Tue, 1 Mar 2005, Richard Smith wrote: > > > I've found that Linux up to 2.6.9 (I haven't > tested .10) Dosen't do > > this fully. With my 440bx chipset there are > config registers in the > > northbridge that control which IRQ line each of > the PCI PIRQ lines are > > routed to. Even with a proper PIRQ table these > registers are not setup > > and I get the same error reported. > > that's whacky. The old linux did fine with 440bx. I > never had to do > anything but set up PIRQ tables. > > > I suggest you diff the output of lspci -xxx for > the northbridge between > > linubios and factory bios and resolve all the > differences with the > > datasheet. > > on the geode 2.4.18 always worked, and if I patched > linux for later > linuxes, that worked fine too. > > What a mess PIRQ got to be .... > > ron > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios