12 May, 2007

1 commit

  • On SN, only allow one bit to be set in the smp_affinty mask when
    redirecting an interrupt. Currently setting multiple bits is allowed, but
    only the first bit is used in determining the CPU to redirect to. This has
    caused confusion among some customers.

    [akpm@linux-foundation.org: fixes]
    Signed-off-by: John Keller
    Signed-off-by: Andrew Morton
    Signed-off-by: Tony Luck

    John Keller
     

09 May, 2007

1 commit


17 Feb, 2007

2 commits

  • Provide funtions to:
    - check, whether an interrupt can set the affinity
    - pin the interrupt to a given cpu

    Necessary for the ability to setup clocksources more flexible (e.g. use the
    different HPET channels per CPU)

    [akpm@osdl.org: alpha build fix]
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Cc: john stultz
    Cc: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     
  • Add a flag so we can prevent the irq balancing of an interrupt. Move the
    bits, so we have room for more :)

    Necessary for the ability to setup clocksources more flexible (e.g. use the
    different HPET channels per CPU)

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Cc: john stultz
    Cc: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     

12 Feb, 2007

1 commit

  • Bug: pnx8550 code creates directory but resets ->nlink to 1.

    create_proc_entry() et al will correctly set ->nlink for you.

    Signed-off-by: Alexey Dobriyan
    Cc: Ralf Baechle
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Jeff Dike
    Cc: Corey Minyard
    Cc: Alan Cox
    Cc: Kyle McMartin
    Cc: Martin Schwidefsky
    Cc: Greg KH
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

09 Dec, 2006

1 commit

  • 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:
    > [] show_stack+0x40/0xa0
    > sp=e00000006b2578d0 bsp=e00000006b2510b0
    > [] dump_stack+0x30/0x60
    > sp=e00000006b257aa0 bsp=e00000006b251098
    > [] move_masked_irq+0xb0/0x240
    > sp=e00000006b257aa0 bsp=e00000006b251070
    > [] move_native_irq+0xe0/0x180
    > sp=e00000006b257aa0 bsp=e00000006b251040
    > [] iosapic_end_level_irq+0x30/0xe0
    > sp=e00000006b257aa0 bsp=e00000006b251020
    > [] __do_IRQ+0x170/0x400
    > sp=e00000006b257aa0 bsp=e00000006b250fd8
    > [] ia64_handle_irq+0x1b0/0x260
    > sp=e00000006b257aa0 bsp=e00000006b250fa8
    > [] ia64_leave_kernel+0x0/0x280
    > sp=e00000006b257aa0 bsp=e00000006b250fa8
    > [] _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: Hidetoshi Seto
    Cc: Arjan van de Ven
    Acked-by: Ingo Molnar
    Acked-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hidetoshi Seto
     

12 Oct, 2006

1 commit

  • 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: Reinette Chatre
    Signed-off-by: Inaky Perez-Gonzalez
    Cc: Paul Jackson
    Cc: Joe Korty
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Reinette Chatre
     

30 Jun, 2006

4 commits

  • Rename no_irq_type to no_irq_chip.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    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: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    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: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    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: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

23 Jun, 2006

1 commit

  • 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: Zhang Yanmin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zhang Yanmin
     

09 Jan, 2006

1 commit

  • This patch contains the following cleanups:
    - make needlessly global functions static
    - every file should include the headers containing the prototypes for
    it's global functions

    Signed-off-by: Adrian Bunk
    Acked-by: "Paul E. McKenney"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

07 Jan, 2006

1 commit

  • Thanks to Christoph for doing most of the work.

    This allows automatic SMP IRQ affinity assignment other than default "all
    interrupts on all CPUs" which is rather expensive. This might be useful if
    the hardware can be programmed to distribute interrupts among different
    CPUs, like Alpha does.

    Signed-off-by: Ivan Kokshaysky
    Cc: Christoph Hellwig
    Cc: Richard Henderson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ivan Kokshaysky
     

08 Sep, 2005

1 commit

  • 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: Ashok Raj
    Acked-by: Zwane Mwaikambo
    Grudgingly-acked-by: Andi Kleen
    Signed-off-by: Coywolf Qi Hunt
    Signed-off-by: Ashok Raj
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ashok Raj
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds