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

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On Jan 9, 2023, at 00:15, Klaus Küchemann <[email protected]> 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 <[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
> 



===
Mark Millard
marklmi at yahoo.com
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.