1. 07 Sep, 2005 5 commits
    • Pekka Enberg's avatar
      [PATCH] IA64: convert kcalloc to kzalloc · f96cb1f0
      Pekka Enberg authored
      
      
      This patch converts kcalloc(1, ...) calls to use the new kzalloc() function.
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f96cb1f0
    • Miklos Szeredi's avatar
      [PATCH] remove duplicated sys_open32() code from 64bit archs · e922efc3
      Miklos Szeredi authored
      
      
      64 bit architectures all implement their own compatibility sys_open(),
      when in fact the difference is simply not forcing the O_LARGEFILE
      flag.  So use the a common function instead.
      Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Cc: <viro@parcelfarce.linux.theplanet.co.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e922efc3
    • John Hawkes's avatar
    • John Hawkes's avatar
      [PATCH] ia64 cpuset + build_sched_domains() mangles structures · f68f447e
      John Hawkes authored
      
      
      I've already sent this to the maintainers, and this is now being sent to a
      larger community audience.  I have fixed a problem with the ia64 version of
      build_sched_domains(), but a similar fix still needs to be made to the
      generic build_sched_domains() in kernel/sched.c.
      
      The "dynamic sched domains" functionality has recently been merged into
      2.6.13-rcN that sees the dynamic declaration of a cpu-exclusive (a.k.a.
      "isolated") cpuset and rebuilds the CPU Scheduler sched domains and sched
      groups to separate away the CPUs in this cpu-exclusive cpuset from the
      remainder of the non-isolated CPUs.  This allows the non-isolated CPUs to
      completely ignore the isolated CPUs when doing load-balancing.
      
      Unfortunately, build_sched_domains() expects that a sched domain will
      include all the CPUs of each node in the domain, i.e., that no node will
      belong in both an isolated cpuset and a non-isolated cpuset.  Declaring a
      cpuset that violates this presumption will produce flawed data structures
      and will oops the kernel.
      
      To trigger the problem (on a NUMA system with >1 CPUs per node):
         cd /dev/cpuset
         mkdir newcpuset
         cd newcpuset
         echo 0 >cpus
         echo 0 >mems
         echo 1 >cpu_exclusive
      
      I have fixed this shortcoming for ia64 NUMA (with multiple CPUs per node).
      A similar shortcoming exists in the generic build_sched_domains() (in
      kernel/sched.c) for NUMA, and that needs to be fixed also.  The fix
      involves dynamically allocating sched_group_nodes[] and
      sched_group_allnodes[] for each invocation of build_sched_domains(), rather
      than using global arrays for these structures.  Care must be taken to
      remember kmalloc() addresses so that arch_destroy_sched_domains() can
      properly kfree() the new dynamic structures.
      Signed-off-by: default avatarJohn Hawkes <hawkes@sgi.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f68f447e
    • Ashok Raj's avatar
      [PATCH] x86/x86_64: deferred handling of writes to /proc/irqxx/smp_affinity · 54d5d424
      Ashok Raj authored
      
      
      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: default avatarAshok Raj <ashok.raj@intel.com>
      Acked-by: default avatarZwane Mwaikambo <zwane@holomorphy.com>
      Grudgingly-acked-by: default avatarAndi Kleen <ak@muc.de>
      Signed-off-by: default avatarCoywolf Qi Hunt <coywolf@lovecn.org>
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      54d5d424
  2. 31 Aug, 2005 1 commit
  3. 29 Aug, 2005 1 commit
    • Steven Rostedt's avatar
      [PATCH] convert signal handling of NODEFER to act like other Unix boxes. · 69be8f18
      Steven Rostedt authored
      
      
      It has been reported that the way Linux handles NODEFER for signals is
      not consistent with the way other Unix boxes handle it.  I've written a
      program to test the behavior of how this flag affects signals and had
      several reports from people who ran this on various Unix boxes,
      confirming that Linux seems to be unique on the way this is handled.
      
      The way NODEFER affects signals on other Unix boxes is as follows:
      
      1) If NODEFER is set, other signals in sa_mask are still blocked.
      
      2) If NODEFER is set and the signal is in sa_mask, then the signal is
      still blocked. (Note: this is the behavior of all tested but Linux _and_
      NetBSD 2.0 *).
      
      The way NODEFER affects signals on Linux:
      
      1) If NODEFER is set, other signals are _not_ blocked regardless of
      sa_mask (Even NetBSD doesn't do this).
      
      2) If NODEFER is set and the signal is in sa_mask, then the signal being
      handled is not blocked.
      
      The patch converts signal handling in all current Linux architectures to
      the way most Unix boxes work.
      
      Unix boxes that were tested:  DU4, AIX 5.2, Irix 6.5, NetBSD 2.0, SFU
      3.5 on WinXP, AIX 5.3, Mac OSX, and of course Linux 2.6.13-rcX.
      
      * NetBSD was the only other Unix to behave like Linux on point #2. The
      main concern was brought up by point #1 which even NetBSD isn't like
      Linux.  So with this patch, we leave NetBSD as the lonely one that
      behaves differently here with #2.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      69be8f18
  4. 26 Aug, 2005 4 commits
  5. 24 Aug, 2005 8 commits
  6. 23 Aug, 2005 2 commits
  7. 18 Aug, 2005 2 commits
    • Alex Williamson's avatar
      [IA64, X86_64] fix swiotlb sizing · e8579e72
      Alex Williamson authored
      
      
         Fix swiotlb sizing to match what the comments and the kernel
      parameters documentation indicate.  Given a default 16k page size kernel
      (ia64) and a 2k swiotlb page size, we're off by a multiple of 8 trying
      to size the swiotlb.  When specified on the boot line, the swiotlb is
      made 8x bigger than requested.  When left to the default value, it's 8x
      smaller than the comments indicate.  For x86_64 the multiplier would be
      2x.  The patch below fixes this.  Now, what's a good default swiotlb
      size?  Apparently we don't really need 64MB.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@hp.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      e8579e72
    • Ian Wienand's avatar
      [IA64] Simulator bootloader fails with gcc 4 · 4aec0fb1
      Ian Wienand authored
      
      After building a fresh tree with gcc 4 I can't boot the simulator as
      the bootloader loader dies with 
      
      loading /home/ianw/kerntest/kerncomp//build/sim_defconfig/vmlinux...
      failed to read phdr
      
      After some investigation I believe this is do with differences between
      the alignment of variables on the stack between gcc 3 and 4 and the
      ski simulator.  If you trace through with the simulator you can see
      that the disk_stat structure value returned from the SSC_WAIT_COMPLETION
      call seems to be only half loaded.  I guess it doesn't like the alignment
      of the input.
      Signed-off-by: default avatarIan Wienand <ianw@gelato.unsw.edu.au>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      4aec0fb1
  8. 17 Aug, 2005 7 commits
  9. 16 Aug, 2005 5 commits
  10. 15 Aug, 2005 1 commit
  11. 11 Aug, 2005 4 commits