1. 19 May, 2003 2 commits
  2. 16 May, 2003 2 commits
  3. 15 May, 2003 6 commits
  4. 14 May, 2003 11 commits
  5. 13 May, 2003 4 commits
  6. 12 May, 2003 5 commits
  7. 09 May, 2003 3 commits
  8. 08 May, 2003 1 commit
  9. 06 May, 2003 6 commits
    • Arun Sharma's avatar
      [PATCH] ia64: fix sys32_select() · 4c5ece64
      Arun Sharma authored
      4c5ece64
    • David Mosberger's avatar
      mca.c: · 0e2134fe
      David Mosberger authored
        (show_min_state): Fix typo r11 -> r12.
      0e2134fe
    • David Mosberger's avatar
      Merge tiger.hpl.hp.com:/data1/bk/vanilla/linux-2.5 · 20f6d716
      David Mosberger authored
      into tiger.hpl.hp.com:/data1/bk/lia64/to-linus-2.5
      20f6d716
    • David Mosberger's avatar
    • Ernie Petrides's avatar
      [PATCH] ia64: fixes for semtimedop() ia32-compat handling · 6a1a1239
      Ernie Petrides authored
      Here are two fixes for the ia32-compatibility mode handling
      for the new semtimedop() system call for the ia64 architecture.
      
      The first problem was that treatment of user-mode calls to semtimedop()
      with a NULL 4th (struct timespec *) parameter was inconsistent with the
      behavior of the same executable on i386 and also with a natively compiled
      ia64 binary.  A NULL 4th arg to semtimedop() should result in no timeout
      being used (like a straight semop() call) rather than in an EFAULT error.
      
      The second problem was that a legitimate semtimedop() with a timeout was
      also resulting in an EFAULT because the fetch of the internal timespec
      strucure by sys_semtimedop() from semtimedop32()'s kernel stack was
      treated as an invalid user-data reference.  This requires temporarily
      switching the addressing limit with set_fs(), further requiring that
      appropriate parameter checking by performed prior to the switch.
      
      The const qualifier was removed from the (struct compat_timespec *) arg
      to semtimedop32() so that the call to get_compat_timespec() wouldn't
      generate a compilation warning.
      6a1a1239
    • Bjorn Helgaas's avatar
      [PATCH] ia64: vendor-specific ACPI resource cleanup · 7c19bf64
      Bjorn Helgaas authored
      This is to
      
        - handle _CRS with multiple vendor-specific resources
        - use acpi_walk_resources() instead of doing it by hand
        - make lookup of vendor resource by GUID generic
        - cleanup now-unused helper functions
      
      (This depends on the previous IO port space patches, because
      they removed the last of acpi_get_addr_space()).
      
      My hope is that acpi_vendor_resource_match() and
      acpi_find_vendor_resource() can someday move into ACPI,
      but that probably depends on getting the idea of labelling
      vendor resources with a GUID into the spec.  HP does this
      and I think is working on putting it in the spec.
      7c19bf64