Re: (RPi) db> reboot -> cpu_reset failed

From: Mark Millard <marklmi_at_yahoo.com>
Date: Mon, 09 Jan 2023 16:21:09 UTC
On Jan 9, 2023, at 00:15, Klaus Küchemann <maciphone2@googlemail.com> wrote:

> `ve tested D37981 on a Pi4b, 
> sorry but it had no effect,
> not on the booted machine and not when intentionally provoked crashing in early boot up( no changed behavior in reset) .
> 
> I never see :
> <<debug.kdb.enter: 0KDB: enter: sysctl debug.kdb.enter>>
> (except, of course when entering directly by : sysctl debug.kdb.enter=1)

I think you misinterpreted:

QUOTE
We get some new console output with this change:
debug.kdb.enter: 0KDB: enter: sysctl debug.kdb.enter
[ thread pid 812 tid 100118 ]
Stopped at kdb_trap+0x448: sd zero,0(s1)
db> reset
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Uptime: 1m51s
END QUOTE

I expect the new output text was only the text after the "reset"
command:

QUOTE
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Uptime: 1m51s
END QUOTE

I also expect that the text:

QUOTE
debug.kdb.enter: 0KDB: enter: sysctl debug.kdb.enter
END QUOTE

was just from how db> was entered to make the example and
other ways of entering db> that historically did not put
out such a line still would not put out such a line.


> From the booted system( so you see that the new tunable is compiled in) :
> —
> root@:~ # sysctl debug.ddb.full_reboot=1
> debug.ddb.full_reboot: 1 -> 1
> root@:~ # root@:~ # sysctl debug.kdb.panic=1
> ….
> KDB: enter: panic
> [ thread pid 1056 tid 100128 ]
> Stopped at      kdb_enter+0x44: undefined       f900827f
> db> 
> --
> 
> root@:~ # sysctl debug.ddb.full_reboot=0
> debug.ddb.full_reboot: 1 -> 0
> root@:~ # sysctl debug.kdb.panic=1
> ...
> KDB: enter: panic
> [ thread pid 1057 tid 100092 ]
> Stopped at      kdb_enter+0x44: undefined       f900827f
> db> 
> —






> Am 08.01.2023 um 19:32 schrieb Mitchell Horne <mhorne@freebsd.org>:
> 
> …….
> 
> The reason for the difference in behaviour here is that the ddb reset command doesn't execute the full list of registered shutdown handlers, it just calls cpu_reset() directly. For whatever reason your combination of RPI hw+fw doesn't support the PSCI shutdown interface, so cpu_reset() fails. I am guessing that it is the bcm2835_watchdog driver that handles the normal reboot.
> 
> I think it should be just fine to execute such handlers from ddb reset, so you can try my patch: https://reviews.freebsd.org/D37981
> 
> Cheers,
> Mitchell
> 



===
Mark Millard
marklmi at yahoo.com