1. 15 Jan, 2003 11 commits
    • Martin J. Bligh's avatar
      [PATCH] Add ACPI hook, rename raw_phys_apicid to bios_cpu_apicid · 3bbeca78
      Martin J. Bligh authored
      Patch from James Cleverdon & John Stultz
      
      This adds machine a type detection hook to the acpi code, and renames
      raw_phys_apicid to bios_cpu_apicid (it's an array of apicid's to boot,
      indexed by the bios' cpu numbering), and I other large machines will
      need to use it later ... not necessarily using physical interrupts.
      3bbeca78
    • Martin J. Bligh's avatar
      [PATCH] Fix interrupt dest mode / delivery mode confusion · fbf7fcc5
      Martin J. Bligh authored
      Patch from James Cleverdon & John Stultz
      
      Currently the naming for the IO-APIC fields is very confused, we assign
      dest_LowestPrio to delivery_mode, and INT_DELIVERY_MODE to dest_mode.
      The values are correct, but the naming is wrong - this patch corrects
      that confusion. It also moves the definitions of those settings into
      subarch, where they belong (we have to use fixed delivery mode for Summit
      due to what seems to be an Intel IO-APIC bug with P4 clustered mode).
      fbf7fcc5
    • Christoph Hellwig's avatar
      d1ae0ede
    • Christoph Hellwig's avatar
      32e50ad9
    • Christoph Hellwig's avatar
      3ad42de2
    • Trond Myklebust's avatar
      [PATCH] Fix NFS root mount handling · eec91b48
      Trond Myklebust authored
      eec91b48
    • Trond Myklebust's avatar
      [PATCH] Fix RPC client warning in 2.5.58... · 8dffd730
      Trond Myklebust authored
      The warning
      
      	/lockd/clntXxXxXxXx RPC: Couldn't create pipefs entry
      
      is due to the lockd process starting RPC clients as an unprivileged
      user, causing path_walk() to fail.  The following patch fixes it.
      8dffd730
    • Gabriel Paubert's avatar
      [PATCH] Cleanup of the lcall7/lcall27 entry path. · b49b7f62
      Gabriel Paubert authored
      I have more carefully tested the proposed removal of the NT flag
      clearing on lcall entry.
      
      The question I wanted to answer is: is it necessary to clear NT in the
      sysenter entry path as implemented for lcall7/lcall27 or is it possible
      to remove the flag manipulation from do_lcall?
      
      Doing it only for one and not the other looks wrong since several return
      paths are shared, especially the ones which end up in iret, the only
      instruction which is affected by the NT flag.
      
      The conclusion is that 2.5 is NT safe (had to dig out an old P5-133 which
      I could crash without fear of data loss, so I have only tested on 1
      machine). The reason this cleanup works is that now (since Jan 5th) flags
      are saved and restored in switch_to() to keep IOPL private to a process
      even when using sysenter/sysexit.
      
      The side effect of that patch is that NT becomes also process-private
      instead of infecting all processes and triggering a killfest of all user
      mode processes, including init (AFAICT kernel threads survived, but I
      did not have any debug tools enabled in the kernel).
      
      The only addition to the preceding version is that interrupts are
      reenabled in the iret fixup path because it seems that do_exit() might
      otherwise spend quite some time with interrupts disabled.
      b49b7f62
    • Christoph Hellwig's avatar
      [PATCH] more procfs bits for !CONFIG_MMU · 36ece8f9
      Christoph Hellwig authored
      New version with all ifdef CONFIG_MMU gone from procfs.
      
      Instead, the conditional code is in either task_mmu.c/task_nommu.c, and
      the Makefile will select the proper file for inclusion depending on
      CONFIG_MMU.
      36ece8f9
    • Dave Jones's avatar
      7a8f29d2
    • Dave Jones's avatar
      Merge tetrachloride.(none):/mnt/stuff/kernel/2.5/bk-linus · 11061ebf
      Dave Jones authored
      into tetrachloride.(none):/mnt/stuff/kernel/2.5/agpgart
      11061ebf
  2. 14 Jan, 2003 17 commits
  3. 15 Jan, 2003 1 commit
    • Russell King's avatar
      [ARM] Fix CPUFREQ initialisation oops · 6eafb008
      Russell King authored
      The CPUFREQ initialisation now registers an interface with the device
      model, and thus needs to initialise after postcore.  We use the
      arch level for this.  This does, however, impose the restriction
      that cpufreq may not be available for other architecture
      initialisated code.
      6eafb008
  4. 14 Jan, 2003 11 commits