x86/sfi: fix ioapic gsi range
in [Kernel]
|
Prev: Fwd: EXT3 File System Corruption 2.6.34
Next: 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
From: Eric W. Biederman on 9 Jun 2010 19:50 jacob pan <jacob.jun.pan(a)linux.intel.com> writes: > [jacob pan] > > In arch/x86/kernel/mrst.c we parse SFI MTMR table then > add timer irqs to mp_irqs. what is broken by this patch is > pin_2_irq() lookup for the legacy irq range since we want > NR_IRQS_LEGACY to be 0 on Moorestown. We do have the assumption that > mp_irqs from SFI is 1:1 mapped to IRQs. NR_IRQS_LEGACY is a constant of 16. > Doing this can fix the problem, but you mentioned you have to use > NR_IRQS_LEGACY, which i still don't understand. Looking at the code in io_apic.c there is a relatively clean way to handle this. The actual concept in io_apic.c today is mp_bus_not_pci. So you just need to do: diff --git a/arch/x86/kernel/mrst.c b/arch/x86/kernel/mrst.c index e796448..9377fda 100644 --- a/arch/x86/kernel/mrst.c +++ b/arch/x86/kernel/mrst.c @@ -242,4 +242,5 @@ void __init x86_mrst_early_setup(void) x86_init.mpparse.find_smp_config = x86_init_noop; x86_init.mpparse.get_smp_config = x86_init_uint_noop; + set_bit(0, mp_bus_not_pci); } Then you get treated as ISA for purposes of pin_2_irq, and everything is a pass through. Since that seems to be what you want anyway I don't see a problem with that for now. Using legacy pic to even talk about this behavior is wrong as that is hardware abstraction and the presence or absence of an i8259 has nothing to do with the presence of ISA irqs and their descendants. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: jacob pan on 10 Jun 2010 04:40 Eric W. Biederman Wed, 09 Jun 2010 16:44:11 -0700 >jacob pan <jacob.jun.pan(a)linux.intel.com> writes: > >> [jacob pan] >> >> In arch/x86/kernel/mrst.c we parse SFI MTMR table then >> add timer irqs to mp_irqs. what is broken by this patch is >> pin_2_irq() lookup for the legacy irq range since we want >> NR_IRQS_LEGACY to be 0 on Moorestown. We do have the assumption that >> mp_irqs from SFI is 1:1 mapped to IRQs. > >NR_IRQS_LEGACY is a constant of 16. i know, what i meant is we want this to be a variable. > >> Doing this can fix the problem, but you mentioned you have to use >> NR_IRQS_LEGACY, which i still don't understand. > >Looking at the code in io_apic.c there is a relatively clean way to >handle this. The actual concept in io_apic.c today is mp_bus_not_pci. > >So you just need to do: > >diff --git a/arch/x86/kernel/mrst.c b/arch/x86/kernel/mrst.c >index e796448..9377fda 100644 >--- a/arch/x86/kernel/mrst.c >+++ b/arch/x86/kernel/mrst.c >@@ -242,4 +242,5 @@ void __init x86_mrst_early_setup(void) > x86_init.mpparse.find_smp_config = x86_init_noop; > x86_init.mpparse.get_smp_config = x86_init_uint_noop; > >+ set_bit(0, mp_bus_not_pci); > } > > >Then you get treated as ISA for purposes of pin_2_irq, and everything >is a pass through. Since that seems to be what you want anyway I don't >see a problem with that for now. > I think this may work better. Since we already assign srcbus = MP_ISA_BUS to use the mp_irqs, this may be more inline with the current code. Thanks for the pointer. But the nr_irqs_gsi would still be wrong for Moorestown if don't use legacy_pic or some sort of runtime detection. >Using legacy pic to even talk about this behavior is wrong as that is >hardware abstraction and the presence or absence of an i8259 has >nothing to do with the presence of ISA irqs and their descendants. > >Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 10 Jun 2010 10:50
jacob pan <jacob.jun.pan(a)linux.intel.com> writes: > Eric W. Biederman Wed, 09 Jun 2010 16:44:11 -0700 >>jacob pan <jacob.jun.pan(a)linux.intel.com> writes: >> >>> [jacob pan] >>> >>> In arch/x86/kernel/mrst.c we parse SFI MTMR table then >>> add timer irqs to mp_irqs. what is broken by this patch is >>> pin_2_irq() lookup for the legacy irq range since we want >>> NR_IRQS_LEGACY to be 0 on Moorestown. We do have the assumption that >>> mp_irqs from SFI is 1:1 mapped to IRQs. >> >>NR_IRQS_LEGACY is a constant of 16. > i know, what i meant is we want this to be a variable. No. Not on that code path. As that code path has nothing to do what what hardware is present. There are a bunch of other very awkward usages of legacy_pic->nr_legacy_irqs that should be removed with cleanups. Things like EISA_ELCR are very wrong to have a variable in there. We already have a probe for ISA being present so we don't need an extra one. >>> Doing this can fix the problem, but you mentioned you have to use >>> NR_IRQS_LEGACY, which i still don't understand. >> >>Looking at the code in io_apic.c there is a relatively clean way to >>handle this. The actual concept in io_apic.c today is mp_bus_not_pci. >> >>So you just need to do: >> >>diff --git a/arch/x86/kernel/mrst.c b/arch/x86/kernel/mrst.c >>index e796448..9377fda 100644 >>--- a/arch/x86/kernel/mrst.c >>+++ b/arch/x86/kernel/mrst.c >>@@ -242,4 +242,5 @@ void __init x86_mrst_early_setup(void) >> x86_init.mpparse.find_smp_config = x86_init_noop; >> x86_init.mpparse.get_smp_config = x86_init_uint_noop; >> >>+ set_bit(0, mp_bus_not_pci); >> } >> >> >>Then you get treated as ISA for purposes of pin_2_irq, and everything >>is a pass through. Since that seems to be what you want anyway I don't >>see a problem with that for now. >> > I think this may work better. Since we already assign srcbus = MP_ISA_BUS to > use the mp_irqs, this may be more inline with the current code. > Thanks for the pointer. > > But the nr_irqs_gsi would still be wrong for Moorestown if don't use legacy_pic > or some sort of runtime detection. nr_irqs_gsi has a possibly confusing name. nr_irqs_gsi is the number of linux irqs that we reserve for handling the gsis. All of the rest of the irqs are allowed to be dynamically allocated for MSIs and the like. As long as the number is >= the number of gsis you are fine. Unless you have patches that do strange and use nr_irqs_gsi for something else I don't see why you would have a problem with nr_irqs_gsi. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |