Hi,
When i use Orin, a prompt like “The system will power off automatically in 50 seconds” sometimes appears so that i need to choose “cancel” and input my password to return.
Is it kinda “protection mechanism” ? Is there any method to close it?
Sorry for the late response, have you managed to get issue resolved or still need the support? Thanks
Thanks for your reply.
I do still need support.
hello DJI_Jeremy,
I’ve never seen this before, may I know what’s your background running applications?
do you have thermal solution? you may check Thermal Specifications session, there’ll be throttling and shutdown to protect the hardware if temperatures exceed the limits.
please also setup Tegrastats Utility to monitor the process usage and also thermals.
thanks
Can you log in via serial console and run the command “dmesg --follow
” before it shuts down? There might be a useful log message, and serial console will be able to capture it even if the system shuts down.
hello DJI_Jeremy,
it looks low processor usage and also not in critical thermal condition.
please setup a terminal by running $ dmesg --follow
to keep gather the logs. we need to check the messages to understand the circumstances.
Sorry,it is a problem which seems to happen randomly. When the problem reoccurs, i will try to run ‘dmesg --follow’ as you say to gather the logs. But i don’t clearly understand how to log in via serial console?
These are the logs before and after the prompt appeared. But i don’t know if these logs are unbroken.
hello DJI_Jeremy,
please share the logs as text file and upload it to attachment. it’s hard reading by catching logs as screen shots.
BTW, are you using Orin DevKits?
On the AGX there is a USB connector just to the left of the 40-pin header (true for both Orin and Xavier AGX). On the Orin AGX it should be a USB-C socket. If you connect from this to the host PC, then it should make available the serial console. On the host PC, if you monitor “dmesg --follow
”, and then look for new log lines as you insert this cable, it will report serial devices (it should be the first serial device in the case of multiple). Then your host PC can talk to this UART via a serial console program.
Often the serial console program is minicom
, but I prefer gtkterm
(“sudo apt-get install gtkterm
” on the host PC). If that device is “/dev/ttyACM0
”, then this would do the job to start monitoring serial console (adjust for your serial device designation):
gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyACM0
This program (and many others with serial console abilities) can log everything it sees. Just tell it to start logging, and run “dmesg --follow
” on the serial console program (it might require login first). Everything seen goes to the log file you name. You can tell it to stop logging after it fails, and this will have logged more messages than you see on the screenshots since it does not require the GUI. This can be posted here.
Almost forgot: If your user is not a member of group “dialout
”, then you can use “sudo
” in front of the “gtkterm
” command to get permission. Better yet, add your user to group “dialout
”. If for example your user name is “ubuntu
”, then this would do the trick:
sudo usermod -aG dialout ubuntu
log.txt (91.3 KB)
The log has been saved in this file. Hope it is useful.
Thanks for your detailed reply.
Was that log from a system which was connected over serial console and running at the time of a shutdown?
hello DJI_Jeremy,
even though there’re errors with dce-fabric, it’s not impact SC7 functionality.
you may ignore those failure messages.
for example.
[ 710.773507] CPU:0, Error:dce-fabric@0xde00000, irq=24
[ 710.773509] **************************************
[ 710.773510] CPU:0, Error:dce-fabric, Errmon:4
[ 710.773517] Error Code : SLAVE_ERR
[ 710.773524] Error Code : SLAVE_ERR
[ 710.773526] MASTER_ID : DCE
[ 710.773527] Address : 0xdc9ed80
[ 710.773529] Cache : 0x3 -- Bufferable Modifiable
[ 710.773531] Protection : 0x2 -- Unprivileged, Non-Secure, Data Access
[ 710.773532] Access_Type : Read
[ 710.773532] Access_ID : 0x0
[ 710.773534] Fabric : dce-fabric
[ 710.773534] Slave_Id : 0x5
[ 710.773535] Burst_length : 0x7
[ 710.773536] Burst_type : 0x1
[ 710.773537] Beat_size : 0x3
[ 710.773537] VQC : 0x0
[ 710.773539] GRPSEC : 0x3f
[ 710.773540] FALCONSEC : 0x0
[ 710.773542] Slave : T234_SCE_SN_AST0_T
[ 710.773544] **************************************
[ 710.774716] dce: dce_handle_irq_status:176 DCE can be safely powered-off now
[ 710.784610] host1x 13e40000.host1x: suspended
[ 710.851442] Disabling non-boot CPUs ...
according to your logs,
[ 720.796312] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
[ 721.055800] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
do you see issue happened here?
this looks system is idle instead of “power-off”, it might be hardware problem if you actually see an issue.
So what can i do to solve this “hardware problem”?
hello DJI_Jeremy,
are you using Orin developer kit or, it’s a customize board?
I’m using Orin developer kit.
hello DJI_Jeremy,
I’ve never see this kind of failure before, may I know what’s the application you’re running?
please share the detail reproduce steps to re-create this issue locally.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.