mps(4) blocks panic-reboot

[Harry Schmalzbauer]

Bezüglich Stephen Mcconnell's Nachricht vom 01.06.2017 19:36 (localtime):
> Can you try the attached patch and let me know how it goes? I didn't test
> it, but since you know how, it might be easier this way. This was diff'd
> from the latest mps files in stable/11, which I recently updated (today).

Your diff is doing very well on r319447:

Fatal trap 12: page fault while in kernel mode
…
Uptime: 1m26s
Dumping 1608 out of 15734
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
Dump complete
mps0: Sending StopUnit: path (xpt0:mps0:0:2:ffffffff):  handle 12
mps0: Completing stop unit for (xpt0:mps0:0:2:ffffffff):
mps0: Sending StopUnit: path (xpt0:mps0:0:3:ffffffff):  handle 11
mps0: Completing stop unit for (xpt0:mps0:0:3:ffffffff):
mps0: Sending StopUnit: path (xpt0:mps0:0:4:ffffffff):  handle 10
mps0: Completing stop unit for (xpt0:mps0:0:4:ffffffff):
mps0: Sending StopUnit: path (xpt0:mps0:0:5:ffffffff):  handle 9
mps0: Completing stop unit for (xpt0:mps0:0:5:ffffffff):
mps0: Sending StopUnit: path (xpt0:mps0:0:6:ffffffff):  handle 13
mps0: Completing stop unit for (xpt0:mps0:0:6:ffffffff):

And, there followed a immediate reset :-)

Thank you very much! Fellows who have these great mp[sr] silicon in use
but no ipmi-watchdog will get better slepp from now on ;-)

-harry