Apologies if this is an implementation or model issue rather than a code issue... There appears to be a bug (?) in stats::glm where start/mustart/etastart values are not passed to the fitting procedure if an offset is provided. if (length(offset) && attr(mt, "intercept") > 0L) { fit2 <- eval(call(if (is.function(method)) "method" else method, x = X[, "(Intercept)", drop = FALSE], y = Y, weights = weights, offset = offset, family = family, control = control, intercept = TRUE)) if (!fit2$converged) warning("fitting to calculate the null deviance did not converge -- increase 'maxit'?") fit$null.deviance <- fit2$deviance } In the deviance recalculation of glm the potentially provided start/mustart/etastart values are not passed into the call to glm.fit. This leads to glm.fit failing with if (!is.finite(dev)) { if (is.null(coefold)) stop("no valid set of coefficients has been found: please supply starting values", call. = FALSE) In my test case, dev is calculated as NaN (many values of dev.resids(y, mu, weights) are NaN. This is due to (log(ifelse(y == 0, 1, y)/mu) since some calculated values of mu are negative (hence the log fails). I can't seem to trace back where etastart and mustart flow through to eta and mu and how they interact with offset, but given the next bit, it seems this is the cause... Ben Bolker (http://stackoverflow.com/a/8221108/4168169) provided a patch that seems to remedy this by adding start = start[1], etastart = etastart[1], mustart = mustart[1], into the call to method (default: glm.fit) and in testing this seems to work well; the deviance remains finite and the solution is reached. Is this a correct addition to the code? i.e. is the calculation of mu for the purposes of re-calculating the deviance robust? Kind regards, - Jonathan Carroll.