Tests found: reboot failed. but power-on again is OK.

I have many test(about reboot).
but: Tests found: reboot failed。 but power-off-on again is OK。
write in the terminal: reboot. ping IP is OK,but ssh is failed.
if the divice power-off-on again。 the divice is OK.

Hi zbit,

Are you using the native image we provided? Which version? Repro rate? Log file?
Any device connected with you TX1?

Please provide the clear steps, then we can try to repro to see where might be wrong.


yes, I have not change image. and , I use commond : reboot -f . then device is OK.

Hi zbit,

Are you using jetpack with devkit?

yes. install by jetpak 3.0.

Is there a particular use-case of why you want to use “reboot -f”? I ask because this bypasses init and most likely requires the ext4 journal to lose the most recent file system changes when it comes back up (similar to cutting the power wires). I would think that this is useful only for an emergency.

Any log from uart after “reboot”??

this picture:

Does anything change if you remove all possible USB devices? If you use a keyboard to issue the command, try removing the keyboard right after the reboot command. If the issue then changes, try reboot again adding one USB device at a time…you may have a particular USB device causing problems.

Hi zbit,

I cannot reproduce this issue on my devkit. Could you provide more details about your error and environment?

system is on mount Sata. is not on mmcblk0p1.

So you flash it with ./flash p2371-2180 sda1 and connect some usb devices?

i have try dd if=/dev/sda1 of=iso. then dd if=iso of=dev/sda1(new device).

and system is on mount Sata.
many error infomations

Hi zbit,

I mount my system in sata with some usb devices connected, but I don’t hit these errors.

May I ask how you mount your system on sata and what usb device do you connect? In previous comment, I believe you use jetpack3.1 with tx1 devkit. Am I right?

If you boot without the SATA drive connected (or at least without using the SATA device as a boot device), what does “lsusb -t” show? If this shows at a speed of 5000M (USB3 standard), then it is possible the issue is caused by switching from USB2 mode in U-Boot to USB3 mode as the kernel takes over (restarting the controller and switching modes would invalidate anything depending on a continuous operation of the device). If this is the case, then you could test if forcing the USB port to USB2 under the Linux kernel causes the drive to work as a boot device. I’m betting U-Boot still does not support USB3 mode even in R28.1.

root@tegra-ubuntu:/home/ubuntu/data/libRtspClientAPI# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/5p, 480M

but I input commond : reboot. then , systeam is blocking. have not in boot link.

In the above “lsusb -t” I see no USB devices installed at all (the r8152 is internal to the TX1); only root HUBs are shown. Can you show “lsusb -t” with the USB SATA drive connected? Don’t boot from the drive, but attach it after boot is complete (if the drive was attached during the “lsusb -t” then there is an error that USB could not see the drive at all).

Hi linuxdev,

May I ask why to try “boot without the SATA drive connected”? I think it would cause error if we boot from sata drive, doesn’t it??

Also, could you elaborate your guess? Why does this case only happen in reboot but not in boot up procedure?

I’m interested in behavior change between the two configurations. There are both software and hardware/power components involved…and it is easy to test.

On the software side I am somewhat curious because of the separation of USB controller initialization in U-Boot versus under the Linux kernel. In theory the device tree should be something like a constructor on a new object and guarantee a certain state each time the object is created. In the case of a full computer system there should be no difference in state between a cold boot and a soft boot at the moment the boot loader is done, but this is not always the case. Sometimes part of the hardware actually preserves a state between software reboots which would not have existed from a cold boot. Changing when the USB disk is added may cause such differences to stand out…and of course it is very easy to test compared to something like putting it on a JTAG debugger.