-----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-----
