Hopefully ASAP. The team is working on resolving the issue and we’re trying to characterize more units from the field.
If you’re experiencing the behavior, please let us know the serial of your unit (from the underside near the edge). Thanks everyone.
I also had the super-laggy problem and the “disable WiFi” fix above did the trick. The laggy problem was most severe and obvious when I ran the System Monitor. It would lock up for several seconds at a time, then run for a fraction of a second, then lock up again. With wifi disabled everything is fine. In case it matters, I did not attach the wifi antennas. S/N: 0324415050322.
Had lag issues as well, that got fixed by disabling the WiFi Firmware, as mentioned above in #19.
S/N: 0324515042241
Error message before disabling WiFi:
[ 116.009320] mmc1: Data CRC error, intmask: 200000 Interface clock = 204000000Hz
[ 116.019129] sdhci: ================== REGISTER DUMP (mmc1)==================
[ 116.027491] sdhci: Sys addr[0x000]: 0x00000000 | Version[0x0fe]: 0x00000303
[ 116.035873] sdhci: Blk size[0x004]: 0x00007040 | Blk cnt[0x006]: 0x00000000
[ 116.044253] sdhci: Argument[0x008]: 0xa5000040 | Trn mode[0x00c]: 0x00000003
[ 116.052628] sdhci: Present[0x024]: 0x01fb00f0 | Host ctl[0x028]: 0x00000013
[ 116.061006] sdhci: Power[0x029]: 0x0000000d | Blk gap[0x02a]: 0x00000000
[ 116.069378] sdhci: Wake-up[0x02b]: 0x00000000 | Clock[0x02c]: 0x00000007
[ 116.077742] sdhci: Timeout[0x02e]: 0x0000000e | Int stat[0x030]: 0x00000000
[ 116.086085] sdhci: Int enab[0x034]: 0x02ff000b | Sig enab[0x038]: 0x02fc000b
[ 116.094417] sdhci: AC12 err[0x03c]: 0x00000000 | Slot int[0x0fc]: 0x00000000
[ 116.102726] sdhci: Caps[0x040]: 0x376cd08c | Caps_1[0x044]: 0x10006f73
[ 116.111024] sdhci: Cmd[0x00e]: 0x0000353a | Max curr[0x048]: 0x00000000
[ 116.119297] sdhci: Host ctl2[0x03e]: 0x0000300b
[ 116.125020] sdhci: ADMA Err[0x054]: 0x00000000 | ADMA Ptr[0x058]: 0xe9500010
[ 116.133342] sdhci: =========================================================
It looks like there are some other topics being discussed here, but to follow up on my original issue:
I ordered a new display with a native HDMI interface. That arrived today and I hooked it up and it worked right away.
I’m having similar issues here - I originally hooked up the TX1 to the same monitor that I was using on the TK1 and couldn’t get it to boot (or so it seemed). I had the HDMI cable going to a DVI adapter that plugged into the Dell monitor. Once I hooked it up to a different monitor that had an HDMI input it works. Why the difference?
IF however I start it headless, I can’t get the monitor to come up if I plug it in later–it just goes to sleep. I have to restart the board with the monitor plugged in.
I have done the following to set it up in headless mode:
Add this stanza to /etc/X11/xorg.conf
Section “Screen”
Option “UseEdid” “False”
EndSection
and run this command:
echo “manual” | sudo tee /etc/init/lightdm.override
How can I get the monitor to come up if I initially start it headless?
One issue sometimes causing problems is that of the EDID data of the monitor responds with a broken format (the EDID is sent from the monitor to the video connector after an EDID query from the Jetson). Because the EDID is required for automatic setting of a mode compatible with both the video card and the monitor, failure of EDID means you have to get lucky that a mode used by some default on Jetson also matches a mode the monitor is capable of running.
Note that DVI and HDMI are both compatible with EDID, that an adapter between the two should work. However, sometimes cable signal quality is an issue…adding adapters or longer cables of an older standard may degrade signal quality and indirectly effect EDID.
FYI, there have been some issues with default mode in text console during boot behaving with different defaults versus when X11 starts and Jetson goes into graphics mode…text mode during boot may use different EDID parsing and EDID response, thus it is possible for console to fail while graphics works, or vice versa (by console I mean the directly connected monitor…serial console is unrelated).
A broken EDID would have a similar effect as intentionally disabling EDID.
So far as how to make things work with headless and still function correctly with a monitor, I don’t know…I suspect it can be done if you use more than one “Section” in your xorg.conf, but tie this to different monitor setups…I do not know what would actually be required. The basic idea is that different monitor and device sections can exist, and if EDID is tested and successful at matching a section, it would work, else fall back to the non-EDID section.
If you install packages “read-edid” and “edid-decode”, you should be able to run a command which tells you at least part of what your system sees as a monitor response. Try adding those packages and look at the outputs of:
get-edid | parse-edid"
get-edid | edid-decode
-
Where is the debug uart documented?
-
There are uart pins on J21 (easy to connect to, it’s a .1’’ pitch connector), on J17 (ditto), and on J10 (high-density samtec connector – is there a breakout cable/board for it?). If I am reading the docs correctly, the J17 and J21 pins are 3.3V, but the J10 pins are 1.8V. Is this correct?
-
Are the 3.3V UART pins 5V-tolerant?
Thanks
/ji
The serial console for JTX1 is described here:
[url]Jetson TX1 - eLinux.org
Be sure to use a 3.3V-compatible serial UART…I don’t know if a 5V UART would work…even if there is no harm, the levels for “low” may not be reliable.
By “documented” I meant “how to get kernel debugging output”, and which UART it is going to. The wiring is obvious. Thanks though!
I’m not risking a $600 board, so I ordered a pair of “ftdi friends” from Adafruit!
The settings are for a standard serial console application such as minicom, gtkterm, or PuTTY. I’m not sure which UART is referred to in TRM for this, but it is the one going to J21. Setting is 115200 8N1. If CTS/RTS are connected, use this for flow control; if just data and ground, use software flow control.
The default for u-boot output and the L4T kernel is to always have this console available and logged in…no other configuration is needed. One can change kernel log level messages and have some control over what goes to the serial console, but serial console already receives information all the way from boot loader through completed boot, and if certain errors show up, these are also automatically sent to serial console. For example, a kernel OOPS should go there.
So long as your attached serial UART is designed for 3.3V there should be no risk of damage.
Hi everyone,
I meet a trouble today,as i copy a file to my /usr location, have a warning “sudo:unkown uid1000:who are you?”, then, i restart my tx1, but i can’t boot the device just as this topic said " I get the green power and SOC LEDs, but nothing on the HDMI output", and i use the tx1 with native compile before, now i don’t kown how to do and don’t understand above topics you said such as USB A port and USB recovery, can anyone tell me how to do, can i solve it? can i get the documents and codes in the file sysytem or i need root the device? (sorry for my poor english)
You might be better off starting a new thread. In general though missing UID 1000 means your administrative user Ubuntu does not exist. This is a serious problem, but likely software and not hardware.
If the operating system was previously working correctly, then this could be a security issue…everyone knows the default login user name and password for Ubuntu, so unprotected exposure to the internet would have resulted in a malicious hack. Protection could be in the form of a router stopping outside networks from reaching the Jetson, but a router would still expose the Jetson to internal network. Other protection might be as simple as changing the ubuntu user’s password.
If the system was not exposed to the internet without remote access protection, and if the system previously worked, then more information on what changes were made need to be listed. Generally speaking failed modifications would be best dealt with by reflashing.
About USB ports: The micro-USB port is called “On the Go” (OTG) because it accepts either a type-A cable or a type-B cable. The supplied cable is type-B. During normal operation a type-A could be used for standard peripherals, for example, USB keyboard or mouse. When a Jetson is in recovery mode, then you must use the type-B cable instead. Recovery mode is not normal operation; this mode allows the Jetson to respond to flash software (the mode itself does not do anything and is safe to view). Holding the recovery button down while powering up the Jetson puts the Jetson in recovery mode. If the Jetson is in recovery mode with the proper cable going to your x86_64 host, then you can see the existence of a flashable Jetson via “lsusb -d 0955:7721”.
linuxdev, thank you very much! I find you answered my most questions!
I reflashed my tx1 after that, and didn’t get my files on the tx1, fortunately, i spent only one day to rebuild my environment.
The operating system was previously working correctly and exposed to the internet, maybe it’s because of the malicious hack.
and maybe it’s my false changes on the file system, i had copied some .h files to the /usr/local/include and under a named “" folder, then i think it’s not well, so i "sudo rm -r /usr/local/include//” then “sudo:unkown uid1000:who are you?” appeared! maybe it’s the “*” folder’s fault!
No change to “/usr/local” would ever harm boot unless you had a library path configured to make it mandatory (which is rare and you’d know it if you put a system library there…CUDA and many third party libraries are harmless in “/usr/local”…pretty much anything user space can go there and failure won’t hurt upon removal).
Operating normally and then missing that uid is highly suggestive that someone accessed the system and did something malicious. In the past when I’ve installed Linux on a system exposed to the internet I see logs of incoming hack attempts within the first 30 seconds. The hack attempts escalate quite a bit within the first 24 hours. In the past I had a Linux bridge set up to log and actively respond to malicious attacks (I had “snort” installed…hacks were challenging the bandwidth of my 56k modem…active blocking was mandatory). It’s astonishing how fast and automated those attempts are when you enable logs…logging alone would consume a disk very quickly if not for log rotation.
FYI, the first hack attempts to get logged will be common administrative accounts and default passwords. Then dictionary words will become the next attack. After that probably various ports will be checked for services with vulnerabilities (default services on Ubuntu seem to be pretty safe, especially if updated…not much is exposed without explicit admin modification).
So it is, i will try not to use the internet to avoid the malicious hacks.