Received my Jetson TK1 yesterday. After unboxing it and configuring the Linux GUI, rebooting the device with a mouse (cordless) attached to its USB 3.0 port takes it to some sort of Command line page where it probably loads some files and then the screen starts printing " [ . ] ". Nothing happens beyond that until I restart the board without any USB peripheral and then the device boots into the normal Linux GUI. Unable to figure out what's wrong with my board and why is it not working properly.(I am a newbie to LINUX)
P.S.: Connecting the monitor via HDMI after switching on the device gives no visual output, just a blank screen. Is it possible to connect the device via network adapter for remote access even it the screen is running blank?
The question is quite old, but as some people might get frustrated with it, I'll provide the answer for most probable cause.
Upgrading the board running 19.X release causes libglx.so to be corrupted. The issue have been actively discussed on NVIDIA forums and the best way to solve it is to upgrade to 21.X.
Otherwise, you can try recovering the libglx.so in the usr/lib/xorg/modules/extensions/ from Tegra124_Linux_R19.3.0_armhf.tbz2.
Could you possibly provide a bit more information about your situation.
Are you able to go to command mode by pressing 'CTRL+F1' or 'CTRL+ALT+F1'?
If that works, it means your Jetson operating system is working but only the GUI is not working properly.
Yes, You can use ssh to your Jetson (what I do) if only the GUI of Jetson is broken and your OS is working properly. Note that in order to do so you need to know ip address of your Jetson and perform some possible router configuration.
Note: Sometimes if you have a USB device connected to your system (jetson), the jetson might mistakenly assume the USB is storage type and therefore tries to boot up from the USB. This leads to failure since it can not load any OS of the USB. (I'm not sure if this is the case for you)
Related
What I am looking for: I need help debugging consistently happening system crashes on my Jetson TK1.
System: I am using a Jetson TK1 board from NVIDIA. Updated to 21.3.4 Grinch Kernel. All drivers installed, libopencv4tegra installed alongside ROS (using hacked deb packages to not overwrite openCV). Everything used to work perfectly in this exact setup.
When the crashes happen: I am running a VSLAM program, which uses a camera connected on the USB port. The program is making heavy use of OpenCV. The program used to run for over 1 month without problems in the current setup. Now, I am getting consistent system crashes which result in a total system freeze. When I am connected over ssh, I loose connection. When I connect a monitor to see what happens on the system while it crashes, I can see everything freeze. The USB port also seems to turn off, since not even USB mouse and keyboard work anymore post-crash. The Jetson stays on though.
Crash Logs: I have tried looking into the /var/log/ logs, but none of them show any messages for when the crash happens.
I have run memtester before. It didn't return any bad memory. While running and crashing, the memory onboard is used at about 60-75% (as shown by "top"). CPU usage is around 60%.
The weird thing is that this exact setup has been running just like this for over a month now.
I need to know: are there any other logs I could find information about the crash in? How could I find out if this is related to a hardware failure or whether there's a software issue?
Thanks
-Marc
I want to replicate a feature that exists on Windows To Go solution into Ubuntu Linux (https://technet.microsoft.com/en-us/library/jj592680.aspx#wtg_faq_surprise)
If the Windows To Go drive is removed, the computer will freeze and the user will have 60 seconds to reinsert the Windows To Go drive. If the Windows To Go drive is reinserted into the same port it was removed from, Windows will resume at the point where the drive was removed. If the USB drive is not reinserted, or is reinserted into a different port, the host computer will turn off after 60 seconds.
This means: I run Linux on an USB Stick, and I want it to freeze if I accidentally unplug the USB. And if I reconnect it, Linux will detect it and return to work. Can anyone point some directions to perform that?
Thanks in advance!
I am guessing thats going to be more difficult then you think, the linux kernel and other systems need to know to not panic when it happens. Windows is probably set up better for boot drive failure.
I am working with a SOM mounted on a carrier board running Ubuntu 14.04 with the generic 3.13 kernel.
While testing out the peripherals, I hit a problem with serial communication.
Basically, I can transmit data from the custom platform to an external Linux machine, but I can not properly receive data from the external Linux machine to the custom platform.
Through my research I have messed with all sorts of BIOS settings, baud rates, hardware flow control, parity, etc. Nothing has worked. Most info I have found online just says "Make sure your baud rates and other settings match", and they do. It is not my first time working with Linux serial ports. But it is my first time encountering a problem like this.
Does anyone have any suggestions, recommendations, or has anyone ever seen an issue like this before?
More info: We are running a quad-core Intel Atom micro with a custom serial breakout interface. The serial port is at /dev/ttyS0.
EDIT (clarification):
If I set up a session in Picocom or Minicom, I can send characters from our custom platform (running Ubuntu 14.04) to another Linux PC (also running Ubuntu 14.04). However, if I try to send characters from the Linux PC to our custom board, I sometimes get nothing, and other times get unrecognized characters (they show up as bubbles with question marks in them).
I can also simply echo a string to /dev/ttyS0 on the custom platform and receive it on the Linux PC. I just can't get it to work the other way around.
I'm trying to write a linux driver to a device that i have the windows driver of (Similar to the case described Here, but a different device)
I'm using Libusb for the communication on the linux side, and SourceUSB as my USB sniffer (on the windows machine). Now I think I've replicated the controls and bulks properly, but I can't really test the linux log against the windows one. I'm running Ubuntu 12.04 on a VM.
So my questions are:
Is there a multiplatform logger? That could really simplify the log compare process.
When I attach the USB device to the VM - I get the VM driver in Windows. Sniffing this device gives me exactly what the device sees, right? I mean - Is this where I want to sniff?
EDIT:
I've compiled my application on windows (libusb is cross platform - A big thanks to libusb developers who did such a good job) and my application worked properly.
When sniffing the VM driver while running my application on linux, I see the requests to the USB as VENDOR_DEVICE instead of CONTROL_TRANSFER and BULK_OR_INTERRUPT. This seems to be the problem if I understand correctly, since this is what the device "sees".
So I guess my problem now is why does Linux sends my requests as vendor.
ANOTHER EDIT: Problem solved:
Listening to the VM driver gave me the wrong requests (I was listening to the VM driver traffic, not, as i wanted, the traffic of the my USB linux driver
Libusb is perfectly multiplatform. It took me a few minutes to get my code to compile under windows, and from there it was pretty easy to debug and compare logs
You can use Wireshark to capture USB traffic. This page explain how to do it for Linux and Windows : CaptureSetup/USB
I have a serial GPS connected to an embedded PC via serial<->USB adapter (Prolific PL2303). Every 5 minutes a shell script runs a Python script that reads GPS data via Pyserial then upload them to Internet. If I plug my GPS directly to the PC (via PL2303) everything is ok and my system runs forever BUT if I use a usb HUB between pl2303 and the PC I have a this problem: the Python script runs ok for about 3-6 hours then it goes in a D-state (uninterruptible sleep) and the shell script cannot run it again (I can only shutdown the system, no kill possible). I checked my script and I used usb hubs from various vendors (powered and not) with the same result.
PS my embedded pc (from Embeddedarm) runs an updated Debian Lenny.
Ho can I fix it ?
A process in D state means the kernel (most probably a device driver), has put your process into uninterruptible sleep.
To be honest, there is probably quite little you can do about it as a user, unless you intend to debug the kernel USB stack and/or specific USB chipset device driver.
Here is what would do -
Make sure the kernel configuration of you embedded device has the kernel config option for the magic sysreq key and the run time configuration for it turned on. See: http://en.wikipedia.org/wiki/Magic_SysRq_key on how to do that.
Recreate the problem (have the process get stuck in D state).
Find out the PID of the stuck python script with ps and run strace -p PID on it. This will give you the specific system call that the process is sleeping in.
Send the magic sysreq key command 't', that lists all tasks and their kernel stack to console. Look for the specific task of the python script by PID, see at what part of the kernel code exactly are you stuck.
Open the kernel code and try to debug the problem if you can, or port it to the relevant mailing list if you don't.
One more suggestion would be to try and see if the problem goes away in a more recent kernel version then Debian ships. If so, you know it is a bug fixed in newer version of the kernel and you have the choice of either using the newer version and try to port the fix to the old version you care using.
Good luck! you'll need it...
Ubuntu launchpad has a bug filed that is suspiciously like yours. The workaround suggested is:
modprobe -r pl2303
modprobe pl2303
See if this works around the bug?