Skip to content
  1. Apr 28, 2006
    • Eugene Surovegin's avatar
      [PATCH] ppc32: add 440GX erratum 440_43 workaround · 30aacebe
      Eugene Surovegin authored 
      

This patch adds workaround for PPC 440GX erratum 440_43. According to
this erratum spurious MachineChecks (caused by L1 cache parity) can
happen during DataTLB miss processing. We disable L1 cache parity
checking for 440GX rev.C and rev.F

Signed-off-by: default avatarEugene Surovegin <ebs@ebshome.net>
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      30aacebe
    • David Woodhouse's avatar
      [PATCH] powerpc: Use check_legacy_ioport() on ppc32 too. · 1269277a
      David Woodhouse authored 
      

Some people report that we die on some Macs when we are expecting to
catch machine checks after poking at some random I/O address. I'd seen
it happen on my dual G4 with serial ports until we fixed those to use
OF, but now other users are reporting it with i8042.

This expands the use of check_legacy_ioport() to avoid that situation
even on 32-bit kernels.

Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      1269277a
    • David Gibson's avatar
      [PATCH] powerpc: Fix pagetable bloat for hugepages · f10a04c0
      David Gibson authored 
      

At present, ARCH=powerpc kernels can waste considerable space in
pagetables when making large hugepage mappings.  Hugepage PTEs go in
PMD pages, but each PMD page maps 256M and so contains only 16
hugepage PTEs (128 bytes of data), but takes up a 1024 byte
allocation.  With CONFIG_PPC_64K_PAGES enabled (64k base page size),
the situation is worse.  Now hugepage PTEs are at the PTE page level
(also mapping 256M), so we store 16 hugepage PTEs in a 64k allocation.

The PowerPC MMU already means that any 256M region is either all
hugepage, or all normal pages.  Thus, with some care, we can use a
different allocation for the hugepage PTE tables and only allocate the
128 bytes necessary.

Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      f10a04c0
  3. Apr 27, 2006
    • Cliff Wickman's avatar
      [IA64] enable dumps to capture second page of kernel stack · 1df57c0c
      Cliff Wickman authored 
      

In SLES10 (2.6.16) crash dumping (in my experience, LKCD) is unable to
capture the second page of the 2-page task/stack allocation.
This is particularly troublesome for dump analysis, as the stack traceback
cannot be done.
  (A similar convention is probably needed throughout the kernel to make
   kernel multi-page allocations detectable for dumping)

Multi-page kernel allocations are represented by the single page structure
associated with the first page of the allocation.  The page structures
associated with the other pages are unintialized.

If the dumper is selecting only kernel pages it has no way to identify
any but the first page of the allocation.

The fix is to make the task/stack allocation a compound page.

Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      1df57c0c
    • Jack Steiner's avatar
      [IA64-SGI] - Fix discover of nearest cpu node to IO node · f0fe253c
      Jack Steiner authored 
      

Fix a bug that causes discovery of the nearest node/cpu to
a TIO (IO node) to fail.

Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      f0fe253c
    • Adrian Bunk's avatar
      [PATCH] Kobject: possible cleanups · 5b3ef14e
      Adrian Bunk authored 
      

This patch contains the following possible cleanups:
- #if 0 the following unused global function:
  - subsys_remove_file()
- remove the following unused EXPORT_SYMBOL's:
  - kset_find_obj
  - subsystem_init
- remove the following unused EXPORT_SYMBOL_GPL:
  - kobject_add_dir

Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5b3ef14e
    • Jean Delvare's avatar
      [PATCH] Fix OCFS2 warning when DEBUG_FS is not enabled · bde11d79
      Jean Delvare authored 
      

Fix the following warning which happens when OCFS2_FS is enabled but
DEBUG_FS isn't:

fs/ocfs2/dlmglue.c: In function `ocfs2_dlm_init_debug':
fs/ocfs2/dlmglue.c:2036: warning: passing arg 5 of `debugfs_create_file' discards qualifiers from pointer target type

Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Joel Becker <Joel.Becker@oracle.com>
Acked-by: default avatarMark Fasheh <mark.fasheh@oracle.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      bde11d79
    • Kay Sievers's avatar
      [PATCH] Kobject: fix build error · 4d17ffda
      Kay Sievers authored 
      

