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

Klaus Küchemann <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
Hi Mitchell ,

`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)

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> 
—


but perhaps I have overlooked something

Regards

K.



> Am 08.01.2023 um 19:32 schrieb Mitchell Horne <[email protected]>:
> 
> …….
> 
> 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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.