In the startup process will occasionally encounter the following situation,what should i do?

I use the jetson-tx2 module, in the startup process will occasionally encounter the following situation,what should i do?
random: crng init done
random: 7 urandom warning(s) missed due to ratelimiting

This should not cause any problem. You can just ignore it.

but The system won’t boot up

Then you should provide below info. Tell us more detail about this board.

System version Ubuntu 18.04.5 LTS (GNU/Linux 4.9.201-Tegra AARCH64), bootable card at Random: 7 Urandom warning(s) Missed due to Ratelimiting

Err… and any other information?

Do you really read the post? If you have language problem, please use the translator.

The urandom warning is actually the last successful thing performed. This is part of normal operation whenever there is a soft realtime process which is being limited from too much use (e.g., audio). All Jetsons which I know of present this warning just before making login available. On the other hand, the documents describe a serial console logging method, and knowing the complete log is one of the few ways to see what is going on (such a log shows logging from bootloader stages prior to the Linux kernel running, along with Linux log messages…the cause of such a failure is probably mentioned much earlier in the logs than what occurs right at the point of failing).

So how can I see where is stopped

You didn’t provide any information yet. How can we help you?

The serial port output stopped here, I can’t see any information, and the controls can’t enter, is there any way to get more information .

What is the post telling you to share?

Do you have any problem to understand it? What kind of carrier board are you using?

custom board and JetPack_4.5.1_Linux,My problem is that the device stopped in the middle of startup. The last debugging message of the serial port is “random: 7 urandom warning(s) missed due to ratelimiting”. I could not access the console and could not get any other information

Yes, we know your problem. You’ve told it more than 3 times.

Custom carrier board may cause such problem. Remove the quiet keywords in /boot/extlinux/extlinux.conf and check if any further log prints.

You need to post the entire serial console boot log. It isn’t the end of the log we are looking for. Most likely the error message was from earlier on, but the failure didn’t occur until later. Serial console programs can log all activity, and if you start logging prior to powering up the Jetson, then the log will likely contain good information on the failure.

log.txt (77.0 KB)
This is the log of the boot.

Let me just go straight and tell you what to check.

  1. Please check if this issue only happens to your board. If it is, please review the power sequence and if the voltage is sufficient.

  2. If the power is not the problem, please remove the peripherals on the board and see if any of them causes the problem.

1、The device input is 12V;
2、the power sequence and the voltage is OK;
3、the log shows that the system has been started, as if the service is blocked during startup;
4、 And the problem is random;

The “random” warning is actually not a problem. It is just the way some “real time” components were set to log to tell you something like audio is trying to use too much data. This always happens on all Jetsons, and I’d be more worried if the message did not occur.

Your log is at the point where logging is normal and then just stops. You mentioned that this is “occasional”, and not “always”. What @WayneWWW mentions is something you shouldn’t skip because we know this device can work, and Jetsons are rather picky about power supplies (they have to have above average regulation…not all 12V “regulated” supplies will remain within specs as different devices power on, especially ones which consume significant power). In cases where the power supply itself is good, then the carrier board should be considered since it is what deals with power for the most part. If another Jetson module always works on that carrier, then it might be the module. If the module which now fails works on other carriers without this issue, then it might be the carrier board at fault. If both modules fail only on this carrier board, then it might be the carrier board or power. So swapping with the supplied dev kit power supply for testing is a good thing to check for to see if it is the power supply’s regulation at issue and not a carrier board (there are a lot of power supplies out there which are ok “much of the time”, but still are insufficient under certain power spikes).