Freescale Synchronous Audio Interface (SAI) - vf610_sai_ac97_read_write: rx timeout, failed to read register 0x7a

Hello.

For our last project we used the Linux version 2.7 with installed (copied) on it Oracle’s JVM.

During running our Java-application we periodically noticed an issue of appearing in console the error of vf610_sai_ac97, after that the Linux-system can sometimes either hangs on, or no.

I thought, that it’s because our Java-application influences to this behaviour of Linux, but sometimes this error can appear after full reboot of Linux before without executing our app, so I changed my opinion about influence of our Java-program.

Here is a screenshot of console output:
[upload|PP6aQaZfcdZstzK5FKrHGpABdOw=]

Also I have attached full text-file of this console output: link text

And here is console output after rebooting:
[upload|YgZJapxizizdOFsMAoehGtMCK34=]

What you can say about it?

Best regards.

P.S. By the way, the file Colibri-VF_LXDE-Image_2.7-20180104.tar.bz2 is exactly as previous file Colibri-VF_LXDE-Image_2.7b4-20171005.tar.bz2, and I wonder that they have various dates.

P.P.S. Here’s a full console outputof the new (last) event, after that our program was hanged up, but Linux is still alive: link text

Hi Volodymyr, which carrier board are you using?

Hello, Mr. Jaskaranjeet Singh.

The carrier board is of our own development.
To the VF61 from it are connected:

  1. Ethernet;
  2. 3xUART (A,B & C);
  3. 2x USB;
  4. LCD (RGB);
  5. 2x GPIO.

The its diagram (PDF-file) is in attachment: link text

Best regards,
Volodymyr.

The following SAI AC97 messages are warnings:

vf610_sai_ac97_read_write: rx timeout, checked buffer 0 to 10, current 1035
failed to read register 0x7a

The Colibri VF61 uses a software implementation of the AC97 protocol which sometimes times out on register reads/writes. The stack then retries which then usually succeeds. That register read/write miss happens rather rarely and is not really concerning.

If you don’t need audio (or to verify that the warning is not related to your issue) you can disable the kernel configuration CONFIG_SND_SOC_FSL_SAI.

The stack trace you are seeing seems file system related, but it is not entirely clear to me what happens.

Do you see the issue on more than one module?

Hello Mr. Agner.

Is it possible do disable audio drivers on already installed (flashed) Linux?
Or it is possible only by building of Linux-image via bitbake? If it is, where I should search CONFIG_SND_SOC_FSL_SAI?

You can build the kernel only as described here:
Build U-Boot and Linux Kernel from Source Code

Make sure to edit .config and remove CONFIG_SND_SOC_FSL_SAI before the compile step.

Hello, Mr. Agner.

I decided to test my program on latest Linux 2.8.b1.
After I started my Java-app on it I immediately have received in console quite long error listing: [upload|8Qx6XVbaxoDZ0iHx6WRrdgVSln0=].

After some investigation I found that source of this error listing is call of cursor creating method from java.awt:

Cursor invisibleCursor = Toolkit.getDefaultToolkit().createCustomCursor(cursorImage, new Point(0, 0), “”);

I use this method for make cursor invisible before drawing a window.

But it is not only one issue. Already after appearing of main window this kind of error can be generated again during program running: [upload|EtKLcSmRoRSbDTjB8tvvAdPi5U4=].

Thus, I wrote for you simple Java-program as simulator. You can find source-code in attachment, as well as its complilated jar-file. You can compile or run it for analyse: link text

With 2.8b1 we enabled user_debug kernel parameter. With that, in case a user space program generates a page fault (SIGSEGV) or other faults, the kernel prints this rather extensive message. While the message is printed by the kernel, the issue happens in the user space java. Debugging Java is outside of the scope of our support.

However, often when user debug prints an error there is not a real issue underlying. Some programs use faults intentionally: E.g. we found that OpenSSL tests which ARM instructions are available and handles the undefined instruction fault (SIGILL). I guess your Java implementation uses page faults e.g. for garbage collection. In fact, this blog post indicates that at least Java HotSpot VM uses page faults for savepoints.

To get rid of this messages simply change the user_debug parameter to not print SIGSEGVs (or any user debug messages by removing the complete user_debug parameter in U-Boot):

setenv defargs user_debug=22
saveenv