Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu

Andi Kleen
2007-12-12T16:07:36Z

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