1. 27 Jul, 2015 7 commits
  2. 24 Jul, 2015 4 commits
  3. 23 Jul, 2015 3 commits
  4. 22 Jul, 2015 10 commits
  5. 21 Jul, 2015 8 commits
    • Morris Jette's avatar
      Merge branch 'slurm-14.11' · 11c5684f
      Morris Jette authored
      11c5684f
    • Morris Jette's avatar
      Fix typo on web page · 49560d80
      Morris Jette authored
      49560d80
    • Chandler Wilkerson's avatar
      fix incorrect reading of cpuinfo on POWER systems · 962dea86
      Chandler Wilkerson authored
      This patch provides a rewrite of how /proc/cpuinfo is parsed in common_jag.c, as the original code made the incorrect assumption that cpuinfo follows a sane format across architectures ;-)
      
      The motivation for this patch is that the original code was producing stack smashing on a POWER7 running RHEL6.4 Red Hat adds -fstack-protector along with a lot of other protective CFLAGS when building RPMs. The code ran okay with -fno-stack-protector, but that is not the best work-around.
      
      So, the relevant /proc/cpuinfo line on an Intel (Xeon X5675) system looks like:
      
      cpu MHz                : 3066.915
      
      Whereas the relevant line in a POWER7 system is
      
      clock                : 3550.000000MHz
      
      My patch replaces the assumption that the relevant number starts 11 characters into the string with another assumption: That the relevant number starts two characters after a colon in a string that matches (M|G)Hz.
      
      All in all, the function has a few more calls, which may be a performance issue if it has to be called multiple times, but since the section I edited only gets evaluated if we don't know the cpu frequency, getting it right will actually result in fewer string operations and unnecessary opens of /proc/cpuinfo for systems likewise affected.
      
      Finally, I also read the actual value into a double and multiply it up to the size indicated by the suffix, so we end up with KHz? It was unclear what the original code intended, since it matched both MHz and GHz, replaced the decimal point with a zero, and read the result as an int.
      
      --
      Chandler Wilkerson
      Center for Research Computing
      Rice University
      962dea86
    • Danny Auble's avatar
      Revert "ALPS - Remove sanity code to work like it did in 2.5. This is an addition" · 6ab26aa6
      Danny Auble authored
      This reverts commit 2c95e2d2.
      
      Conflicts:
      	src/plugins/select/alps/basil_interface.c
      
      This is related to bug 1822.  It isn't clear why the code was taken out in
      this commit in the first place and based off of commit 2e2de6a4 (which is
      the reason for the conflict) we tried unsuccessfully to put it back.
      
      It appears the only difference here is the addition of
      always setting mppnppn = 1 instead of always to
      job_ptr->details->ntasks_per_node when no ntasks is set.
      
      This appears to only be an issue with salloc or sbatch as ntasks
      is always set for srun.
      6ab26aa6
    • David Gloe's avatar
      Patch that adds new script and templates · 1a0ec9a3
      David Gloe authored
      I've attached a patch to add a new script and templates that create slurm.conf and gres.conf on a Cray SMW.
      
      The script parses the output of xthwinv, combines nodes with the same hardware, and writes the output to slurm.conf. It also uses NodeName in gres.conf to allow having the same gres.conf file on all nodes.
      
      I removed the settings in slurm.conf that we had commented out or set to the default.
      1a0ec9a3
    • Morris Jette's avatar
      Merge branch 'slurm-14.11' · 594e043d
      Morris Jette authored
      594e043d
    • Morris Jette's avatar
      Clarify GraceTime configuration · afae90b1
      Morris Jette authored
      afae90b1
    • david's avatar
      Enhance the error message. · 2c937879
      david authored
      2c937879
  6. 20 Jul, 2015 7 commits
  7. 18 Jul, 2015 1 commit