This problem would effect systems in which specific GRES are associated
with specific CPUs.
One possible result is the CPUs identified as usable could be inappropriate
and job would be held when trying to layout out the tasks on CPUs (all
done as part of the job allocation process).
The other problem is that if multiple GRES are linked to specific CPUs,
there was a CPU bitmap OR which should have been an AND, resulting in
some CPUs being identified as usable, but not available to all GRES.

options in srun, and push that logic to salloc and sbatch.

Bug 201

and timeout in the runjob_mux trying to send in this situation.

Bug 223

Jobs are not backfilled due to the fact that backfill does not finish the complete backlog of jobs in the queue before it's interrupted and starts all over again. We sometimes have lots of jobs in the queue of various sizes and users and even with idle nodes short job will not start because of this.  I have made a patch for backfill with a configuration option (bf_continue) to let backfill continue.

The original reservation data structure is deleted and it's backup
added to the reservation list, but jobs can retain a pointer to the
original (now invalid) reservation data structure.
Bug 250

energy data.

Without this fix, jobs that should be initiated by the backfill
scheduler based upon the preemption of other jobs will not be
started.

cnode does not have a job running on it do not resume the block.

Select/cons_res - If the job request specified --ntasks-per-socket and the
allocation using is cores, then pack the tasks onto the sockets up to the
specified value. Previously it would ignore the ntasks-per-socket
parameter and distribute tasks across sockets

--enable-debug.

Counts would previously go negative as jobs terminate and decrement from
a base value of zero

to EINTR when something wrong happened between the open call and
its return. By ensuring that Slurm retries on such errors, we can
better tolerate Network file systems errors at launch time.

(>5000) and using the SchedulerParameters option bf_max_job_user.

NEWS note for last few commits

midplane.

Handle situation where a receiving/forwarding host can't unpack the header
of the sender (not compatible version).

The logic is only an example and not meant for actual use.

built.

(within the existing select_nodeinfo field of the node_info_t data structure).
Added Allocated Memory to node information displayed by sview and scontrol commands.
bug 229

This makes the configuration parameter names consistent within
a partition and system-wide

Added new field to partition_info data structure
Break up some long lines and minor format changes
Move some definitions and statements into alphabetic order

1. Removed the job_submit and job_modify functions from the plugin, they are not required for the "slurmctld" plugin type
2. Renamed the new parameter from "JobSubmitDynAllocPort" to "DynAllocPort" and renamed the variable (You need to change this in your slurm.conf file)
3. Added logic so you can see the DynAllocPort value using "scontrol show config" or "sview"
4. I made some minor formatting changes, mostly for lines that were too long
5. Added #ifdef to the msg.h header file
6. Changed the #ifdef variables in the header files to start with "DYNALLOC_", perhaps not needed, but it should safer, especiallly with some common names like "INFO_H"
7. I re-wrote much of info.c. There was no need to get a copy of the node information and process the copy. We can just work directly with the data structures.

These provide support for MapReduce+

of the current day.

the user commands.

Make core reservation test a bit more flexible in terms of node names

Fix arithmetic for core reservation count return for old RPCs
Update NEWS and RELEASE_NOTES

Remove trailing spaces from recent scontrol man page changes

the allocation to 1 instead of 0 which prevents the allocation to happen.

Old logic uses some vestigial power management logic that no longer
applies. It creates a job allocation, but the job step blocks
indefinitely.