1. 01 1月, 2009 1 次提交
  2. 13 12月, 2008 2 次提交
  3. 08 12月, 2008 1 次提交
    • Y
      sparse irq_desc[] array: core kernel and x86 changes · 0b8f1efa
      Yinghai Lu 提交于
      Impact: new feature
      
      Problem on distro kernels: irq_desc[NR_IRQS] takes megabytes of RAM with
      NR_CPUS set to large values. The goal is to be able to scale up to much
      larger NR_IRQS value without impacting the (important) common case.
      
      To solve this, we generalize irq_desc[NR_IRQS] to an (optional) array of
      irq_desc pointers.
      
      When CONFIG_SPARSE_IRQ=y is used, we use kzalloc_node to get irq_desc,
      this also makes the IRQ descriptors NUMA-local (to the site that calls
      request_irq()).
      
      This gets rid of the irq_cfg[] static array on x86 as well: irq_cfg now
      uses desc->chip_data for x86 to store irq_cfg.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0b8f1efa
  4. 10 11月, 2008 1 次提交
  5. 22 10月, 2008 1 次提交
  6. 16 10月, 2008 4 次提交
  7. 13 8月, 2008 1 次提交
  8. 05 6月, 2008 1 次提交
    • M
      genirq: Expose default irq affinity mask (take 3) · 18404756
      Max Krasnyansky 提交于
      Current IRQ affinity interface does not provide a way to set affinity
      for the IRQs that will be allocated/activated in the future.
      This patch creates /proc/irq/default_smp_affinity that lets users set
      default affinity mask for the newly allocated IRQs. Changing the default
      does not affect affinity masks for the currently active IRQs, they
      have to be changed explicitly.
      
      Updated based on Paul J's comments and added some more documentation.
      Signed-off-by: NMax Krasnyansky <maxk@qualcomm.com>
      Cc: pj@sgi.com
      Cc: a.p.zijlstra@chello.nl
      Cc: tglx@linutronix.de
      Cc: rdunlap@xenotime.net
      Cc: mingo@elte.hu
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      18404756
  9. 30 1月, 2008 1 次提交
  10. 22 7月, 2007 1 次提交
  11. 12 5月, 2007 1 次提交
  12. 09 5月, 2007 1 次提交
  13. 17 2月, 2007 2 次提交
  14. 12 2月, 2007 1 次提交
  15. 09 12月, 2006 1 次提交
    • H
      [PATCH] CPEI gets warning at kernel/irq/migration.c:27/move_masked_irq() · 6e2ac664
      Hidetoshi Seto 提交于
      While running my MCA test (hardware error injection) on 2.6.19,
      I got some warning like following:
      
      > BUG: warning at kernel/irq/migration.c:27/move_masked_irq()
      >
      > Call Trace:
      >  [<a000000100013d20>] show_stack+0x40/0xa0
      >                                 sp=e00000006b2578d0 bsp=e00000006b2510b0
      >  [<a000000100013db0>] dump_stack+0x30/0x60
      >                                 sp=e00000006b257aa0 bsp=e00000006b251098
      >  [<a0000001000de430>] move_masked_irq+0xb0/0x240
      >                                 sp=e00000006b257aa0 bsp=e00000006b251070
      >  [<a0000001000de6a0>] move_native_irq+0xe0/0x180
      >                                 sp=e00000006b257aa0 bsp=e00000006b251040
      >  [<a00000010004ff50>] iosapic_end_level_irq+0x30/0xe0
      >                                 sp=e00000006b257aa0 bsp=e00000006b251020
      >  [<a0000001000d94d0>] __do_IRQ+0x170/0x400
      >                                 sp=e00000006b257aa0 bsp=e00000006b250fd8
      >  [<a0000001000116f0>] ia64_handle_irq+0x1b0/0x260
      >                                 sp=e00000006b257aa0 bsp=e00000006b250fa8
      >  [<a00000010000c3a0>] ia64_leave_kernel+0x0/0x280
      >                                 sp=e00000006b257aa0 bsp=e00000006b250fa8
      >  [<a000000100690cf0>] _spin_unlock_irqrestore+0x30/0x60
      >                                 sp=e00000006b257c70 bsp=e00000006b250f90
      
      It comes from:
      
      [kernel/irq/migration.c]
        26         if (CHECK_IRQ_PER_CPU(desc->status)) {
        27                 WARN_ON(1);
        28                 return;
        29         }
      
      By putting some printk in kernel, I found that irqbalance is trying to
      move CPEI which is handled as PER_CPU irq. That's why.
      
      CPEI(Corrected Platform Error Interrupt) is ia64 specific irq, is
      allowed to pin to particular processor which selected by the platform, and
      even it is PER_CPU but it has set_affinity handler (=iosapic_set_affinity)
      as same as other IO-SAPIC-level interrupts. (I don't know why, but
      I guess that there would be typical situation where the handler for
      migration is needed, such as hotplug - the processor going to be
      offline/hot-removed.)
      
      To shut up this warning, there are 2 way at least:
       a) fix CPEI stuff
       b) prohibit setting affinity to PER_CPU irq
      
      I'm not sure what stuff of CPEI need to be fixed, but I think that
      returning error to attempting move PER_CPU irq is useful for all
      applications since it will never work.
      
      Following small patch takes b) style.
      It works, the warning disappeared and irqbalance still runs well.
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6e2ac664
  16. 12 10月, 2006 1 次提交
    • R
      [PATCH] bitmap: parse input from kernel and user buffers · 01a3ee2b
      Reinette Chatre 提交于
      lib/bitmap.c:bitmap_parse() is a library function that received as input a
      user buffer.  This seemed to have originated from the way the write_proc
      function of the /proc filesystem operates.
      
      This has been reworked to not use kmalloc and eliminates a lot of
      get_user() overhead by performing one access_ok before using __get_user().
      
      We need to test if we are in kernel or user space (is_user) and access the
      buffer differently.  We cannot use __get_user() to access kernel addresses
      in all cases, for example in architectures with separate address space for
      kernel and user.
      
      This function will be useful for other uses as well; for example, taking
      input for /sysfs instead of /proc, so it was changed to accept kernel
      buffers.  We have this use for the Linux UWB project, as part as the
      upcoming bandwidth allocator code.
      
      Only a few routines used this function and they were changed too.
      Signed-off-by: NReinette Chatre <reinette.chatre@linux.intel.com>
      Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Joe Korty <joe.korty@ccur.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      01a3ee2b
  17. 30 6月, 2006 4 次提交
    • I
      [PATCH] genirq: cleanup: no_irq_type -> no_irq_chip rename · f1c2662c
      Ingo Molnar 提交于
      Rename no_irq_type to no_irq_chip.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f1c2662c
    • I
      [PATCH] genirq: cleanup: merge irq_dir[], smp_affinity_entry[] into irq_desc[] · 4a733ee1
      Ingo Molnar 提交于
      Consolidation: remove the irq_dir[NR_IRQS] and the smp_affinity_entry[NR_IRQS]
      arrays and move them into the irq_desc[] array.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4a733ee1
    • I
      [PATCH] genirq: cleanup: merge irq_affinity[] into irq_desc[] · a53da52f
      Ingo Molnar 提交于
      Consolidation: remove the irq_affinity[NR_IRQS] array and move it into the
      irq_desc[NR_IRQS].affinity field.
      
      [akpm@osdl.org: sparc64 build fix]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a53da52f
    • I
      [PATCH] genirq: rename desc->handler to desc->chip · d1bef4ed
      Ingo Molnar 提交于
      This patch-queue improves the generic IRQ layer to be truly generic, by adding
      various abstractions and features to it, without impacting existing
      functionality.
      
      While the queue can be best described as "fix and improve everything in the
      generic IRQ layer that we could think of", and thus it consists of many
      smaller features and lots of cleanups, the one feature that stands out most is
      the new 'irq chip' abstraction.
      
      The irq-chip abstraction is about describing and coding and IRQ controller
      driver by mapping its raw hardware capabilities [and quirks, if needed] in a
      straightforward way, without having to think about "IRQ flow"
      (level/edge/etc.) type of details.
      
      This stands in contrast with the current 'irq-type' model of genirq
      architectures, which 'mixes' raw hardware capabilities with 'flow' details.
      The patchset supports both types of irq controller designs at once, and
      converts i386 and x86_64 to the new irq-chip design.
      
      As a bonus side-effect of the irq-chip approach, chained interrupt controllers
      (master/slave PIC constructs, etc.) are now supported by design as well.
      
      The end result of this patchset intends to be simpler architecture-level code
      and more consolidation between architectures.
      
      We reused many bits of code and many concepts from Russell King's ARM IRQ
      layer, the merging of which was one of the motivations for this patchset.
      
      This patch:
      
      rename desc->handler to desc->chip.
      
      Originally i did not want to do this, because it's a big patch.  But having
      both "desc->handler", "desc->handle_irq" and "action->handler" caused a
      large degree of confusion and made the code appear alot less clean than it
      truly is.
      
      I have also attempted a dual approach as well by introducing a
      desc->chip alias - but that just wasnt robust enough and broke
      frequently.
      
      So lets get over with this quickly.  The conversion was done automatically
      via scripts and converts all the code in the kernel.
      
      This renaming patch is the first one amongst the patches, so that the
      remaining patches can stay flexible and can be merged and split up
      without having some big monolithic patch act as a merge barrier.
      
      [akpm@osdl.org: build fix]
      [akpm@osdl.org: another build fix]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d1bef4ed
  18. 23 6月, 2006 1 次提交
    • Z
      [PATCH] x86: kernel irq balance doesn't work · 1b61b910
      Zhang Yanmin 提交于
      On i386, kernel irq balance doesn't work.
      
      1) In function do_irq_balance, after kernel finds the min_loaded cpu but
         before calling set_pending_irq to really pin the selected_irq to the
         target cpu, kernel does a cpus_and with irq_affinity[selected_irq].
         Later on, when the irq is acked, kernel would calls
         move_native_irq=>desc->handler->set_affinity to change the irq affinity.
          However, every function pointed by
         hw_interrupt_type->set_affinity(unsigned int irq, cpumask_t cpumask)
         always changes irq_affinity[irq] to cpumask.  Next time when recalling
         do_irq_balance, it has to do cpu_ands again with
         irq_affinity[selected_irq], but irq_affinity[selected_irq] already
         becomes one cpu selected by the first irq balance.
      
      2) Function balance_irq in file arch/i386/kernel/io_apic.c has the same
         issue.
      
      [akpm@osdl.org: cleanups]
      Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1b61b910
  19. 09 1月, 2006 1 次提交
  20. 07 1月, 2006 1 次提交
  21. 08 9月, 2005 1 次提交
    • A
      [PATCH] x86/x86_64: deferred handling of writes to /proc/irqxx/smp_affinity · 54d5d424
      Ashok Raj 提交于
      When handling writes to /proc/irq, current code is re-programming rte
      entries directly. This is not recommended and could potentially cause
      chipset's to lockup, or cause missing interrupts.
      
      CONFIG_IRQ_BALANCE does this correctly, where it re-programs only when the
      interrupt is pending. The same needs to be done for /proc/irq handling as well.
      Otherwise user space irq balancers are really not doing the right thing.
      
      - Changed pending_irq_balance_cpumask to pending_irq_migrate_cpumask for
        lack of a generic name.
      - added move_irq out of IRQ_BALANCE, and added this same to X86_64
      - Added new proc handler for write, so we can do deferred write at irq
        handling time.
      - Display of /proc/irq/XX/smp_affinity used to display CPU_MASKALL, instead
        it now shows only active cpu masks, or exactly what was set.
      - Provided a common move_irq implementation, instead of duplicating
        when using generic irq framework.
      
      Tested on i386/x86_64 and ia64 with CONFIG_PCI_MSI turned on and off.
      Tested UP builds as well.
      
      MSI testing: tbd: I have cards, need to look for a x-over cable, although I
      did test an earlier version of this patch.  Will test in a couple days.
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Acked-by: NZwane Mwaikambo <zwane@holomorphy.com>
      Grudgingly-acked-by: NAndi Kleen <ak@muc.de>
      Signed-off-by: NCoywolf Qi Hunt <coywolf@lovecn.org>
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      54d5d424
  22. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4