Do you have serial console available? Info:
http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/
I am thinking that the issue might be USB auto-suspend. You might try this with the mouse and keyboard (this won’t stick around after boot, but if you want to make it permanent, then there are methods to do so on the kernel command line). Before you start, look at the following:
lsusb
Each USB device has a combination of product and device ID. For example, I have a cheap keyboard which shows up with “ID 04d9:1603”. Write this down for both mouse and keyboard. After this you may want to “sudo -s” to stay in a root shell, but most access which follows requires sudo.
Note that keyboards and mice are “HID” devices (they use the Human Interface Device generic drivers). cd to “/proc/bus/input/”. Look at the contents (there are many ways to do this). For example:
cd /proc/bus/input
less -i devices
Then search for “keyboard” or “mouse”. You will see a “Sysfs=” entry which identifies where the devices are in terms of “/sys” controllers. For example, I have this with a keyboard:
I: Bus=0003 Vendor=04d9 Product=1603 Version=0110
N: Name=" USB Keyboard"
P: Phys=usb-3530000.xhci-2.4/input1
S: Sysfs=/devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4:1.1/0003:04D9:1603.0002/input/input4
Note that earlier I said my lsusb ID was “ID 04d9:1603”. The first part is a vendor, and matches, the second part after the ‘:’ is the product, and this matches. Now cd to the Sysfs part (substitute for what your mouse or keyboard is, but you have to prepend “/sys/”):
cd <b><u>/sys</u></b>/devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4:1.1/0003:04D9:1603.0002/input/input4
Verify this is the correct device via “cat name”. Now cd to “power/”. Verify this is currently in “auto” mode:
cat control
Now, for this boot only, temporarily force this always on:
echo 'on' > control
# Verify now "on":
cat control
Do the same thing with both keyboard and mouse. Now let this keep running long enough to see if you still have the same issues. If this does the job, then two things can occur. First, NVIDIA might be able to help debug. Second, this is a workaround, and auto suspend could be disabled via other methods which persist across reboots.
If this does not help, then you will want to leave a serial console running and monitor the Xorg log:
sudo tail -f /var/log/Xorg.0.log
(there may be cases where it is “Xorg.1.log”…“ls -ltr Xorg*” will list logs in reverse chronological order…the last one to list is the active log after a boot)
FYI, X uses the USB subsystem (along with udev) to do the work of identifying input devices. My thoughts are that probably USB is not failing so much as something is interfering with X picking the devices back up after a suspend. The tail of this log will make notes about a suspend operation, and then again upon wake. Assuming you test without disable of auto suspend, then I’m thinking you will see a suspend operation, but no wake operation, and probably no actual errors. You could do the same with “dmesg --follow”, but you can’t do both on the same serial console (well, you could, but it would not be worth it).
Side Note: You probably do not want to block traffic on “localhost/loopback/lo/127.0.0.*”. This is traffic which is not going to the outside world. Traffic which is purely on that interface should be whitelisted.