An error occurred fetching the project authors.
  1. 08 Mar, 2007 1 commit
    • Tony Luck's avatar
      [IA64] Pick highest possible saved_max_pfn for crash_dump · e55fdf11
      Tony Luck authored
      Berhhard Walle noted that on his HP rx8640 he ended up with saved_max_pfn
      smaller than the highest address of system ram in /proc/iomem and proposed
      a patch to base the address on the unrounded and unfiltered EFI memory
      map address.  Simon Horman and Magnus Damm suggested that the whole test
      be moved earlier in the function.  This is the combination of both of
      these patches.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      e55fdf11
  2. 06 Mar, 2007 2 commits
    • Magnus Damm's avatar
      [IA64] kexec: Use EFI_LOADER_DATA for ELF core header · cee87af2
      Magnus Damm authored
      The address where the ELF core header is stored is passed to the secondary
      kernel as a kernel command line option.  The memory area for this header is
      also marked as a separate EFI memory descriptor on ia64.
      
      The separate EFI memory descriptor is at the moment of the type
      EFI_UNUSABLE_MEMORY.  With such a type the secondary kernel skips over the
      entire memory granule (config option, 16M or 64M) when detecting memory.
      If we are lucky we will just lose some memory, but if we happen to have
      data in the same granule (such as an initramfs image), then this data will
      never get mapped and the kernel bombs out when trying to access it.
      
      So this is an attempt to fix this by changing the EFI memory descriptor
      type into EFI_LOADER_DATA.  This type is the same type used for the kernel
      data and for initramfs.  In the secondary kernel we then handle the ELF
      core header data the same way as we handle the initramfs image.
      
      This patch contains the kernel changes to make this happen.  Pretty
      straightforward, we reserve the area in reserve_memory().  The address for
      the area comes from the kernel command line and the size comes from the
      specialized EFI parsing function vmcore_find_descriptor_size().
      
      The kexec-tools-testing code for this can be found here:
      http://lists.osdl.org/pipermail/fastboot/2007-February/005983.htmlSigned-off-by: default avatarMagnus Damm <magnus@valinux.co.jp>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      cee87af2
    • Horms's avatar
      [IA64] point saved_max_pfn to the max_pfn of the entire system · f4a57099
      Horms authored
      Make saved_max_pfn point to max_pfn of entire system.
      
      Without this patch is so that vmcore is zero length on ia64.  This is
      because saved_max_pfn was wrongly being set to the max_pfn of the crash
      kernel's address space, rather than the max_pfg on the physical memory of
      the machine - the whole purpose of vmcore is to access physical memory that
      is not part of the crash kernel's addresss space.
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarZou Nan hai <nanhai.zou@intel.com>
      Sort-Of-Acked-By: default avatarJay Lan <jlan@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      f4a57099
  3. 12 Feb, 2007 2 commits
  4. 05 Feb, 2007 1 commit
  5. 07 Dec, 2006 2 commits
  6. 02 Aug, 2006 1 commit
  7. 10 Jul, 2006 1 commit
    • Lennert Buytenhek's avatar
      [PATCH] make valid_mmap_phys_addr_range() take a pfn · 06c67bef
      Lennert Buytenhek authored
      Newer ARMs have a 40 bit physical address space, but mapping physical
      memory above 4G needs a special page table format which we (currently?) do
      not use for userspace mappings, so what happens instead is that mapping an
      address >= 4G will happily discard the upper bits and wrap.
      
      There is a valid_mmap_phys_addr_range() arch hook where we could check for
      >= 4G addresses and deny the mapping, but this hook takes an unsigned long
      address:
      
      	static inline int valid_mmap_phys_addr_range(unsigned long addr, size_t size);
      
      And drivers/char/mem.c:mmap_mem() calls it like this:
      
      	static int mmap_mem(struct file * file, struct vm_area_struct * vma)
      	{
      		size_t size = vma->vm_end - vma->vm_start;
      
      		if (!valid_mmap_phys_addr_range(vma->vm_pgoff << PAGE_SHIFT, size))
      
      So that's not much help either.
      
      This patch makes the hook take a pfn instead of a phys address.
      Signed-off-by: default avatarLennert Buytenhek <buytenh@wantstofly.org>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      06c67bef
  8. 30 Jun, 2006 1 commit
  9. 08 May, 2006 1 commit
    • Bjorn Helgaas's avatar
      [IA64] rework memory attribute aliasing · 32e62c63
      Bjorn Helgaas authored
      This closes a couple holes in our attribute aliasing avoidance scheme:
      
        - The current kernel fails mmaps of some /dev/mem MMIO regions because
          they don't appear in the EFI memory map.  This keeps X from working
          on the Intel Tiger box.
      
        - The current kernel allows UC mmap of the 0-1MB region of
          /sys/.../legacy_mem even when the chipset doesn't support UC
          access.  This causes an MCA when starting X on HP rx7620 and rx8620
          boxes in the default configuration.
      
      There's more detail in the Documentation/ia64/aliasing.txt file this
      adds, but the general idea is that if a region might be covered by
      a granule-sized kernel identity mapping, any access via /dev/mem or
      mmap must use the same attribute as the identity mapping.
      
      Otherwise, we fall back to using an attribute that is supported
      according to the EFI memory map, or to using UC if the EFI memory
      map doesn't mention the region.
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      32e62c63
  10. 26 Mar, 2006 2 commits
  11. 07 Feb, 2006 2 commits
  12. 09 Jan, 2006 1 commit
    • Bjorn Helgaas's avatar
      [PATCH] /dev/mem: validate mmap requests · 80851ef2
      Bjorn Helgaas authored
      Add a hook so architectures can validate /dev/mem mmap requests.
      
      This is analogous to validation we already perform in the read/write
      paths.
      
      The identity mapping scheme used on ia64 requires that each 16MB or
      64MB granule be accessed with exactly one attribute (write-back or
      uncacheable).  This avoids "attribute aliasing", which can cause a
      machine check.
      
      Sample problem scenario:
        - Machine supports VGA, so it has uncacheable (UC) MMIO at 640K-768K
        - efi_memmap_init() discards any write-back (WB) memory in the first granule
        - Application (e.g., "hwinfo") mmaps /dev/mem, offset 0
        - hwinfo receives UC mapping (the default, since memmap says "no WB here")
        - Machine check abort (on chipsets that don't support UC access to WB
          memory, e.g., sx1000)
      
      In the scenario above, the only choices are
        - Use WB for hwinfo mmap.  Can't do this because it causes attribute
          aliasing with the UC mapping for the VGA MMIO space.
        - Use UC for hwinfo mmap.  Can't do this because the chipset may not
          support UC for that region.
        - Disallow the hwinfo mmap with -EINVAL.  That's what this patch does.
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      80851ef2
  13. 10 Nov, 2005 1 commit
  14. 19 Sep, 2005 1 commit
  15. 08 Sep, 2005 1 commit
    • Tony Luck's avatar
      [IA64] simplified efi memory map parsing · d8c97d5f
      Tony Luck authored
      New version leaves the original memory map unmodified.
      Also saves any granule trimmings for use by the uncached
      memory allocator.
      
      Inspired by Khalid Aziz (various traces of his patch still
      remain).  Fixes to uncached_build_memmap() and sn2 testing
      by Martin Hicks.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      d8c97d5f
  16. 22 Jun, 2005 1 commit
    • Jes Sorensen's avatar
      [PATCH] ia64 uncached alloc · f14f75b8
      Jes Sorensen authored
      This patch contains the ia64 uncached page allocator and the generic
      allocator (genalloc).  The uncached allocator was formerly part of the SN2
      mspec driver but there are several other users of it so it has been split
      off from the driver.
      
      The generic allocator can be used by device driver to manage special memory
      etc.  The generic allocator is based on the allocator from the sym53c8xx_2
      driver.
      
      Various users on ia64 needs uncached memory.  The SGI SN architecture requires
      it for inter-partition communication between partitions within a large NUMA
      cluster.  The specific user for this is the XPC code.  Another application is
      large MPI style applications which use it for synchronization, on SN this can
      be done using special 'fetchop' operations but it also benefits non SN
      hardware which may use regular uncached memory for this purpose.  Performance
      of doing this through uncached vs cached memory is pretty substantial.  This
      is handled by the mspec driver which I will push out in a seperate patch.
      
      Rather than creating a specific allocator for just uncached memory I came up
      with genalloc which is a generic purpose allocator that can be used by device
      drivers and other subsystems as they please.  For instance to handle onboard
      device memory.  It was derived from the sym53c7xx_2 driver's allocator which
      is also an example of a potential user (I am refraining from modifying sym2
      right now as it seems to have been under fairly heavy development recently).
      
      On ia64 memory has various properties within a granule, ie.  it isn't safe to
      access memory as uncached within the same granule as currently has memory
      accessed in cached mode.  The regular system therefore doesn't utilize memory
      in the lower granules which is mixed in with device PAL code etc.  The
      uncached driver walks the EFI memmap and pulls out the spill uncached pages
      and sticks them into the uncached pool.  Only after these chunks have been
      utilized, will it start converting regular cached memory into uncached memory.
      Hence the reason for the EFI related code additions.
      Signed-off-by: default avatarJes Sorensen <jes@wildopensource.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f14f75b8
  17. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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