Logic was assuming the reservation had a node bitmap which was
  being used to check for overlapping jobs. If there is no node
  bitmap (e.g. a licenses only reservation), an abort would result.

Bug 1739

Bug 1743

Bug 1743

Prevent double free.

cpufreq variables weren't being intialized to NO_VAL when using task/none
plugin. This caused the conditions in cpur_freq_reset to not stop
test_cpu_owner_lock from being called.

Conflicts:
	src/common/cpu_frequency.c

Conflicts:
	src/common/cpu_frequency.c

Bug 1733

In your node_mgr fix to keep rebooted nodes down (commit 9cd15dfe), you
forgot to consider the case of nodes that are powered up but are responding after
ResumeTimeout seconds (the maximum time permitted). Such nodes are
marked DOWN (because they didn't respond within ResumeTimeout seconds) than
should become silently available when ReturnToService=1 (as stated in the slurm.conf manual)

With your modification when such nodes are finally responding, they are seen as
rebooted nodes and remain in the DOWN state (with the new reason: Node
unexpectedly rebooted) even when ReturnToService=1 !

Correction of commit 3c2b46af

It was always failing when a node list was supplied on job submission

In your node_mgr fix to keep rebooted nodes down (commit 9cd15dfe), you
forgot to consider the case of nodes that are powered up but are responding after
ResumeTimeout seconds (the maximum time permitted). Such nodes are
marked DOWN (because they didn't respond within ResumeTimeout seconds) than
should become silently available when ReturnToService=1 (as stated in the slurm.conf manual)

With your modification when such nodes are finally responding, they are seen as
rebooted nodes and remain in the DOWN state (with the new reason: Node
unexpectedly rebooted) even when ReturnToService=1 !

My patch to obtain the correct behaviour:

Conflicts:
	doc/man/man5/slurm.conf.5
	src/plugins/select/cons_res/job_test.c

Equivalent fix as e1a00772
for select/serial rather than select/cons_res

1. I submit a first job that uses 1 GPU:
$ srun --gres gpu:1 --pty bash
$ echo $CUDA_VISIBLE_DEVICES
0

2. while the first one is still running, a 2-GPU job asking for 1 task per node
waits (and I don't really understand why):
$ srun --ntasks-per-node=1 --gres=gpu:2 --pty bash
srun: job 2390816 queued and waiting for resources

3. whereas a 2-GPU job requesting 1 core per socket (so just 1 socket) actually
gets GPUs allocated from two different sockets!
$ srun -n 1  --cores-per-socket=1 --gres=gpu:2 -p testk --pty bash
$ echo $CUDA_VISIBLE_DEVICES
1,2

With this change #2 works the same way as #3.
bug 1725

Bug 1572

Bug 1572

option.

Modify test to work if "." is not in search path
Fix error message, change "sbatch" to "salloc"

option.