Sluggish Tx2

Hi Folks,

I see my Tx2 getting very sluggish often enough.

  1. While editing files in gedit, when we save it often goes unresponsive. I would gray out entire gedit GUI for 5-8 seconds.

  2. When we do normal compilation, sometimes make command does not respond for another 5-8 sec.

  3. While, searching for a particular file - sudo find / -name ‘libovx.a’ takes more than 2 to three minutes. There are not that many files on our Tx2.

Please enlighten, about potential causes/leads.

Thanks,

This sounds like the embedded flash drive is slow.
Is it almost full? Some flash devices really don’t like not having lots of free space; they end up spending a lot of time garbage collecting and shuffling blocks around.

You should also check kernel messages when this happen; you may be experiencing timeouts and re-tries for example, which would indicate either a bad connection or something more serious being wrong.

You might also install “htop” and watch to see if there is any obvious extreme resource hogging going on.

Hi Snarky and Linuxdev

THanks for your responses/help.

  1. My flash drive is relatively empty

ubuntu@tegra-ubuntu:~$ df .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 123287548 24978092 92023736 22% /

From your comment, I infer that this could make it move block around, in order to do garbage collection. Would you happen to know the name of that process with does this ? I will check if that process take more memory / cpu cycles.

  1. Where can I check kernel messages ? Is there a log file somewhere ?

Hi linuxdev,

I do not see much with htop. none of the cpu is loaded more that 3%. None of the process takes more than 5% mem. THis is the state soon after boot up. When I try to launch firefox after boot up - is takes long long (about a min) time trying to connect to nvidia developer forum (the screen grays out). I checked from other PCs that my connection is proper.

Thanks,

It’s done by the electronics on the flash drive itself. Linux doesn’t know about it. If the drive is largely empty, this is unlikely to be the problem.
In this case, it’s more likely that you have either a marginal eMMC storage device, or some problems with the bus it’s attached to (which is inside the Jetson module.)

A quick web search for that exact question says that two commands you can look at include:

dmesg

and

journalctl -xb

There will be some output that’s not at all related to storage, so you’ll have to sift through these messages to find what might be relevant.

I would have to assume firefox has a complicated set of dependencies. Perhaps it is blocking and waiting until something times out. Blocking and waiting would be consistent with low CPU and RAM usage (it isn’t all that different from waiting for a slow disk, but the slowness would be a software issue instead of hardware).

One example of something you might want to do for testing is to be sure that on start-up firefox is set to use a blank page instead of a URL.

One additional note on dmesg: Recent distributions have a “–follow” option, and “dmesg --follow” will show continuous output as dmesg is updated…use that while opening and using firefox.

While firefox start-up may be a problem, I think the original three problems indicate it’s something disk I/O related:

Hi dumbogeorge,

Have you clarified the cause and resolved the problem?
Any further update?

Thanks

Hi KayCCC

No we have not been able to spend any time on this issue. Living with our system, to address other higher priority issues.

Thanks,