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

On Jan 9, 2023, at 11:45, Mark Millard <[email protected]> wrote:

> On Jan 9, 2023, at 11:13, Klaus Küchemann <[email protected]> wrote:
> 
>> Am 09.01.2023 um 17:21 schrieb Mark Millard <[email protected]>:
>>> …
>>> ..
>>> 
>>> 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