Re: (RPi) db> reboot -> cpu_reset failed
- In reply to: Mark Millard : "Re: (RPi) db> reboot -> cpu_reset failed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 09 Jan 2023 20:36:28 UTC
On Jan 9, 2023, at 11:45, Mark Millard <marklmi@yahoo.com> wrote: > On Jan 9, 2023, at 11:13, Klaus Küchemann <maciphone2@googlemail.com> wrote: > >> Am 09.01.2023 um 17:21 schrieb Mark Millard <marklmi@yahoo.com>: >>> … >>> .. >>> >>> 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 >>> …. >>> >>> === >>> Mark Millard >>> marklmi at yahoo.com >> >> >> Mark, I also don`t see the new expected output text… >> do you see any effect , have you tested on an RPI?, > > I've only been reading along, not testing the patches. > (For one, my normal environment has its own patches > involved, making for a unclean test environment if > used.) > >> I would be very happy if I’m mistaken and if it would work.. >> - >> O.K., now tested the new Diff 114868 of D37981, >> Also no effect to ‚reset‘ by an provocated early boot panic… >> >> I think you`ll need a real hardware debugger to e.g. track the issue that the software debugger can’t >> execute shutdown_reset(NULL, howto); > > I have no access to such. > >> safely in early boot stage without calling the bcm2835_watchdog directly :-), >> and you would need it anyway for board bringup issues.. >> Afaik that’s normal on embedded >> >> Please consider this only as a test report, not as a scientific statement, >> I don`t have any knowledge of db_command.c Given the BOOTTRACE(...) usage that I see, having: kern.boottrace.enabled=1 in /boot/loader.conf (or set via the loader?) might prove interesting during the reboot attempt from the db> prompt. === Mark Millard marklmi at yahoo.com