1. 01 Apr, 2004 6 commits
    • Andrew Morton's avatar
      [PATCH] siginfo.si_band is long · 112347bb
      Andrew Morton authored
      From: Marcus Meissner <meissner@suse.de>
      
      After discussion on the glibc list the result was that=20 si_band is "long
      int" according to POSIX:
      
      	http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html
      
      Ulrich Drepper refused a patch to fix glibc due to this reason:
      	http://sources.redhat.com/ml/libc-alpha/2004-03/msg00254.html
      
      so here is the patch to fix it in the kernel.
      
      ppc64 and s390x were broken before and are fixed by this patch too.
      112347bb
    • Andrew Morton's avatar
      [PATCH] ppc64: add useful warning message in hugepage code · 8d507e4e
      Andrew Morton authored
      From: David Gibson <david@gibson.dropbear.id.au>
      
      This patch adds a debugging message to the ppc64 hugepage code when we
      attempt to open the "low" (32-bit) hugepage window on PPC64, but can't
      because a (non-hugepage) mapping already exists in the region.
      8d507e4e
    • Andrew Morton's avatar
      [PATCH] ppc64: allow MAP_FIXED hugepage mappings · e9acfc13
      Andrew Morton authored
      From: David Gibson <david@gibson.dropbear.id.au>
      
      On PowerPC64 the "low" hugepage range (at 2-3G for use by 32-bit processes)
      needs to be activated before it can be used.  hugetlb_get_unmapped_area()
      automatically activates the range for hugepage mappings in 32-bit processes
      which are not MAP_FIXED.  However for MAP_FIXED mmap()s, even at a suitable
      address will fail if the region is not already activated, because there is
      no suitable callback from the generic MAP_FIXED code path into the arch
      code.
      
      This patch corrects this problem and allows PPC64 to do MAP_FIXED hugepage
      mappings in the low hugepage range.
      e9acfc13
    • Andrew Morton's avatar
      [PATCH] ppc64: bugfix for hugepage support · ccfcbaed
      Andrew Morton authored
      From: David Gibson <david@gibson.dropbear.id.au>
      
      Due to a misunderstanding of pmd_offset() the PPC64 hugepage code could end
      up looking at bogus pages as if they were PMD pages.
      ccfcbaed
    • Andrew Morton's avatar
      [PATCH] ppc64: create dma_mapping_error · 007658d4
      Andrew Morton authored
      From: Anton Blanchard <anton@samba.org>
      
      From: Stephen Rothwell <sfr@canb.auug.org.au>
      
      This creates DMA_ERROR_CODE and uses it everywhere instead of
      PCI_DMA_ERROR_CODE as we really want the three DMA mapping API's to return
      a single error code.  Also we now have dma_mapping_error and
      vio_dma_mapping_error - and this latter and pci_dma_mapping_error both just
      call the former.
      
      Also a small fix in the vscsi - dma_map_sg returns 0 to indicate an error.
      007658d4
    • Andrew Morton's avatar
      [PATCH] PPC32 build fix · a460c410
      Andrew Morton authored
      From: Matt Porter <mporter@kernel.crashing.org>
      
      This fixes the build on non cache coherent PPC32 platforms.
      a460c410
  2. 31 Mar, 2004 2 commits
  3. 01 Apr, 2004 1 commit
  4. 31 Mar, 2004 4 commits
  5. 01 Apr, 2004 16 commits
  6. 31 Mar, 2004 11 commits