An error occurred fetching the project authors.
  1. 31 Mar, 2006 1 commit
  2. 15 Feb, 2006 1 commit
    • hawkes@sgi.com's avatar
      [IA64] ia64: simplify and fix udelay() · defbb2c9
      hawkes@sgi.com authored
      The original ia64 udelay() was simple, but flawed for platforms without
      synchronized ITCs:  a preemption and migration to another CPU during the
      while-loop likely resulted in too-early termination or very, very
      lengthy looping.
      
      The first fix (now in 2.6.15) broke the delay loop into smaller,
      non-preemptible chunks, reenabling preemption between the chunks.  This
      fix is flawed in that the total udelay is computed to be the sum of just
      the non-premptible while-loop pieces, i.e., not counting the time spent
      in the interim preemptible periods.  If an interrupt or a migration
      occurs during one of these interim periods, then that time is invisible
      and only serves to lengthen the effective udelay().
      
      This new fix backs out the current flawed fix and returns to a simple
      udelay(), fully preemptible and interruptible.  It implements two simple
      alternative udelay() routines:  one a default generic version that uses
      ia64_get_itc(), and the other an sn-specific version that uses that
      platform's RTC.
      Signed-off-by: default avatarJohn Hawkes <hawkes@sgi.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      defbb2c9
  3. 07 Feb, 2006 1 commit
    • Tony Luck's avatar
      [IA64] Fix CONFIG_PRINTK_TIME · d6e56a2a
      Tony Luck authored
      There were two problems with enabling the PRINTK_TIME config
      option:
      1) The first calls to printk() occur before per-cpu data virtual
      address is pinned into the TLB, so sched_clock() can fault.
      2) sched_clock() is based on ar.itc, which may not be synchronized
      across cpus.
      
      Ken Chen started this patch, Tony Luck tinkered with it, and Jes
      Sorensen perfected it.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      d6e56a2a
  4. 05 Jan, 2006 1 commit
    • Ashok Raj's avatar
      [IA64] support for cpu0 removal · ff741906
      Ashok Raj authored
      here is the BSP removal support for IA64. Its pretty much the same thing that
      was released a while back, but has your feedback incorporated.
      
      - Removed CONFIG_BSP_REMOVE_WORKAROUND and associated cmdline param
      - Fixed compile issue with sn2/zx1 due to a undefined fix_b0_for_bsp
      - some formatting nits (whitespace etc)
      
      This has been tested on tiger and long back by alex on hp systems as well.
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      ff741906
  5. 16 Dec, 2005 1 commit
    • John Hawkes's avatar
      [IA64] disable preemption in udelay() · f5899b5d
      John Hawkes authored
      The udelay() inline for ia64 uses the ITC.  If CONFIG_PREEMPT is enabled
      and the platform has unsynchronized ITCs and the calling task migrates
      to another CPU while doing the udelay loop, then the effective delay may
      be too short or very, very long.
      
      This patch disables preemption around 100 usec chunks of the overall
      desired udelay time.  This minimizes preemption-holdoffs.
      
      udelay() is now too big to be inline, move it out of line and export it.
      Signed-off-by: default avatarJohn Hawkes <hawkes@sgi.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      f5899b5d
  6. 31 Oct, 2005 1 commit
  7. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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