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

[Ben Woodard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Horman wrote:
> On Fri, Dec 07, 2007 at 11:36:58AM -0700, Eric W. Biederman wrote:
>> Neil Horman <nhorman at redhat.com> writes:
>>
>>> this seems reasonable, I can reroll the patch for this.  As I think about it I'm
>>> also going to update the patch to make this check occur for any pci class 0600
>>> device from vendor AMD, since its possible that more than just nvidia chipsets
>>> can be affected.
>>>
>>> I'll repost as soon as I've tested, thanks!
>> Thanks.
>>
>> Neil in your testing please confirm the preconditions for setting 
>> the Apic Extended Broadcast flag (bit 17) are present.
>>
> The systems that I have here do _not_ in fact have that precondition, but the
> systems from Ben, who originoally reported the problem do have that
> precondition, and he has reported that this fixes the hang in the kdump boot.
> 
>> If that is the case it makes sense to always set that bit on conforming
>> systems but we will also want to print a message noting that the
>> BIOS has a bug, and we are working around it.
>>
> I've got two printk's in this patch, one that indicates that Extended APIC ID's
> are in use, and a second that indicates that there is a mismatch between the use
> of extended APIC ids (bit 18) and the lack of an extended APIC id dest mask for
> interrupt packets (bit 17).  Not sure if that meets you're requirements, but I
> think its sufficient.  If you disagree, let me know and we can enhance them.
> 
> Thanks
> Neil
> 
Is enough to say if the machine has 8 cpus and it is using a broadcast
of 0x0f then there is a BIOS bug?

- -ben

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHXZXrugekqaRDL9cRAvkUAKCBLq+vXPqjOgDxD+tsYRU8W2rDwgCfR8S/
K9B5vS1dwGZxeMeMceSxpdE=
=9oKY
-----END PGP SIGNATURE-----