- 08 Sep, 2015 1 commit
-
-
David Bigagli authored
-
- 02 Sep, 2015 2 commits
-
-
Morris Jette authored
Previous logic would set the avail_node_bitmap when a node was powered down, even if the initial state was DOWN or DRAINED. This made the node available for allocation to a job, which we don't want until the DOWN or DRAIN state is cleared. bug 1893
-
Morris Jette authored
This reverts commits 7660da9e 5c386455 and f6c5302b
-
- 01 Sep, 2015 4 commits
-
-
Brian Christiansen authored
Bug 1741
-
David Bigagli authored
-
Danny Auble authored
-
David Bigagli authored
-
- 28 Aug, 2015 1 commit
-
-
Morris Jette authored
This problem is reproducible by launching a job then killing the slurmstepd process. Under those conditions, requeue the job if possible (i.e. batch job with requeue option/configuration). This patch also improves the slurmctld logging when this happens. bug 1889
-
- 27 Aug, 2015 2 commits
-
-
Morris Jette authored
Correct RebootProgram logic when executed outside of a maintenance reservation. Previous logic would mark the node up upon response to the reboot RPC (from slurmctld to slurmc) and when the node actually rebooted, flag that as an unexpected reboot. This new logic checks the node's up time to not mark the compute node as being usable until the reboot actually takes place. but 1866
-
Danny Auble authored
association manager.
-
- 26 Aug, 2015 3 commits
-
-
Morris Jette authored
Prevent job array task ID from being reported as NO_VAL if last task in the array gets requeued. The problem is that when that task starts, the task bitmap entry for it stays set, but the task counter gets decremented. If that job then gets requeued, under some conditions a failure to schedule it results in the array_task_id in the job record getting set to NO_VAL. Then when building the job info to report for squeue/scontrol, the string showing the pending task ID's is not rebuilt due to that counter being zero. All indications are that the job runs fine, only the information reported to squeue/scontrol is wrong. bug 1790
-
Danny Auble authored
-
Danny Auble authored
-
- 25 Aug, 2015 2 commits
-
-
Brian Christiansen authored
Bug 1873
-
Danny Auble authored
or binary.
-
- 21 Aug, 2015 5 commits
-
-
Brian Christiansen authored
Bug 1831
-
Brian Christiansen authored
Bug 1869
-
David Bigagli authored
-
Morris Jette authored
Fix gang scheduling/preemption issue that could cancel job at startup. I have not been able to reproduce the reported problem, but this should prevent the reported problem. bug 1880
-
Morris Jette authored
-
- 20 Aug, 2015 1 commit
-
-
David Bigagli authored
This reverts commit 406cb529. Conflicts: NEWS This works ok up until 1048576M then it will make the divisor 1048576 and when it goes to divide it only does it once instead of 2 times returning 1G instead of 1T. We have decided to wait until 15.08 for a no convert option to be added.
-
- 14 Aug, 2015 2 commits
-
-
Daniel Ahlin authored
We are using a non-default AuthInfo configuration and based on log-messages we see I believe this is not properly handled in certain parts of the code. Typical log message: Aug 12 17:06:15 t02n20 slurmd[27001]: error: Munge encode failed: Failed to access "/var/run/munge/munge.socket.2": No such file or directory Aug 12 17:06:15 t02n20 slurmd[27001]: error: Creating authentication credential: Socket communication error Aug 12 17:06:15 t02n20 slurmd[27001]: error: stepd_connect to 3165.0 failed: Protocol authentication error Aug 12 17:06:15 t02n20 slurmd[27001]: error: If munged is up, restart with --num-threads=10
-
Morris Jette authored
Unfortunately the reservation's core_bitmap is a global bitmap and the nodes in the system may have changed in terms of their node count or nodes have been added or removed. Make best effort to rebuild the reservation's core_bitmap on the limited information currently available. The specific cores might change, but this logic at least leaves their count constant and uses the same nodes bug 1850
-
- 11 Aug, 2015 2 commits
-
-
David Bigagli authored
-
Brian Christiansen authored
Bug 1770
-
- 06 Aug, 2015 1 commit
-
-
Danny Auble authored
thing (-F exclusive) instead of -F share. bug 1849
-
- 04 Aug, 2015 2 commits
-
-
David Bigagli authored
-
Morris Jette authored
Fix scheduling anomaly with job arrays submitted to multiple partitions, jobs could be started out of priority order. bug 1892
-
- 03 Aug, 2015 2 commits
-
-
Danny Auble authored
portion of a job array is pending after it's initial start in the database it could create another row for the remain array instead of using the already existing row. bug 1840
-
Danny Auble authored
-
- 31 Jul, 2015 1 commit
-
-
David Bigagli authored
-
- 28 Jul, 2015 4 commits
-
-
Brian Christiansen authored
Fix segfault in Bluegene setups where RebootQOSList is defined in bluegene.conf and accounting is not setup.
-
Nathan Yee authored
Read in correct number of nodes from SLURM_HOSTFILE when specifying nodes and --distribution=arbitrary. Bug 1808
-
Brian Christiansen authored
From eee63695
-
Brian Christiansen authored
Bug 1810
-
- 27 Jul, 2015 1 commit
-
-
Morris Jette authored
If node definitions in slurm.conf are spread across multiple lines and topology/tree is configured, then sub-optimal node selection can occur. bug 1645
-
- 22 Jul, 2015 2 commits
-
-
Nicolas Joly authored
Previously only batch job completions were being captured. bug 1820
-
David Bigagli authored
-
- 21 Jul, 2015 2 commits
-
-
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
-
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.
-