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