"ZPOTRF failed!" occurs before first step in PBE+U calc when ISIF=2, but is ok when ISIF=1

[dhfphysics]

I use an automatic 2x2x2 Gamma k-point mesh with the INCAR below. System has 127 atoms (8 primitive enargite structure cells of Cu3PSe4, with one Cu atom missing) and PBE paws.
I'm using VASP 5.2.8 (compiled with ifort 9.1 with mkl 9.1), parallel (openMPI) on 8 cores on one machine.

If I run with ISIF=2, I get:
FFT: planning ...( 1 )
reading WAVECAR
LAPACK: Routine ZPOTRF failed! 413
LAPACK: Routine ZPOTRF failed! 413
LAPACK: Routine ZPOTRF failed! 413 ....

but things are fine if I set ISIF=1 !
Any ideas?
-David


SYSTEM = Cu3PSe4 PBE+U6
LWAVE=.TRUE.
LCHARG=.TRUE.
LVHAR=.TRUE.
LMAXMIX=4
ISTART=0
MAXMEM=2048

LDAU = .TRUE.
LDAUTYPE = 2
LDAUL = -1 2 -1
LDAUU = 0 6. 0
LDAUJ = 0 0 0
#LDAUPRINT = 2

! algorithm
ALGO = Normal
NSIM = 1
#NPAR = 1
LREAL = Auto
LASPH = .TRUE.

! basis set 1.1 * ENMAX of sulfur POTCAR (we will occasionally include a S)
ENCUT = 310
PREC = normal ! normal,accurate

! ksi
ISMEAR = -5 ! -5,-1
SIGMA = 0.03

! electronic relaxation
EDIFF = 1e-6
NELM = 100

! ionic relaxation
EDIFFG = 5e-5
NSW = 0 ! NSW=80,0, NUMBER OF IONIC STEPS
IBRION = 2 ! IBRION=1,-1
ISIF = 2 ! ISIF=2,4,3

NEDOS=2001
LORBIT=10

[admin]

as this error shows up in the first electronic step after having read an existing WAVECAR, I suppose there is some inconsistency in the parameters of the run writing WAVECAR and the one reading WAVECAR. (i.e. the charge density of the new run constructed form WAVECAR is not appropriate for the current run)
the parameters that should be the same are
cell volume, cell shape, #of PW coefficients, #of bands, k-points...
However, ISIF=1 AND 2 should not make a difference here
please check the respective parameters (Bravais Matrix, NGX NGY NGZ, NBANDS,.... ) of the 2 runs if this may have caused the error.

[dhfphysics]

It wasn't reading any WAVECAR however (ISTART was set to 0, and the program prints "reading WAVECAR" *before* checking ISTART and choosing whether to read or not read the WAVECAR).
I have seen this error and the "Matrix not Hermitian" error many times and they are sometimes fixable by changes to any of a large number of parameters (changing ALGO from Fast to Normal, changing ISIF from 4 to 1, changing NPAR = 1 to not having this line, changing from mpi to serial with threads (this is the most successful fix for the "not hermitian error". Because so many different things cause or fix this, I now am hypothesizing that it is a ultimately a resource (memory-related) error.