On Wed, Dec 12, 2007 at 10:55:15AM -0500, Neil Horman wrote:
> On Wed, Dec 12, 2007 at 03:21:32PM +0100, Andi Kleen wrote:
> > > + htcfg = read_pci_config(num, slot, func, 0x68);
> > > + if (htcfg & (1 << 18)) {
> > > + printk(KERN_INFO "Detected use of extended apic ids on
> > > hypertransport bus\n");
> > > + if ((htcfg & (1 << 17)) == 0) {
> > > + printk(KERN_INFO "Enabling hypertransport extended apic
> > > interrupt broadcast\n");
> > > + printk(KERN_INFO "Note this is a bios bug, please
> > > contact your hw vendor\n");
> >
> > I'm not convinced the message is correct. e.g. on a system with only a dual
> > core not enabling
> > that is fine, but the extended IDs might be still set.
> >
> I'm not sure that would be fine. In the situation you describe, not setting
> this bit means the second core won't receive interrupts. If we crash on that
> core and boot the kdump kernel with it, we get exactly the same problem that
> we
> currently see.
It could enable the extended APIC IDs but not use them?
Anyways I haven't got docs on that NV bridge so I might be wrong.
> > > #endif /* CONFIG_ACPI */
> > >
> > > -static void __init nvidia_bugs(void)
> > > +static void __init nvidia_bugs(int num, int slot, int func)
> > > {
> > > + static int fix_applied = 0;
> > > +
> > > + if (fix_applied++)
> > > + return;
> >
> > This looks like the wrong place to do this. Better add a flag or something
> > in the structure. Dito others.
> >
> I suppose I can, but I'm not sure what benefit that provides. Can you
> elaborate?
The code would be smaller and cleaner.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
