1. 26 4月, 2005 5 次提交
  2. 23 4月, 2005 1 次提交
    • A
      [IA64] cpu hotplug: return offlined cpus to SAL · b8d8b883
      Ashok Raj 提交于
      This patch is required to support cpu removal for IPF systems. Existing code
      just fakes the real offline by keeping it run the idle thread, and polling
      for the bit to re-appear in the cpu_state to get out of the idle loop.
      
      For the cpu-offline to work correctly, we need to pass control of this CPU 
      back to SAL so it can continue in the boot-rendez mode. This gives the
      SAL control to not pick this cpu as the monarch processor for global MCA
      events, and addition does not wait for this cpu to checkin with SAL
      for global MCA events as well. The handoff is implemented as documented in 
      SAL specification section 3.2.5.1 "OS_BOOT_RENDEZ to SAL return State"
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      b8d8b883
  3. 22 4月, 2005 1 次提交
    • D
      [IA64] fix fls() · 821376bf
      David Mosberger-Tang 提交于
      The ia64-version of fls() never worked as intended (the bitnumbering
      was off by 1 and fls(0) was undefined).  This patch fixes the problem
      by using a popcnt-based fls(), which on McKinley-derived cores is
      slightly faster than both ia64_fls() and generic_fls().  The resulting
      code, however, is bigger (7-8 bundles instead of about 3 bundles).
      Also switch ia64_popcnt() to __builtin_popcountl() for GCC v3.4 or
      newer since the compiler can predicate that and schedule it better.
      
      Thanks to Simon Derr and Matt Mackall for tracking down this bug.
      Signed-off-by: NDavid Mosberger-Tang <davidm@hpl.hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      821376bf
  4. 20 4月, 2005 4 次提交
    • H
      [PATCH] freepgt: arch FIRST_USER_ADDRESS 0 · d455a369
      Hugh Dickins 提交于
      Replace misleading definition of FIRST_USER_PGD_NR 0 by definition of
      FIRST_USER_ADDRESS 0 in all the MMU architectures beyond arm and arm26.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d455a369
    • H
      [PATCH] freepgt: remove arch pgd_addr_end · 8f6c99c1
      Hugh Dickins 提交于
      ia64 and sparc64 hurriedly had to introduce their own variants of
      pgd_addr_end, to leapfrog over the holes in their virtual address spaces which
      the final clear_page_range suddenly presented when converted from pgd_index to
      pgd_addr_end.  But now that free_pgtables respects the vma list, those holes
      are never presented, and the arch variants can go.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8f6c99c1
    • H
      [PATCH] freepgt: hugetlb_free_pgd_range · 3bf5ee95
      Hugh Dickins 提交于
      ia64 and ppc64 had hugetlb_free_pgtables functions which were no longer being
      called, and it wasn't obvious what to do about them.
      
      The ppc64 case turns out to be easy: the associated tables are noted elsewhere
      and freed later, safe to either skip its hugetlb areas or go through the
      motions of freeing nothing.  Since ia64 does need a special case, restore to
      ppc64 the special case of skipping them.
      
      The ia64 hugetlb case has been broken since pgd_addr_end went in, though it
      probably appeared to work okay if you just had one such area; in fact it's
      been broken much longer if you consider a long munmap spanning from another
      region into the hugetlb region.
      
      In the ia64 hugetlb region, more virtual address bits are available than in
      the other regions, yet the page tables are structured the same way: the page
      at the bottom is larger.  Here we need to scale down each addr before passing
      it to the standard free_pgd_range.  Was about to write a hugely_scaled_down
      macro, but found htlbpage_to_page already exists for just this purpose.  Fixed
      off-by-one in ia64 is_hugepage_only_range.
      
      Uninline free_pgd_range to make it available to ia64.  Make sure the
      vma-gathering loop in free_pgtables cannot join a hugepage_only_range to any
      other (safe to join huges?  probably but don't bother).
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3bf5ee95
    • H
      [PATCH] freepgt: remove MM_VM_SIZE(mm) · ee39b37b
      Hugh Dickins 提交于
      There's only one usage of MM_VM_SIZE(mm) left, and it's a troublesome macro
      because mm doesn't contain the (32-bit emulation?) info needed.  But it too is
      only needed because we ignore the end from the vma list.
      
      We could make flush_pgtables return that end, or unmap_vmas.  Choose the
      latter, since it's a natural fit with unmap_mapping_range_vma needing to know
      its restart addr.  This does make more than minimal change, but if unmap_vmas
      had returned the end before, this is how we'd have done it, rather than
      storing the break_addr in zap_details.
      
      unmap_vmas used to return count of vmas scanned, but that's just debug which
      hasn't been useful in a while; and if we want the map_count 0 on exit check
      back, it can easily come from the final remove_vm_struct loop.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ee39b37b
  5. 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