search for: nr_irqs

Make NR_IRQ overridable by each pv instances. Pv instance may need each own number of irqs so that NR_IRQS should be the maximum number of nr_irqs each pv instances need. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- arch/ia64/kernel/asm-offsets.c | 18 ++++++++++++++++++ include/asm-ia64/hardirq.h | 4 +++- include/asm-ia64/irq.h | 13 +++++++++++-- 3 files ch...

Instead of artificially limiting irq numbers, use arch provided NR_IRQS Signed-off-by: Glauber Costa <gcosta at redhat.com> --- irqhook/irqhook_main.c | 16 +++++++--------- 1 files changed, 7 insertions(+), 9 deletions(-) diff --git a/irqhook/irqhook_main.c b/irqhook/irqhook_main.c index 5f414d1..828c70a 100644 --- a/irqhook/irqhook_main.c +++ b/irqhook/irq...

Instead of artificially limiting irq numbers, use arch provided NR_IRQS Signed-off-by: Glauber Costa <gcosta at redhat.com> --- irqhook/irqhook_main.c | 16 +++++++--------- 1 files changed, 7 insertions(+), 9 deletions(-) diff --git a/irqhook/irqhook_main.c b/irqhook/irqhook_main.c index 5f414d1..828c70a 100644 --- a/irqhook/irqhook_main.c +++ b/irqhook/irq...

On 03/01/2010 03:25 PM, Ian Campbell wrote: > On Mon, 2010-03-01 at 14:21 +0000, Michal Novotny wrote: > >> Hi, >> well, I tried reverting this patch and both applying and not applying >> the new one from Ian but there is still kernel oops. Error image is >> attached. Also, I tried disabling CONFIG_SPARSE_IRQ (i.e. setting this >> to n) but no luck. Still

...- 0xc0000000 ( 2 MB) [ 0.000000] .text : 0xc0008000 - 0xc0359be8 (3399 kB) [ 0.000000] .init : 0xc035a000 - 0xc037c884 ( 139 kB) [ 0.000000] .data : 0xc037e000 - 0xc039ef80 ( 132 kB) [ 0.000000] .bss : 0xc039ef80 - 0xc03c1434 ( 138 kB) [ 0.000000] NR_IRQS:16 nr_irqs:16 16 I won''t go through all the configurations I tried of course but just one that I got ''semi'' working. Device Tree: git://xenbits.xen.org/people/sstabellini/device-trees.git Dom0 Kernel: git://xenbits.xen.org/people/ianc/linux.git the arm-privcmd-for-3.8...

