Re: Add reset option to boot command of ddb(4)

On 14/12/17(Thu) 17:19, Artturi Alm wrote: > On Thu, Dec 14, 2017 at 02:05:36PM +0100, Martin Pieuchot wrote: > > On 14/12/17(Thu) 13:37, Florian Riehm wrote: > > > [...] > > > If the command could lead to DMA issues, I agree that we should not > > > introduce it. > > > > The problem is not only

Re: Add reset option to boot command of ddb(4)

On Thu, Dec 14, 2017 at 02:05:36PM +0100, Martin Pieuchot wrote: > On 14/12/17(Thu) 13:37, Florian Riehm wrote: > > [...] > > If the command could lead to DMA issues, I agree that we should not > > introduce it. > > The problem is not only DMA issues. The problem is that ddb(4) will > never get

Re: Add reset option to boot command of ddb(4)

On 14/12/17(Thu) 13:37, Florian Riehm wrote: > [...] > If the command could lead to DMA issues, I agree that we should not > introduce it. The problem is not only DMA issues. The problem is that ddb(4) will never get fixed. If we give people a 'reset' button then how long until the core dump

Re: Add reset option to boot command of ddb(4)

On 12/14/17 12:20, Mark Kettenis wrote: Date: Thu, 14 Dec 2017 11:49:18 +0100 From: Martin Pieuchot 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 On 13/12/17(Wed)

Re: Add reset option to boot command of ddb(4)

> Date: Thu, 14 Dec 2017 11:49:18 +0100 > From: Martin Pieuchot > > 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 > > > > > > On 13/12/17(Wed) 19:09,

Re: Add reset option to boot command of ddb(4)

On 2017 Dec 14 (Thu) at 11:49:18 +0100 (+0100), Martin Pieuchot wrote: :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 :> > :> > On 13/12/17(Wed) 19:09, Florian Riehm wrote:

Re: Add reset option to boot command of ddb(4)

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 > > > > On 13/12/17(Wed) 19:09, Florian Riehm wrote: > > > Hi, > > > > > > This patch follows bluhm's attempt for a ddb command

Re: Add reset option to boot command of ddb(4)

> X-Originating-IP: 88.153.7.170 > Date: Thu, 14 Dec 2017 10:30:21 +0100 > From: Martin Pieuchot > > 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.

Re: Add reset option to boot command of ddb(4)

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

Re: Add reset option to boot command of ddb(4)

I will prepare a new diff including the other architecures and try to find people who can test it. I have had such a diff already but then I decided to remove the untested parts because I didn't want to submit untested code. friehm On 12/13/17 21:59, Theo de Raadt wrote: As it is, this diff

Re: Add reset option to boot command of ddb(4)

On Wed, Dec 13, 2017 at 06:09:14PM GMT, 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. > > ok? > > friehm > > Index: share/man/man4/ddb.4 >

Re: Add reset option to boot command of ddb(4)

As it is, this diff will not go in. Your 2nd attempt is not architecture aware either. There are more than 2 architectures. If you add a MI feature, you must attempt to add support for it to all the MD versions. And the process of mailing it out to the community gives people an opportunity to

Re: Add reset option to boot command of ddb(4)

This is a better plan. All the architectures can adapt to this, even those that have a tricky ROM-related dance. > On Thu, Oct 26, 2017 at 10:32:42PM +1100, Jonathan Gray wrote: > > What specifically? Skip if_downall() if rebooting from ddb? > > That could perhaps even be done for RB_NOSYNC. >

Re: Add reset option to boot command of ddb(4)

On Thu, Oct 26, 2017 at 10:32:42PM +1100, Jonathan Gray wrote: > What specifically? Skip if_downall() if rebooting from ddb? > That could perhaps even be done for RB_NOSYNC. I thought of someting like a big hammer. Skip everything except the final call in boot() that causes the machine to

Re: Add reset option to boot command of ddb(4)

On Thu, Oct 26, 2017 at 01:12:53PM +0200, Alexander Bluhm wrote: > On Thu, Oct 26, 2017 at 08:08:35PM +1100, Jonathan Gray wrote: > > No, cpu_reset() is MD this will break ddb on all non x86 archs besides > > landisk. > > Would it make sense to implement a boot(RB_RESET) that works > everywhere?

Re: Add reset option to boot command of ddb(4)

On Thu, Oct 26, 2017 at 08:08:35PM +1100, Jonathan Gray wrote: > No, cpu_reset() is MD this will break ddb on all non x86 archs besides > landisk. Would it make sense to implement a boot(RB_RESET) that works everywhere? Problem is that when adding MP locks to the kernel, ddb boot reboot does not

Re: Add reset option to boot command of ddb(4)

On 2017/10/26 10:42, Florian Riehm wrote: > Hi, > > Sometimes I see systems hanging in ddb(4) after panic(9) and the "boot reboot" > command doesn't work anymore, i.e. of filesystem or locking issues. > Bluhm@ suggested to me to use "call cpu_reset" in such situations. > > I would like to

Re: Add reset option to boot command of ddb(4)

On Thu, Oct 26, 2017 at 10:42:17AM +0200, Florian Riehm wrote: > Hi, > > Sometimes I see systems hanging in ddb(4) after panic(9) and the "boot reboot" > command doesn't work anymore, i.e. of filesystem or locking issues. > Bluhm@ suggested to me to use "call cpu_reset" in such situations. > > I