Start a new topic

TS-7600, Full Debian Boot, xuartctl using 100% of cpu?

OK, not 100%, but all time that would normally be idle. I was look at htop (and top) to see how much CPU my application was using and I was surprised to discover that xuartctl was solidly locked in the top spot and total CPU usage stays at 100%. Since booting (a little over 10 minutes ago), top shows xuartctl as using over 11 MINUTES of CPU, while both top and my program are each showing a little over 2 SECONDS. I am connected using ssh (from PuTTY on a Windows system) and, as the title says, this is a TS-7600 board running in the full Debian environment. I expect I have a config error somewhere, but I'm not sure what it could be. Any ideas? (FYI: I am trying to attach a screen cap of htop from when I noticed this, but I cannot tell if the forum is actually accepting the file when I choose it. Hopefully it will be attached ... and only once ... but I just cannot tell.)

 Here's the file (again ... I hope!) that the original post refused to accept.

A little follow-up...  the ts7600 ran with xuartctl using as much CPU as it could get for about a half hour, when I issued a reboot command to the board.

When it came back up, xuartctl appears to be well behaved and using virtually no CPU.

The strange thing now is that I don't have *ANY* serial I/O in my program and I most definitely don't use xuartctl (or the associated library) in my program, yet it goes "berzerk" on some boots, while not on others.  I configured it with the --bind= --irq=100hz options that I found in the config file (and the xuartctl manual) to ensure no external access and minimal (?) CPU usage.  So why might it decide to "eat" the CPU at times?

If I figure out how to keep it from running at all, with the local serial console still work or is that the only reason that I might want to keep xuartctl on my system?


This is definitely something we have not had brought to us in the past nor have we seen here at all during the life of the TS-7600.

Are you able to reproduce this in any way with an unmodified stock image? What image date is your current system starting from ('cat /root.version')? Are you able to reproduce this on multiple units? We can try to investigate this as far as you are willing, but we would definitely need a lot more data points to get traction.

We have also previously made a patch that can be applied to the initramfs that will prevent xuartctl from being used at all. This will disable the proxy console via telnet, but the physical serial port will still function. However due to the initramfs setup, a kernel recompile is necessary in order to apply the patch.

1) Begin by following the kernel build instructions here:

2) Run through those instructions all the way until you run 'make ts7600_defconfig'

3) Unpack the "initramfs.cpio-ts7600" CPIO archive file in to a new folder and move to that directory.

4) Apply the attached patch, "patch -p2 < noxuartctlproxy-initramfs.patch"

5) Create a new CPIO file from this folder structure with the modified "init" file

6) Link or name the file "initramfs.cpio"

7) Skip the step in the manual "ln -sf initramfs.cpio-ts7600 initramfs.cpio"

8) Continue with the rest of the kernel compile steps.

The patch simply removes all the setup calls to 'xuartctl' and sets the physical console port as the $CONSOLE for the initramfs and further booting in to Debian.

(935 Bytes)

So far, I have only seen this condition occasionally under the full Debian boot environment.  When I have seen it, I typically use "killall xuartctl" and the problem (and program) goes away.  For my uses, I have not seen any difference in the way the system or my program works.  Also, I only use the full Debian environment for development -- the production devices are designed to use the initramfs environment (where I have not seen this issue.)

In fact, for the production devices our customers typically request that we ensure that nothing like telnet/sshd are running on the device, though we typically deliver them with telnetd being started in the /mnt/root/ts/init script.

FWIW, I tried "killall xuartctl" from a telnet session in the initramfs environment and the "red light" on the TS-7600 came on and stayed on until I cycled power to the board.  Needless to say, my telnet session was frozen, too, during that time.  Luckily, I don't think I have an issue in the initramfs environment.

I don't currently have MicroSD with an untouched image to experiment with, but I could download the current image and create one, if necessary.  My main curiosity was to find out if there were any known reasons why xuartctl might eat the cpu when the only thing connected was an ssh session -- not even a serial cable attached.  Could there be some interaction with the USB keyboard device we have attached?  If you haven't seen anything and cannot think of anything, then I'm OK with it for now, since I have only seen it in the full Debian that I only use for development AND I can kill the offending program (in the full Debian environment, at least) without any impact on my tasks.



Unfortunately we have not seen this before. We design our ctl applications to be rather self contained; xuartctl is purely a bridge between FPGA and kernel. It communicates to the kernel as a pseudo-tty device, and polls (or waits for interrupt) the FPGA peripheral. It is unlikely that external peripherals like a USB keyboard would impact this. If the current situation is acceptable for you then so be it. But if that ever changes please let us know and we can help you investigate further, or help you with removing all use of xuartctl on this platform.

Login or Signup to post a comment