On Mon, Dec 10, 2007 at 11:39:23AM -0800, Ben Woodard wrote: > -----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 <[EMAIL PROTECTED]> 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? > Its not strictly speaking, more than 8 cpus, its any case in which a system has a cpu that has an APIC id that doesn't fit into 4 bits.
And I would say that it likely is a bios bug in the event that we have APIC-ID's greater than what can fit in 4 bits, and the broadcast mask is set to only 0xf. The implication is that there are some cpu's that will never receive interrupts. While not fatal, it is certainly sub optimal, unless a specific design choice was made to do that, which would be a pretty application specific design I think. For a general purpose system, I can't see why you would restrict interrupts from being received on an arbitrary subset of processors. Neil > - -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----- > > _______________________________________________ > kexec mailing list > [email protected] > http://lists.infradead.org/mailman/listinfo/kexec -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
