Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 09 1月, 2006 12 次提交
  3. 07 1月, 2006 9 次提交
  5. 20 12月, 2005 1 次提交
  7. 17 12月, 2005 1 次提交
  9. 12 12月, 2005 2 次提交
  11. 05 12月, 2005 1 次提交
    • P
      ppc: Build in all three of powermac, PREP and CHRP support · b6d78157
      由 Paul Mackerras 提交于 
      This reverts commit da0825fd, making
it so that if you select CONFIG_PPC_MULTIPLATFORM you get support
for PMAC, PREP and CHRP built in.

The reason for not allowing PMAC, PREP and CHRP to be selected
individually for ARCH=ppc is that there is too much interdependency
between them in the platform support code.  For example, CHRP uses
the PMAC nvram code.

Configuring with ARCH=powerpc does allow you to select support for
PMAC and CHRP separately.  Support for PREP is not there yet but
should be there soon.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b6d78157
  13. 02 12月, 2005 2 次提交
  15. 30 11月, 2005 2 次提交
    • P
      [PATCH] ppc: fix floating point register corruption · 9f232a12
      由 Paolo Galtieri 提交于 
      I recently discovered a bug on PPC which causes the floating point
registers to get corrupted when CONFIG_PREEMPT=y.

The problem occurred while running a multi threaded Java application that
does floating point.  The problem could be reproduced in anywhere from 2 to
6 hours.  With the patch I have included below it ran for over a week
without failure.
Signed-off-by: NPaolo Galtieri <pgaltieri@mvista.com>
Cc: Kumar Gala <galak@gate.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Tom Rini <trini@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9f232a12
    • P
      [PATCH] ppc: fix floating point register corruption · 8117ce76
      由 Paolo Galtieri 提交于 
      I recently discovered a bug on PPC which causes the floating point
registers to get corrupted when CONFIG_PREEMPT=y.

The problem occurred while running a multi threaded Java application that
does floating point.  The problem could be reproduced in anywhere from 2 to
6 hours.  With the patch I have included below it ran for over a week
without failure.
Signed-off-by: NPaolo Galtieri <pgaltieri@mvista.com>
Cc: Kumar Gala <galak@gate.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Tom Rini <trini@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      8117ce76
  17. 29 11月, 2005 1 次提交
  19. 18 11月, 2005 5 次提交
  21. 16 11月, 2005 3 次提交
    • B
      [PATCH] ppc: Fix build with CONFIG_CHRP not set · d3ed6583
      由 Benjamin Herrenschmidt 提交于 
      Building ARCH=ppc for multiplatforms with CONFIG_CHRP not set fails
due to some unshielded code in xmon
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d3ed6583
    • B
      [PATCH] ppc: Fix boot with yaboot with ARCH=ppc · de93f0d6
      由 Benjamin Herrenschmidt 提交于 
      The merge of machine types broke boot with yaboot & ARCH=ppc due to the
old code still retreiving the old-syle machine type passed in by yaboot.
This patch fixes it by translating those old numbers. Since that whole
mecanism is deprecated, this is a temporary fix until ARCH=ppc uses the
new prom_init that the merged architecture now uses for both ppc32 and
ppc64 (after 2.6.15)
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      de93f0d6
    • 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
  23. 14 11月, 2005 1 次提交