On 12/14/17 12:20, Mark Kettenis wrote:
Date: Thu, 14 Dec 2017 11:49:18 +0100
From: Martin Pieuchot <m...@openbsd.org>
On 14/12/17(Thu) 11:30, Mark Kettenis wrote:
X-Originating-IP: 88.153.7.170
Date: Thu, 14 Dec 2017 10:30:21 +0100
From: Martin Pieuchot <m...@openbsd.org>
On 13/12/17(Wed) 19:09, Florian Riehm wrote:
Hi,
This patch follows bluhm's attempt for a ddb command 'boot reset'.
My first attempt was not architecture aware.
Tested on i386 by bluhm@ and on amd64 by me.
I don't understand why we need to add "boot reset"? To not fix ddb(4)
and keep a broken "boot reboot"? If we cannot fix our own code...
Funny you say that given the discussion about if_downall() on icb ;).
There's nothing funny. There's people not reporting bugs with traceback
to bugs@ and coming around with workaround like that.
IIRC "boot reset" is all about avoiding the if_downall() call. And we
really don't want to skip if_downall() in the "boot reboot". We added
that call since not stopping the DMA engines of the network cards had
some very interesting effects when the machine rebooted...
If if_downall() is a problem, then please show me a traceback where
that's the case. I'd be delighted to fix it :)
True. Given the DMA issue, "boot reset" would be a rather dangerous
command.
If the command could lead to DMA issues, I agree that we should not
introduce it.
I also agree that we should try to make boot reboot as reliable as possible
and it works fine in most situations.
Anyway I have seen it hanging in some cases. This is a problem for me,
since I don't have physical access to my machines all the time. In such
cases I preferred the cpu_reset hammer. I have never noticed any side effects
like DMA issues, so I thought it would be a good idea, to provide that way
as a regular ddb feature. But I am also fine without the command.
