Unfortunately, I could not find other topics treating dmesg issues on the community forums.
The setup is:
- SabreLite board from Boundary Devices connected to a Windows PC using this terminal (through UART).
- Android v13.4-ga;
- linux kernel v.3.0.35 from Boundary Devices.
The use-case is like below:
1. let the board boot-up;
2. see console messages populating the terminal window;
3. see the Android lock-screen on the LCD;
4. clear the terminal contents;
5. perform "dmesg" command in terminal Tx field;
6. see kernel ring-buffer contents filling the terminal. save in text file.
7. perform steps 4-6 several times => generate several text files.
8. compare the text files => the files are NOT identical; There are several differences not at the end of files, but somewhere in the middle portion.
This is an awful issue. How can I trust DMESG ? Anyone experienced this?
We didn't seem this before.
Is the Terminal setting like this?
115200 BPS, 8 bits, no parity, 1 stop bit and no flow control.
what kind of Terminal are you using? something like "Putty"?
The terminal is this one.
The settings seem to be correct (115200, 8b, no parity, 1stop bit, no flow control).
After some investigation performed today, it seem my laptop's CPU load is affecting the results.
- If Windows is just restarted and no other program runs except the terminal, several logs taken by entering "dmesg" are identical (Putty and Bray's terminal both tried).
- However, upon starting the PRIME95 tool and leaving it to run in background, the issue is starting to occur.
So, it seems to be not a kernel problem.
I will perform the same tests on my Ubuntu PC and, in case of better results, I'll switch my tracing activities to Linux environment.
Thank you for support.
What you mean the "Not identical"? can you show some examples?
How about the logcat output?
I think you are using Android, DMESG may not able to show all the things you need.
Maybe this link can answer your question.
Thanks for not bypassing my question.
Please, find attached 4 text files obtained by following the scenario described in the first post.
In my understanding, since no new activity performed in the kernel, ring-buffer contents should remain unchaged.
However, every new "dmesg" command sent over Uart-Tx reveals different buffer contents in the terminal window (Uart-Rx).
Unfortunately logcat cannot help me, as I am tracing the kernel drivers, not android framework/apps activity.