Timeout (urb) while flashing Jetpack 4.2.1 on some jetsons (TX2)

Hello,

I’m having an issue while trying to flash Jetpack 4.2.1 (AND only this specific Jetpack version) on some jetson (TX2).

With “some jetson” i mean a specific serialnumber range.

It works with S/N 14244 YYYY XXXX
It does not work with S/N 14241 YYYY XXXX and S/N 14242 YYYY XXXX

We have about 60 Jetsons within these prefix ranges, which are not working with 4.2.1

What does the error look like:

[ 9.8769 ]
[ 9.8799 ] tegrarcm_v2 --boot recovery
[ 9.8827 ] Applet version 01.00.0000
[ 10.0664 ]
[ 11.0682 ] tegrarcm_v2 --isapplet
[ 11.7395 ]
[ 11.7426 ] tegradevflash_v2 --iscpubl
[ 11.7439 ] Cannot Open USB
[ 12.1253 ]
[ 13.1296 ] tegrarcm_v2 --isapplet
And then the process is just stuck …

After a while i see a timeout for the usb access with dmesg:
[ 2950.515574] INFO: task tegrarcm_v2:8533 blocked for more than 245 seconds.
[ 2950.515582] Tainted: P OE 5.4.0-77-lowlatency #86~18.04.1-Ubuntu
[ 2950.515585] “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message.
[ 2950.515588] tegrarcm_v2 D 0 8533 8371 0x20020000
[ 2950.515594] Call Trace:
[ 2950.515605] __schedule+0x295/0x740
[ 2950.515610] schedule+0x3a/0xc0
[ 2950.515615] schedule_timeout+0x15b/0x330
[ 2950.515623] ? __next_timer_interrupt+0xe0/0xe0
[ 2950.515628] wait_for_completion_timeout+0xa5/0x130
[ 2950.515632] ? wake_up_q+0x80/0x80
[ 2950.515640] usb_start_wait_urb+0xe3/0x180
[ 2950.515647] usb_bulk_msg+0xb8/0x160
[ 2950.515653] proc_bulk+0x257/0x3a0
[ 2950.515660] usbdev_do_ioctl+0x93d/0x1480
[ 2950.515666] ? handle_mm_fault+0xd5/0x210
[ 2950.515672] usbdev_compat_ioctl+0x10/0x20
[ 2950.515678] __ia32_compat_sys_ioctl+0x105/0x230
[ 2950.515686] do_int80_syscall_32+0x5b/0x130
[ 2950.515692] entry_INT80_compat+0x85/0x90
[ 2950.515696] RIP: 0023:0x807a454
[ 2950.515706] Code: Bad RIP value.
[ 2950.515709] RSP: 002b:00000000ffcb2478 EFLAGS: 00000283 ORIG_RAX: 0000000000000036
[ 2950.515714] RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00000000c0105502
[ 2950.515716] RDX: 00000000ffcb24a0 RSI: 0000000000000010 RDI: 0000000008ac3688
[ 2950.515718] RBP: 00000000ffcb2500 R08: 0000000000000000 R09: 0000000000000000
[ 2950.515719] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 2950.515721] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

Does any know a way to convince the jetsons to be flashable?

Some more information:

  • We are not flashing from a VM
  • Other JetPack versions are flashable (for example 3.3.3 and 4.4.1 work just fine on both S/N ranges), however our customer is tied to JetPack 4.2.1 dependencies.
  • The cable works just fine (i use the same cable as above)
  • The error appear when using flash.sh and sdkmanager
  • I tried using the flashing applications/scripts from working Jetpack versions, but no luck (or maybe i replace the wrong ones).
  • It is stuck in check_ismb1() in tegraflash_internal.py (which in turn is called by tegraflash_poll_applet_bl().

Thanks in advance!
error_log_flash.txt (23.9 KB)
usberror (3.5 KB)

One suggestion as a test and perhaps as a workaround: What happens if, when it is obvious the process has just begun “sticking”, you unplug and replug the USB cable? Obviously such a thing should not start at all, but I’m wondering if a hot plug can work around this.

hello c.hartmann,

here’s Jetson TX2 Product Change Notice (PCN) for your reference,

Hi,

thanks for the tip, but i already tried that (after reading about similar issues). Same result.

But thank you anyway.

If i’m understanding you correctly there has been some changes, which might affect the jetsons we received.

PCN 206440 (the document) states that all with specific partnumbers or level-part-numbers might be affected, how do i destinguish these. part number is always 900-83310-0001-000 and level- part-number is always 699-83310-1000-D02.

The document also stated that a patch may be requested for other Jetpack versions. How would i get my hands on that?

There is no patch for JetPack 4.2.1, and please migrate to newer version that mentioned at the PCN do to get this issue fixed.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.