Booting problems after flashing

Hello, I am using Jetson TX1 as development board and during weekend there was some electricity problems that made my PC to reboot and Jetson to shutdown. After that incident I am not able to boot Jetson to GUI. Tried flashing several times - no results. The error that I encounter - Jetson cannot access virtual addresses.

I attach log files to this post. Any help would be highly appreciated.
booting_log.txt (86.6 KB)
flashing_log.txt (333 KB)

Hi evolutionas,

We’re not able to find the log from those link you posted, you could try to paste them or attach in your comment after posted.

Thanks

Hey kayccc,

I attached log files to my previous post.

I see it started booting correctly, when it gets to setting up the console it fails. It looks like the hardware is probably ok, but software is perhaps corrupted.

Do you need to preserve the data? If not, I’d just try flashing again. If you do need to save data, then you might clone the root (“APP”) partition, fsck.ext4 the loopback mounted clone on your host, then flash with the fsck.ext4 “fixed” loopback copy (you can flash using the clone).

Cloning takes significant time. If interested, see:
http://elinux.org/Jetson/TX1_Cloning

If you do clone you may need a lot of disk space. I’m going to suggest that you keep an untouched copy of the clone (about 15GB), then do the loopback fsck.ext4 on a different copy.

hey linuxdev,
I tried flashing few times. No results. There are two cases: 1) ubuntu boots, but suddenly fails 2) error during booting and requires restart. These errors happens continuously, no matter how many times I reboot. Seems like flashing OS does not help. Do you have any idea which part of hardware could have failed?
boot_error.txt (80.5 KB)
restart.txt (114 KB)

Interesting kernel OOPS:

BUG: sleeping function called from invalid context at /dvs/git/dirty/git-master_linux/kernel/arch/arm64/mm/fault.c:272

Also:

Unable to handle kernel paging request at virtual address dead000000100108

The OOPS ends up hitting the watchdog timer. If you were doing anything special, I’d have to wonder if some unusual condition from a custom program were running, but we know better than that already since it is a new flash. There is a possibility that something on your host got corrupted during the power outage, and then the new flash inherited it. You might try clearing out the install directory on your host and completely re-starting with a fresh download.

Another possibility is that something related to mm hardware did actually get damaged…maybe at just one address. You could clone the rootfs/APP partition just to verify basic functionality to read eMMC, and failure would prove it is time to RMA. This particular issue though may not even get tested from a simple clone (I don’t think all of the hardware involved is used during flash or clone).

If a fresh download of all of the flash software to your host does not resolve the issue, then this may be a sign of RMA time.

Well, deleting everything didn’t worked out. I also tried writing to SD card and booting from it. Same results. It is time for RMA