2017-07-24 18:25, Ken Merry wrote:
It is possible that the change I MFCed today (r321207 in head, r321415
in stable/11) is related, but Mark will have to boot his machine with
the fix to see if it makes any difference.
What happened in my case on one particular machine (not on most
machines in our lab running the same code) was that mps_wait_command()
/ mpr_wait_command() would not wait the full 60 seconds for a write to
the DPM table (Driver Persistent Mapping) table in the controller.
So, it reported that there was a timeout.
[...]
Eliminating bogus timeouts will eliminate most all of the sources of
those panics anyway.
Took r321415 from stable/11 and applied it to 11.1-RC3 - and it makes
no difference to booting: still hangs attempting to attach da0,
with a spinning CPU (according to fan speed).
Booting in safe mode, or with EARLY_AP_STARTUP disabled avoids the
problem.
There is a secondary bug that is still in the mps(4) / mpr(4) drivers
when a timeout does happen — the error recovery code in the
wait_command() routine reinitializes the controller, which clears out
all the commands. When the wait_command() routine returns, the
command passed in has been freed, but the caller doesn’t know that.
So the caller (it happens in a number of places) dereferences a
pointer to freed memory and the kernel panics.
I’m planning to fix that bug, too, if slm@ doesn’t get to it first,
I’ve just had other bugs to fix first.
No panics in my case, just hangs.
Mark
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
