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

[Andi Kleen]

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