Looking at the MSI implementation I have a couple of questions: 1) There currently seems to be a hidden requirement of NR_PIRQS in the kernel needing to be no smaller than NR_IRQS in the hypervisor. Otherwise, the pirq returned from PHYSDEVOP_map_pirq may collide with the dynamic IRQs in the kernel or even be out of range altogether. Therefore I think that NR_PIRQS has to become a variable defaulting to 256 but getting initialized from a hypervisor reported value (perhaps in...

This one basically disables MSI with a pretty vague comment - is there any more detail on where the issues are here? I''m asking because I had to undo this in order to make sure the NR_IRQS patches really work as expected... Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...this has known scalability problems. > >> > >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > >> I'm sorry, I don't understand you meaning. > >> What are the scalability problems you mentioned ? > > We have soft limitation of nr_irqs or hard limitation NR_IRQS, > > we couldn't allocate as much irq number as we need in some cases, > > such as to support MSI-x. > > Oh, yes, this is a potential issue. Gerry, thanks for you explanation. :) This should no longer be an issue, as arm64 uses CONFIG_SPARSE_IRQ an...

...this has known scalability problems. > >> > >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > >> I'm sorry, I don't understand you meaning. > >> What are the scalability problems you mentioned ? > > We have soft limitation of nr_irqs or hard limitation NR_IRQS, > > we couldn't allocate as much irq number as we need in some cases, > > such as to support MSI-x. > > Oh, yes, this is a potential issue. Gerry, thanks for you explanation. :) This should no longer be an issue, as arm64 uses CONFIG_SPARSE_IRQ an...

...h/x86/irq.c Thu Jan 08 18:58:36 2009 +0900 @@ -857,7 +857,7 @@ int map_domain_pirq( if ( type == MAP_PIRQ_TYPE_MSI ) return -EINVAL; - if ( !IS_PRIV(current->domain) ) + if ( !IS_PRIV_FOR(current->domain, d) ) return -EPERM; if ( pirq < 0 || pirq >= NR_IRQS || vector < 0 || vector >= NR_VECTORS ) @@ -931,7 +931,7 @@ int unmap_domain_pirq(struct domain *d, if ( (pirq < 0) || (pirq >= NR_IRQS) ) return -EINVAL; - if ( !IS_PRIV(current->domain) ) + if ( !IS_PRIV_FOR(current->domain, d) ) return -EINVAL;...

...d, there is no ixgbe message in dmesg. I can list irq from dmesg (with NIC detected) and dmesg.old (NIS is not tedected) grep irq dmesg [??? 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [??? 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [??? 0.000000] NR_IRQS:327936 nr_irqs:1024 0 [??? 0.531915] pcieport 0000:00:01.0: irq 120 for MSI/MSI-X [??? 0.532038] pcieport 0000:00:1b.0: irq 121 for MSI/MSI-X [??? 0.532309] pcieport 0000:00:1c.5: irq 122 for MSI/MSI-X [??? 0.532534] pcieport 0000:00:1d.0: irq 123 for MSI/MSI-X [??? 0.604204] 00:05: ttyS0 at I/O 0x...

...mesg. > > I can list irq from dmesg (with NIC detected) and dmesg.old (NIS is not > tedected) > grep irq dmesg > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > [ 0.000000] NR_IRQS:327936 nr_irqs:1024 0 > [ 0.531915] pcieport 0000:00:01.0: irq 120 for MSI/MSI-X > [ 0.532038] pcieport 0000:00:1b.0: irq 121 for MSI/MSI-X > [ 0.532309] pcieport 0000:00:1c.5: irq 122 for MSI/MSI-X > [ 0.532534] pcieport 0000:00:1d.0: irq 123 for MSI/MSI-X > [ 0.60420...

...> MSI users are based on IRQ numbers, but this has known scalability problems. > > Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > I'm sorry, I don't understand you meaning. > What are the scalability problems you mentioned ? We have soft limitation of nr_irqs or hard limitation NR_IRQS, we couldn't allocate as much irq number as we need in some cases, such as to support MSI-x. > For device drivers, they always process interrupt in two steps. > If irq is the legacy interrupt, drivers will first > use the irq_of_parse_and_map() or pci_enable...

...> MSI users are based on IRQ numbers, but this has known scalability problems. > > Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > I'm sorry, I don't understand you meaning. > What are the scalability problems you mentioned ? We have soft limitation of nr_irqs or hard limitation NR_IRQS, we couldn't allocate as much irq number as we need in some cases, such as to support MSI-x. > For device drivers, they always process interrupt in two steps. > If irq is the legacy interrupt, drivers will first > use the irq_of_parse_and_map() or pci_enable...

...Remove the limit of 256 interrupt vectors by changing the value > stored in orig_{e,r}ax to be the negated interrupt vector. > The orig_{e,r}ax needs to be < 0 to allow the signal code to > distinguish between return from interrupt and return from syscall. > With this change applied, NR_IRQS can be > 256. > > Xen extends the IRQ numbering space to include room for dynamically > allocated virtual interrupts (in the range 256-511), which requires a > more permissive interface to do_IRQ. > > Signed-off-by: Ian Pratt <ian.pratt@xensource.com> > Signed-off-by:...

...Remove the limit of 256 interrupt vectors by changing the value > stored in orig_{e,r}ax to be the negated interrupt vector. > The orig_{e,r}ax needs to be < 0 to allow the signal code to > distinguish between return from interrupt and return from syscall. > With this change applied, NR_IRQS can be > 256. > > Xen extends the IRQ numbering space to include room for dynamically > allocated virtual interrupts (in the range 256-511), which requires a > more permissive interface to do_IRQ. > > Signed-off-by: Ian Pratt <ian.pratt@xensource.com> > Signed-off-by:...

...scalability problems. >>>> >>>> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. >>>> I'm sorry, I don't understand you meaning. >>>> What are the scalability problems you mentioned ? >>> We have soft limitation of nr_irqs or hard limitation NR_IRQS, >>> we couldn't allocate as much irq number as we need in some cases, >>> such as to support MSI-x. >> >> Oh, yes, this is a potential issue. Gerry, thanks for you explanation. :) > > This should no longer be an issue, as arm64 us...

Hi, I try to build experimental networks with Xen and stumbled over the same problem that has been described quite well by Mark Doll in his posting "xen_net: Failed to connect all virtual interfaces: err=-100" here: http://lists.xensource.com/archives/html/xen-users/2005-04/msg00447.html As it was still present in 2.0.6, I tried 3.0-devel and found NR_PIRQS and NR_DYNIRQS had been

Hi, I try to build experimental networks with Xen and stumbled over the same problem that has been described quite well by Mark Doll in his posting "xen_net: Failed to connect all virtual interfaces: err=-100" here: http://lists.xensource.com/archives/html/xen-users/2005-04/msg00447.html As it was still present in 2.0.6, I tried 3.0-devel and found NR_PIRQS and NR_DYNIRQS had been

...ata, 956k init) [ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] RCU-based detection of stalled CPUs is disabled. [ 0.000000] NR_IRQS:16640 nr_irqs:256 16 [ 0.000000] Console: colour dummy device 80x25 [ 0.000000] console [ttyS0] enabled [ 0.000000] Fast TSC calibration using PIT [ 0.000000] Detected 2526.022 MHz processor. [ 0.000472] Calibrating delay loop (skipped), value calculated using timer frequency.. 5052....