Re: (RPi) db> reboot -> cpu_reset failed
- Reply: Klaus_Küchemann : "Re: (RPi) db> reboot -> cpu_reset failed"
- In reply to: Klaus_Küchemann : "Re: (RPi) db> reboot -> cpu_reset failed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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