| Message ID | 4A0DC7DC.7000204@kernel.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Friday 15 May 2009 01:51:56 pm Yinghai Lu wrote: > to get all device irq routing and save them This changelog isn't really enough for me to understand what's going on. > Index: linux-2.6/arch/x86/kernel/mpparse.c > =================================================================== > --- linux-2.6.orig/arch/x86/kernel/mpparse.c > +++ linux-2.6/arch/x86/kernel/mpparse.c > @@ -17,6 +17,7 @@ > #include <linux/acpi.h> > #include <linux/module.h> > #include <linux/smp.h> > +#include <linux/pci.h> > > #include <asm/mtrr.h> > #include <asm/mpspec.h> > @@ -961,6 +962,7 @@ static int __initdata enable_update_mpta > static int __init update_mptable_setup(char *str) > { > enable_update_mptable = 1; > + pci_routeirq = 1; I hate to see new uses of pci_routeirq. It'd be nice to remove it completely someday. But maybe it can't be helped. > return 0; > } > early_param("update_mptable", update_mptable_setup); "update_mptable" is apparently a boot option, but it's not mentioned in Documentation/kernel-parameters.txt. Is this some sort of debug code or BIOS-writer's helper? Same with "alloc_mptable". Why do we have this stuff? > @@ -973,6 +975,7 @@ static int __initdata alloc_mptable; > static int __init parse_alloc_mptable_opt(char *p) > { > enable_update_mptable = 1; > + pci_routeirq = 1; > alloc_mptable = 1; > if (!p) > return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bjorn Helgaas wrote: > On Friday 15 May 2009 01:51:56 pm Yinghai Lu wrote: >> to get all device irq routing and save them > > This changelog isn't really enough for me to understand > what's going on. > >> Index: linux-2.6/arch/x86/kernel/mpparse.c >> =================================================================== >> --- linux-2.6.orig/arch/x86/kernel/mpparse.c >> +++ linux-2.6/arch/x86/kernel/mpparse.c >> @@ -17,6 +17,7 @@ >> #include <linux/acpi.h> >> #include <linux/module.h> >> #include <linux/smp.h> >> +#include <linux/pci.h> >> >> #include <asm/mtrr.h> >> #include <asm/mpspec.h> >> @@ -961,6 +962,7 @@ static int __initdata enable_update_mpta >> static int __init update_mptable_setup(char *str) >> { >> enable_update_mptable = 1; >> + pci_routeirq = 1; > > I hate to see new uses of pci_routeirq. It'd be nice to remove it > completely someday. But maybe it can't be helped. > >> return 0; >> } >> early_param("update_mptable", update_mptable_setup); > > "update_mptable" is apparently a boot option, but it's not mentioned > in Documentation/kernel-parameters.txt. Is this some sort of debug > code or BIOS-writer's helper? Same with "alloc_mptable". Why do > we have this stuff? > 1. kexec path: after acpi kernel and use kexec to load kerenl with mptable support only or acpi=off 2. help to BIOS engineer to understand how to set mptable and irq routing setup by chipset. esp system have several cards and there is bridge in those cards. YH -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 15 May 2009 03:13:20 pm Yinghai Lu wrote: > Bjorn Helgaas wrote: > > On Friday 15 May 2009 01:51:56 pm Yinghai Lu wrote: > >> to get all device irq routing and save them > > > > This changelog isn't really enough for me to understand > > what's going on. > > > >> Index: linux-2.6/arch/x86/kernel/mpparse.c > >> =================================================================== > >> --- linux-2.6.orig/arch/x86/kernel/mpparse.c > >> +++ linux-2.6/arch/x86/kernel/mpparse.c > >> @@ -17,6 +17,7 @@ > >> #include <linux/acpi.h> > >> #include <linux/module.h> > >> #include <linux/smp.h> > >> +#include <linux/pci.h> > >> > >> #include <asm/mtrr.h> > >> #include <asm/mpspec.h> > >> @@ -961,6 +962,7 @@ static int __initdata enable_update_mpta > >> static int __init update_mptable_setup(char *str) > >> { > >> enable_update_mptable = 1; > >> + pci_routeirq = 1; > > > > I hate to see new uses of pci_routeirq. It'd be nice to remove it > > completely someday. But maybe it can't be helped. > > > >> return 0; > >> } > >> early_param("update_mptable", update_mptable_setup); > > > > "update_mptable" is apparently a boot option, but it's not mentioned > > in Documentation/kernel-parameters.txt. Is this some sort of debug > > code or BIOS-writer's helper? Same with "alloc_mptable". Why do > > we have this stuff? > > > > 1. kexec path: after acpi kernel and use kexec to load kerenl with mptable support only or acpi=off > 2. help to BIOS engineer to understand how to set mptable and irq routing setup by chipset. > esp system have several cards and there is bridge in those cards. I was sort of hoping for a Documentation/kernel-parameters.txt patch. Is (1) common enough to worry about? What OSes don't have ACPI support? What advantage is there to using "acpi=off"? (2) sounds like something that should be under a config option, if it's in the mainline kernel at all. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bjorn Helgaas wrote: > On Friday 15 May 2009 03:13:20 pm Yinghai Lu wrote: >> Bjorn Helgaas wrote: >>> On Friday 15 May 2009 01:51:56 pm Yinghai Lu wrote: >>>> to get all device irq routing and save them >>> This changelog isn't really enough for me to understand >>> what's going on. >>> >>>> Index: linux-2.6/arch/x86/kernel/mpparse.c >>>> =================================================================== >>>> --- linux-2.6.orig/arch/x86/kernel/mpparse.c >>>> +++ linux-2.6/arch/x86/kernel/mpparse.c >>>> @@ -17,6 +17,7 @@ >>>> #include <linux/acpi.h> >>>> #include <linux/module.h> >>>> #include <linux/smp.h> >>>> +#include <linux/pci.h> >>>> >>>> #include <asm/mtrr.h> >>>> #include <asm/mpspec.h> >>>> @@ -961,6 +962,7 @@ static int __initdata enable_update_mpta >>>> static int __init update_mptable_setup(char *str) >>>> { >>>> enable_update_mptable = 1; >>>> + pci_routeirq = 1; >>> I hate to see new uses of pci_routeirq. It'd be nice to remove it >>> completely someday. But maybe it can't be helped. >>> >>>> return 0; >>>> } >>>> early_param("update_mptable", update_mptable_setup); >>> "update_mptable" is apparently a boot option, but it's not mentioned >>> in Documentation/kernel-parameters.txt. Is this some sort of debug >>> code or BIOS-writer's helper? Same with "alloc_mptable". Why do >>> we have this stuff? >>> >> 1. kexec path: after acpi kernel and use kexec to load kerenl with mptable support only or acpi=off >> 2. help to BIOS engineer to understand how to set mptable and irq routing setup by chipset. >> esp system have several cards and there is bridge in those cards. > > I was sort of hoping for a Documentation/kernel-parameters.txt patch. current we have half commited in mainline. missed the calling in drivers/acpi and we are trying to move the calling to arch/x86/kernel/acpi/boot.c hope Len will buy it. > > Is (1) common enough to worry about? What OSes don't have ACPI > support? What advantage is there to using "acpi=off"? some other "OS" still use half ACPI tables... MADT etc. but still use mptable for irq routing. some one want to disable acpi, because acpid is using 100%... > > (2) sounds like something that should be under a config option, if > it's in the mainline kernel at all. sure, will make it as one CONFIG option that depends on ACPI. Thanks YH -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 15 May 2009 04:03:49 pm Yinghai Lu wrote: > Bjorn Helgaas wrote: > > On Friday 15 May 2009 03:13:20 pm Yinghai Lu wrote: > >> Bjorn Helgaas wrote: > >>> On Friday 15 May 2009 01:51:56 pm Yinghai Lu wrote: > >>>> to get all device irq routing and save them > >>> This changelog isn't really enough for me to understand > >>> what's going on. > >>> > >>>> Index: linux-2.6/arch/x86/kernel/mpparse.c > >>>> =================================================================== > >>>> --- linux-2.6.orig/arch/x86/kernel/mpparse.c > >>>> +++ linux-2.6/arch/x86/kernel/mpparse.c > >>>> @@ -17,6 +17,7 @@ > >>>> #include <linux/acpi.h> > >>>> #include <linux/module.h> > >>>> #include <linux/smp.h> > >>>> +#include <linux/pci.h> > >>>> > >>>> #include <asm/mtrr.h> > >>>> #include <asm/mpspec.h> > >>>> @@ -961,6 +962,7 @@ static int __initdata enable_update_mpta > >>>> static int __init update_mptable_setup(char *str) > >>>> { > >>>> enable_update_mptable = 1; > >>>> + pci_routeirq = 1; > >>> I hate to see new uses of pci_routeirq. It'd be nice to remove it > >>> completely someday. But maybe it can't be helped. > >>> > >>>> return 0; > >>>> } > >>>> early_param("update_mptable", update_mptable_setup); > >>> "update_mptable" is apparently a boot option, but it's not mentioned > >>> in Documentation/kernel-parameters.txt. Is this some sort of debug > >>> code or BIOS-writer's helper? Same with "alloc_mptable". Why do > >>> we have this stuff? > >>> > >> 1. kexec path: after acpi kernel and use kexec to load kerenl with mptable support only or acpi=off > >> 2. help to BIOS engineer to understand how to set mptable and irq routing setup by chipset. > >> esp system have several cards and there is bridge in those cards. > ... > > Is (1) common enough to worry about? What OSes don't have ACPI > > support? What advantage is there to using "acpi=off"? > ... > > some one want to disable acpi, because acpid is using 100%... I'd rather fix the problem with acpid than make it easier to use "acpi=off". Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > On Friday 15 May 2009 04:03:49 pm Yinghai Lu wrote: > > Bjorn Helgaas wrote: > > > On Friday 15 May 2009 03:13:20 pm Yinghai Lu wrote: > > >> Bjorn Helgaas wrote: > > >>> On Friday 15 May 2009 01:51:56 pm Yinghai Lu wrote: > > >>>> to get all device irq routing and save them > > >>> This changelog isn't really enough for me to understand > > >>> what's going on. > > >>> > > >>>> Index: linux-2.6/arch/x86/kernel/mpparse.c > > >>>> =================================================================== > > >>>> --- linux-2.6.orig/arch/x86/kernel/mpparse.c > > >>>> +++ linux-2.6/arch/x86/kernel/mpparse.c > > >>>> @@ -17,6 +17,7 @@ > > >>>> #include <linux/acpi.h> > > >>>> #include <linux/module.h> > > >>>> #include <linux/smp.h> > > >>>> +#include <linux/pci.h> > > >>>> > > >>>> #include <asm/mtrr.h> > > >>>> #include <asm/mpspec.h> > > >>>> @@ -961,6 +962,7 @@ static int __initdata enable_update_mpta > > >>>> static int __init update_mptable_setup(char *str) > > >>>> { > > >>>> enable_update_mptable = 1; > > >>>> + pci_routeirq = 1; > > >>> I hate to see new uses of pci_routeirq. It'd be nice to remove it > > >>> completely someday. But maybe it can't be helped. > > >>> > > >>>> return 0; > > >>>> } > > >>>> early_param("update_mptable", update_mptable_setup); > > >>> "update_mptable" is apparently a boot option, but it's not mentioned > > >>> in Documentation/kernel-parameters.txt. Is this some sort of debug > > >>> code or BIOS-writer's helper? Same with "alloc_mptable". Why do > > >>> we have this stuff? > > >>> > > >> 1. kexec path: after acpi kernel and use kexec to load kerenl with mptable support only or acpi=off > > >> 2. help to BIOS engineer to understand how to set mptable and irq routing setup by chipset. > > >> esp system have several cards and there is bridge in those cards. > > ... > > > Is (1) common enough to worry about? What OSes don't have ACPI > > > support? What advantage is there to using "acpi=off"? > > ... > > > > some one want to disable acpi, because acpid is using 100%... > > I'd rather fix the problem with acpid than make it easier to use > "acpi=off". Well, acpi=off is frequently used. Besides of that, there's a design and future-proof-ness issue as well: having a correct mptable is good in sense of not having all our collective eggs in the ACPI basket. ACPI also has IP attached and there are vendors who are loathe to use it for one reason or another. So as long as Yinghai is willing to maintain this path and is willing to keep it correct, and as long as we _have_ an acpi=off option in the upstream kernel it makes sense to make the kexec environment as correct and inclusive as possible. acpid looping should of course be fixed separately. Almost all distros ship with acpi enabled so there's no shortage of bugs being reported, and there's no need to artificially make it harder for people to not use acpi if they so choose. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-2.6/arch/x86/kernel/mpparse.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/mpparse.c +++ linux-2.6/arch/x86/kernel/mpparse.c @@ -17,6 +17,7 @@ #include <linux/acpi.h> #include <linux/module.h> #include <linux/smp.h> +#include <linux/pci.h> #include <asm/mtrr.h> #include <asm/mpspec.h> @@ -961,6 +962,7 @@ static int __initdata enable_update_mpta static int __init update_mptable_setup(char *str) { enable_update_mptable = 1; + pci_routeirq = 1; return 0; } early_param("update_mptable", update_mptable_setup); @@ -973,6 +975,7 @@ static int __initdata alloc_mptable; static int __init parse_alloc_mptable_opt(char *p) { enable_update_mptable = 1; + pci_routeirq = 1; alloc_mptable = 1; if (!p) return 0;
to get all device irq routing and save them Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/kernel/mpparse.c | 3 +++ 1 file changed, 3 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html