This fixes a build error for various odd combinations of CONFIG_HOTPLUG
and CONFIG_NET.

Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
Cc: Nigel Cunningham <ncunningham@cyclades.com>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4d17ffda
    • Zachary Amsden's avatar
      [PATCH] x86/PAE: Fix pte_clear for the >4GB RAM case · 6e5882cf
      Zachary Amsden authored 
      

Proposed fix for ptep_get_and_clear_full PAE bug.  Pte_clear had the same bug,
so use the same fix for both.  Turns out pmd_clear had it as well, but pgds
are not affected.

The problem is rather intricate.  Page table entries in PAE mode are 64-bits
wide, but the only atomic 8-byte write operation available in 32-bit mode is
cmpxchg8b, which is expensive (at least on P4), and thus avoided.  But it can
happen that the processor may prefetch entries into the TLB in the middle of an
operation which clears a page table entry.  So one must always clear the P-bit
in the low word of the page table entry first when clearing it.

Since the sequence *ptep = __pte(0) leaves the order of the write dependent on
the compiler, it must be coded explicitly as a clear of the low word followed
by a clear of the high word.  Further, there must be a write memory barrier
here to enforce proper ordering by the compiler (and, in the future, by the
processor as well).

On > 4GB memory machines, the implementation of pte_clear for PAE was clearly
deficient, as it could leave virtual mappings of physical memory above 4GB
aliased to memory below 4GB in the TLB.  The implementation of
ptep_get_and_clear_full has a similar bug, although not nearly as likely to
occur, since the mappings being cleared are in the process of being destroyed,
and should never be dereferenced again.

But, as luck would have it, it is possible to trigger bugs even without ever
dereferencing these bogus TLB mappings, even if the clear is followed fairly
soon after with a TLB flush or invalidation.  The problem is that memory above
4GB may now be aliased into the first 4GB of memory, and in fact, may hit a
region of memory with non-memory semantics.  These regions include AGP and PCI
space.  As such, these memory regions are not cached by the processor.  This
introduces the bug.

The processor can speculate memory operations, including memory writes, as long
as they are committed with the proper ordering.  Speculating a memory write to
a linear address that has a bogus TLB mapping is possible.  Normally, the
speculation is harmless.  But for cached memory, it does leave the falsely
speculated cacheline unmodified, but in a dirty state.  This cache line will be
eventually written back.  If this cacheline happens to intersect a region of
memory that is not protected by the cache coherency protocol, it can corrupt
data in I/O memory, which is generally a very bad thing to do, and can cause
total system failure or just plain undefined behavior.

These bugs are extremely unlikely, but the severity is of such magnitude, and
the fix so simple that I think fixing them immediately is justified.  Also,
they are nearly impossible to debug.

Signed-off-by: default avatarZachary Amsden <zach@vmware.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6e5882cf
    • Chris Dearman's avatar
      [MIPS] 24K LV: Add core card id. · 7a834196
      Chris Dearman authored 
      
    
Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      7a834196
    • Atsushi Nemoto's avatar
      [MIPS] Fix bitops for MIPS32/MIPS64 CPUs. · bc818247
      Atsushi Nemoto authored 
      
    
With recent rewrite for generic bitops, fls() for 32bit kernel with
MIPS64_CPU is broken.  Also, ffs(), fls() should be defined the same
way as the libc and compiler built-in routines (returns int instead of
unsigned long).
    
Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      bc818247
    • Jens Axboe's avatar
      [PATCH] Add find_get_pages_contig(): contiguous variant of find_get_pages() · ebf43500
      Jens Axboe authored 
      

find_get_pages_contig() will break out if we hit a hole in the page cache.
From Andrew Morton, small modifications and documentation by me.

Signed-off-by: default avatarJens Axboe <axboe@suse.de>
      ebf43500
  5. Apr 26, 2006
  7. Apr 25, 2006
  9. Apr 24, 2006
  11. Apr 23, 2006
  13. Apr 21, 2006
  15. Apr 20, 2006
  17. Apr 19, 2006