From: ebiederm@xmission.com (Eric W. Biederman)
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Neil Horman <nhorman@redhat.com>,
Yinghai Lu <yhlu.kernel@gmail.com>,
Ben Woodard <woodard@redhat.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Andi Kleen <ak@suse.de>,
hbabu@us.ibm.com, Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu
Date: Mon, 10 Dec 2007 18:08:03 -0700 [thread overview]
Message-ID: <m1k5nm2g3w.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20071207175832.GA18485@hmsreliant.think-freely.org> (Neil Horman's message of "Fri, 7 Dec 2007 12:58:32 -0500")
Neil Horman <nhorman@tuxdriver.com> writes:
> On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
>> On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
>> > On Dec 7, 2007 12:50 AM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>> > >
>> > > On Dec 6, 2007 4:33 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> > ...
>> > > >
>> > > > My feel is that if it is for legacy interrupts only it should not be a
> problem.
>> > > > Let's investigate and see if we can unconditionally enable this quirk
>> > > > for all opteron systems.
>> > >
>> > > i checked that bit
>> > >
>> > >
> http://www.openbios.org/viewvc/trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/coherent_ht.c?revision=2596&view=markup
> <snip>
>> >
>> > it should be bit 18 (HTTC_APIC_EXT_ID)
>> >
>> >
>> > YH
>>
>> 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!
>> Neil
>
>
> Ok, New patch attached. It preforms the same function as previously described,
> but is more restricted in its application. As Yinghai pointed out, the
> broadcast mask bit (bit 17 in the htcfg register) should only be enabled, if the
> extened apic id bit (bit 18 in the same register) is also set. So this patch
> now check for that bit to be turned on first. Also, this patch now adds an
> independent quirk check for all AMD hypertransport host controllers, since its
> possible for this misconfiguration to be present in systems other than nvidias.
> The net effect of these changes is, that its now applicable to all AMD systems
> containing hypertransport busses, and is only activated if extended apic ids are
> in use, meaning that this quirk guarantees that all processors in a system are
> elligible to receive interrupts from the ioapic, even if their apicid extends
> beyond the nominal 4 bit limitation. Tested successfully by me.
>
> Thanks & Regards
> Neil
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
>
> early-quirks.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 76 insertions(+), 7 deletions(-)
>
>
>
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 88bb83e..d5a7b30 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -44,6 +44,50 @@ static int __init nvidia_hpet_check(struct acpi_table_header
> *header)
> #endif /* CONFIG_X86_IO_APIC */
> #endif /* CONFIG_ACPI */
>
> +static void __init fix_hypertransport_config(int num, int slot, int func)
> +{
> + u32 htcfg;
> + /*
> + *we found a hypertransport bus
> + *make sure that are broadcasting
> + *interrupts to all cpus on the ht bus
> + *if we're using extended apic ids
> + */
> + htcfg = read_pci_config(num, slot, func, 0x68);
> + if ((htcfg & (1 << 18)) == 1) {
Ok. This test is broken. Please remove the == 1. You are looking
for == (1 << 18). So just saying: "if (htcfg & (1 << 18))" should be clearer.
> + 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");
> + htcfg |= (1 << 17);
> + write_pci_config(num, slot, func, 0x68, htcfg);
> + }
> + }
> +
> +}
The rest of this quirk looks fine, include the fact it is only intended
to be applied to PCI_VENDOR_ID_AMD PCI_DEVICE_ID_AMD_K8_NB.
For what is below I don't like the way the infrastructure has been
extended as what you are doing quickly devolves into a big mess.
Please extend struct chipset to be something like:
struct chipset {
u16 vendor;
u16 device;
u32 class, class_mask;
void (*f)(void);
};
And then the test for matching the chipset can be something like:
if ((id->vendor == PCI_ANY_ID || id->vendor == dev->vendor) &&
(id->device == PCI_ANY_ID || id->device == dev->device) &&
!((id->class ^ dev->class) & id->class_mask))
Essentially a subset of pci_match_one_device from drivers/pci/pci.h
That way you don't need to increase the number of tables or the
number of passes through the pci busses, just update the early_qrk
table with a few more bits of information.
The extended form should be much more maintainable in the long
run. Given that we may want this before we enable the timer
which is very early doing this in the pci early quirks seems
to make sense.
Eric
next prev parent reply other threads:[~2007-12-11 1:11 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-27 1:47 Neil Horman
2007-11-27 4:12 ` Eric W. Biederman
2007-11-27 13:13 ` Neil Horman
2007-11-27 13:28 ` Eric W. Biederman
2007-11-27 13:45 ` Andi Kleen
2007-11-27 14:28 ` Neil Horman
2007-11-27 14:43 ` Andi Kleen
2007-11-27 14:48 ` Neil Horman
2007-11-27 15:24 ` Andi Kleen
2007-11-27 15:30 ` Eric W. Biederman
2007-11-27 16:45 ` Neil Horman
2007-11-27 20:50 ` Ben Woodard
2007-11-27 21:05 ` Neil Horman
2007-11-27 22:38 ` Eric W. Biederman
2007-11-27 23:15 ` Ben Woodard
2007-11-28 0:15 ` Eric W. Biederman
2007-11-27 23:40 ` Neil Horman
2007-11-28 0:43 ` Eric W. Biederman
2007-11-28 15:54 ` Neil Horman
2007-11-27 14:56 ` Eric W. Biederman
2007-11-27 15:34 ` Neil Horman
2007-11-27 18:41 ` Ben Woodard
2007-11-27 19:42 ` Neil Horman
2007-11-27 20:00 ` Vivek Goyal
2007-11-27 20:52 ` Neil Horman
2007-11-27 22:24 ` Andi Kleen
2007-11-27 23:24 ` Ben Woodard
2007-11-27 23:56 ` Andi Kleen
2007-11-28 15:36 ` Vivek Goyal
2007-11-28 16:02 ` Neil Horman
2007-11-28 17:36 ` Eric W. Biederman
2007-11-28 18:16 ` Neil Horman
2007-11-28 19:05 ` Vivek Goyal
2007-11-28 19:42 ` Eric W. Biederman
2007-11-28 21:09 ` Neil Horman
2007-11-28 23:27 ` Eric W. Biederman
2007-11-30 2:16 ` Ben Woodard
2007-11-30 2:54 ` Eric W. Biederman
2007-11-30 8:59 ` Yinghai Lu
2007-11-30 14:35 ` Vivek Goyal
2007-11-30 14:32 ` Neil Horman
2007-11-30 2:12 ` Ben Woodard
2007-11-30 14:42 ` Vivek Goyal
2007-11-30 14:51 ` Neil Horman
2007-12-06 21:39 ` Neil Horman
2007-12-06 22:11 ` Vivek Goyal
2007-12-07 0:10 ` Neil Horman
2007-12-07 14:39 ` Vivek Goyal
2007-12-07 14:53 ` Neil Horman
2007-12-07 15:16 ` Vivek Goyal
2007-12-07 15:53 ` Neil Horman
2007-12-07 18:46 ` Eric W. Biederman
2007-12-07 0:33 ` Eric W. Biederman
2007-12-07 2:04 ` Neil Horman
2007-12-07 8:50 ` Yinghai Lu
2007-12-07 9:22 ` Yinghai Lu
2007-12-07 14:21 ` Neil Horman
2007-12-07 17:58 ` Neil Horman
2007-12-07 19:19 ` yhlu
2007-12-07 20:13 ` Neil Horman
2007-12-10 15:39 ` Neil Horman
2007-12-10 16:20 ` Vivek Goyal
2007-12-11 1:17 ` Eric W. Biederman
2007-12-11 1:08 ` Eric W. Biederman [this message]
2007-12-11 3:43 ` Neil Horman
2007-12-11 4:48 ` Eric W. Biederman
2007-12-11 6:31 ` Yinghai Lu
2007-12-11 14:39 ` Neil Horman
2007-12-11 15:29 ` Eric W. Biederman
2007-12-11 18:00 ` Yinghai Lu
2007-12-11 18:29 ` Neil Horman
2007-12-11 18:45 ` Yinghai Lu
2007-12-11 18:22 ` Neil Horman
2007-12-11 18:46 ` Eric W. Biederman
2007-12-11 19:24 ` Neil Horman
2007-12-11 19:51 ` Yinghai Lu
2007-12-11 20:59 ` Neil Horman
2007-12-12 0:16 ` Ben Woodard
2007-12-12 0:52 ` Neil Horman
2007-12-12 1:07 ` Yinghai Lu
2007-12-12 8:43 ` [PATCH] k8: Enable legacy irqs with extended cpu ids Eric W. Biederman
2007-12-12 14:21 ` [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu Andi Kleen
2007-12-12 15:55 ` Neil Horman
2007-12-12 16:07 ` Andi Kleen
2007-12-12 19:43 ` Eric W. Biederman
2007-12-12 20:22 ` Neil Horman
2007-12-12 21:32 ` Eric W. Biederman
2007-12-13 14:39 ` Neil Horman
2007-12-13 15:16 ` Andi Kleen
2007-12-13 15:32 ` Neil Horman
2007-12-17 11:38 ` Neil Horman
2007-12-18 0:13 ` Eric W. Biederman
2007-12-17 15:16 ` Ingo Molnar
2007-12-17 15:47 ` Neil Horman
2007-12-07 18:36 ` Eric W. Biederman
2007-12-07 18:48 ` Neil Horman
2007-11-27 13:53 ` Neil Horman
2007-11-27 10:55 ` Andi Kleen
2007-11-27 11:19 ` Eric W. Biederman
2007-11-27 13:28 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1k5nm2g3w.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=ak@suse.de \
--cc=andi@firstfloor.org \
--cc=hbabu@us.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=nhorman@tuxdriver.com \
--cc=woodard@redhat.com \
--cc=yhlu.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®