1. 01 4月, 2008 1 次提交
  2. 28 1月, 2008 1 次提交
  3. 20 11月, 2007 1 次提交
  4. 12 5月, 2007 1 次提交
  5. 12 10月, 2006 1 次提交
    • M
      [PATCH] mm: use symbolic names instead of indices for zone initialisation · 6391af17
      Mel Gorman 提交于
      Arch-independent zone-sizing is using indices instead of symbolic names to
      offset within an array related to zones (max_zone_pfns).  The unintended
      impact is that ZONE_DMA and ZONE_NORMAL is initialised on powerpc instead
      of ZONE_DMA and ZONE_HIGHMEM when CONFIG_HIGHMEM is set.  As a result, the
      the machine fails to boot but will boot with CONFIG_HIGHMEM turned off.
      
      The following patch properly initialises the max_zone_pfns[] array and uses
      symbolic names instead of indices in each architecture using
      arch-independent zone-sizing.  Two users have successfully booted their
      powerpcs with it (one an ibook G4).  It has also been boot tested on x86,
      x86_64, ppc64 and ia64.  Please merge for 2.6.19-rc2.
      
      Credit to Benjamin Herrenschmidt for identifying the bug and rolling the
      first fix.  Additional credit to Johannes Berg and Andreas Schwab for
      reporting the problem and testing on powerpc.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6391af17
  6. 27 9月, 2006 1 次提交
  7. 01 7月, 2006 1 次提交
  8. 13 6月, 2006 1 次提交
  9. 28 3月, 2006 1 次提交
    • P
      ppc: Remove CHRP, POWER3 and POWER4 support from arch/ppc · 0a26b136
      Paul Mackerras 提交于
      32-bit CHRP machines are now supported only in arch/powerpc, as are
      all 64-bit PowerPC processors.  This means that we don't use
      Open Firmware on any platform in arch/ppc any more.
      
      This makes PReP support a single-platform option like every other
      platform support option in arch/ppc now, thus CONFIG_PPC_MULTIPLATFORM
      is gone from arch/ppc.  CONFIG_PPC_PREP is the option that selects
      PReP support and is generally what has replaced
      CONFIG_PPC_MULTIPLATFORM within arch/ppc.
      
      _machine is all but dead now, being #defined to 0.
      
      Updated Makefiles, comments and Kconfig options generally to reflect
      these changes.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0a26b136
  10. 22 3月, 2006 1 次提交
  11. 15 1月, 2006 1 次提交
    • P
      [PATCH] ppc: Remove powermac support from ARCH=ppc · a7fdd90b
      Paul Mackerras 提交于
      This makes it possible to build kernels for PReP and/or CHRP
      with ARCH=ppc by removing the (non-building) powermac support.
      It's now also possible to select PReP and CHRP independently.
      Powermac users should now build with ARCH=powerpc instead of
      ARCH=ppc.  (This does mean that it is no longer possible to
      build a 32-bit kernel for a G5.)
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a7fdd90b
  12. 16 11月, 2005 1 次提交
    • M
      [PATCH] ppc32 8xx: update_mmu_cache() needs unconditional tlbie · eb07d964
      Marcelo Tosatti 提交于
      Currently 8xx fails to boot due to endless pagefaults.
      
      Seems the bug is exposed by the change which avoids flushing the
      TLB when not necessary (in case the pte has not changed), introduced
      recently:
      
      __handle_mm_fault():
      
              entry = pte_mkyoung(entry);
              if (!pte_same(old_entry, entry)) {
                      ptep_set_access_flags(vma, address, pte, entry, write_access);
                      update_mmu_cache(vma, address, entry);
                      lazy_mmu_prot_update(entry);
              } else {
                      /*
                       * This is needed only for protection faults but the arch code
                       * is not yet telling us if this is a protection fault or not.
                       * This still avoids useless tlb flushes for .text page faults
                       * with threads.
                       */
                      if (write_access)
                              flush_tlb_page(vma, address);
              }
      
      The "update_mmu_cache()" call was unconditional before, which caused the TLB
      to be flushed by:
      
              if (pfn_valid(pfn)) {
                      struct page *page = pfn_to_page(pfn);
                      if (!PageReserved(page)
                          && !test_bit(PG_arch_1, &page->flags)) {
                              if (vma->vm_mm == current->active_mm) {
      #ifdef CONFIG_8xx
                              /* On 8xx, cache control instructions (particularly 
                               * "dcbst" from flush_dcache_icache) fault as write 
                               * operation if there is an unpopulated TLB entry 
                               * for the address in question. To workaround that, 
                               * we invalidate the TLB here, thus avoiding dcbst 
                               * misbehaviour.
                               */
                                      _tlbie(address);
      #endif
                                      __flush_dcache_icache((void *) address);
                              } else
                                      flush_dcache_icache_page(page);
                              set_bit(PG_arch_1, &page->flags);
                      }
      
      Which worked to due to pure luck: PG_arch_1 was always unset before, but
      now it isnt.
      
      The root of the problem are the changes against the 8xx TLB handlers introduced
      during v2.6. What happens is the TLBMiss handlers load the zeroed pte into
      the TLB, causing the TLBError handler to be invoked (thats two TLB faults per 
      pagefault), which then jumps to the generic MM code to setup the pte.
      
      The bug is that the zeroed TLB is not invalidated (the same reason
      for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
      
      The "two exception" approach requires a TLB flush (to nuke the zeroed TLB)
      at each PTE update for correct behaviour:
      Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      eb07d964
  13. 29 10月, 2005 1 次提交
    • R
      [PATCH] ppc: make phys_mem_access_prot() work with pfns instead of addresses · 8b150478
      Roland Dreier 提交于
      Change the phys_mem_access_prot() function to take a pfn instead of an
      address.  This allows mmap64() to work on /dev/mem for addresses above 4G
      on 32-bit architectures.  We start with a pfn in mmap_mem(), so there's no
      need to convert to an address; in fact, it's actively bad, since the
      conversion can overflow when the address is above 4G.
      
      Similarly fix the ppc32 page_is_ram() function to avoid a conversion to an
      address by directly comparing to max_pfn.  Working with max_pfn instead of
      high_memory fixes page_is_ram() to give the right answer for highmem pages.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      8b150478
  14. 22 10月, 2005 1 次提交
  15. 19 9月, 2005 1 次提交
  16. 05 9月, 2005 2 次提交
  17. 28 7月, 2005 1 次提交
    • A
      [PATCH] ppc32: 8xx avoid icbi misbehaviour in __flush_dcache_icache_phys · bf85fa6c
      Anton Wllert 提交于
      On 8xx, in the case where a pagefault happens for a process who's not
      the owner of the vma in question (ptrace for instance), the flush
      operation is performed via the physical address.
      
      Unfortunately, that results in a strange, unexplainable "icbi"
      instruction fault, most likely due to a CPU bug (see oops below).
      
      Avoid that by flushing the page via its kernel virtual address.
      
      Oops: kernel access of bad area, sig: 11 [#2]
      NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not tainted
      MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
      DAR: 00000010, DSISR: C2000000
      TASK = c0ea8430[761] 'gdbserver' THREAD: c0f34000
      Last syscall: 26
      GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
      00000001
      GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
      00000001
      GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
      C01E0000
      GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
      C02ACB00
      NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
      LR [c000b060] flush_dcache_icache_page+0x20/0x30
      Call trace:
      [c000b154] update_mmu_cache+0x7c/0xa4
      [c005ae98] do_wp_page+0x460/0x5ec
      [c005c8a0] handle_mm_fault+0x7cc/0x91c
      [c005ccec] get_user_pages+0x2fc/0x65c
      [c0027104] access_process_vm+0x9c/0x1d4
      [c00076e0] sys_ptrace+0x240/0x4a4
      [c0002bd0] ret_from_syscall+0x0/0x44
      Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bf85fa6c
  18. 28 6月, 2005 1 次提交
    • M
      [PATCH] 8xx: avoid "dcbst" misbehaviour with unpopulated TLB · bb165746
      Marcelo Tosatti 提交于
      The proposed _tlbie call at update_mmu_cache() is safe because:
      
      Addresses for which update_mmu_cache() gets invocated are never inside the
      static kernel virtual mapping, meaning that there is no risk for the
      _tlbie() here to be thrashing the pinned entry, as Dan suspected.
      
      The intermediate TLB state in which this bug can be triggered is not
      visible by userspace or any other contexts, except the page fault handling
      path.  So there is no need to worry about userspace dcbxxx users.
      
      The other solution to this is to avoid dcbst misbehaviour in the first
      place, which involves changing in-kernel "dcbst" callers to use 8xx
      specific SPR's.
      
      Summary:
      
      On 8xx, cache control instructions (particularly "dcbst" from
      flush_dcache_icache) fault as write operation if there is an unpopulated
      TLB entry for the address in question.  To workaround that, we invalidate
      the TLB here, thus avoiding dcbst misbehaviour.
      Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bb165746
  19. 22 6月, 2005 2 次提交
  20. 20 5月, 2005 1 次提交
    • P
      [PATCH] ppc32: don't call progress functions after boot · 6c37a88c
      Paul Mackerras 提交于
      On ppc32, the platform code can supply a "progress" function that is
      used to show progress through the boot.  These functions are usually
      in an init section and so can't be called after the init pages are
      freed.  Now that the cpu bringup code can be called after the system
      is booted (for hotplug cpu) we can get the situation where the
      progress function can be called after boot.  The simple fix is to set
      the progress function pointer to NULL when the init pages are freed,
      and that is what this patch does (note that all callers already check
      whether the function pointer is NULL before trying to call it).
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6c37a88c
  21. 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