We are seeing kernel 'Oopses', while running the following combination:
- A simple Qt app running using EGLFS (source here)
- Something that plays a long wav file.
Both of these elements seem to be required for the crash.
This is reproducable on stock raspbian (2018-04-18).
We did our own build of Qt to use eglfs and libinput, but it's build from stock qt 5.10.0. We carry one small patch to qt, but have reproduced the crash without it.
Here are the kernel error messages we have seen. (closest to stock raspbian/qt first):
The following are the minimum steps to reproduce, that we have so far:
# (connected to wifi and enabled ssh, and switched audio to Analog output).
sudo apt-get update
sudo apt-get install libts-0.0-0 tsconf
# This is build from Stock QT 5.10.0:
wget http://dev.kano.me/temp/kernel_crash_repr/libqt5all_5.10-1_armhf.deb
# This is a very simple Qt app:
wget http://dev.kano.me/temp/kernel_crash_repr/qmlmatrix_1.0-1.20170815_all.deb
# A long wav file:
wget http://dev.kano.me/temp/kernel_crash_repr/chippytoon.wav
# Despite the name, this just contains some symlinks:
wget http://dev.kano.me/temp/kernel_crash_repr/kano-graphics-libs_4.0.0-0.20180530_all.deb
sudo dpkg -i qmlmatrix_1.0-1.20170815_all.deb libqt5all_5.10-1_armhf.deb kano-graphics-libs_4.0.0-0.20180530_all.deb
# a script to run the qt app repeatedly
cat <<END >>qtest
while true; do
qmlmatrix &
QPID=$!
sleep 240
kill $QPID
done
END
while true; do aplay chippytoon.wav ; done &
. ./qtest
The result is one of the following:
- A kernel crash, with varying output (see above). 25..50% of the time
- No kernel crash, but instead audio stops working (aplay sometimes starts to give errors,
aplay: pcm_write:2011: write error: Input/output error , sometimes continues oblivious). After this it needs a reboot to start working again.
- (Seen once, not on raspbian) The display siezes and the firmware stops responding to vcgencmd, but ssh still works
- (Seen once, on raspbian) The display siezes but firmware still responds to vcgencmd, and ssh still works.
This is using a 2.5A power supply, where the pi and a speaker are the only things powered by it. We do not see low voltage warnings in this setup.
It is not clear to us whether the kernel or firmware is at fault.
Please let us know if there are other logs or traces we could enable which would help diagnose this.
We have a patch to our app that seems to prevent the problem, but we have a fair few qt apps, so we'd like to persue this, to be sure that the others aren't vulnerable at some lower probability.
[1]
CONFIG_DEBUG_INFO=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_FRAME_POINTER=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_KDB=y
CONFIG_KDB_KEYBOARD=y
We are seeing kernel 'Oopses', while running the following combination:
Both of these elements seem to be required for the crash.
This is reproducable on stock raspbian (2018-04-18).
We did our own build of Qt to use eglfs and libinput, but it's build from stock qt 5.10.0. We carry one small patch to qt, but have reproduced the crash without it.
Here are the kernel error messages we have seen. (closest to stock raspbian/qt first):
Captured over serial, vanilla qt and kernel: https://gist.github.com/Ealdwulf/1dcaa867199fa59c921673479ef30fe1
Captured over serial, patched qt: https://gist.github.com/Ealdwulf/2bb0beb46085b8b61501864b470265de
Captured over ssh, patched qt: https://gist.github.com/Ealdwulf/d26ae24f059e37acda58ef384bce9c27
Captured over serial, patched qt, kernel 4.14.50 rebuilt with more debug options[1]: https://gist.github.com/wizofe/469d8c4f092e5ae7d9adc9147f83e167
The following are the minimum steps to reproduce, that we have so far:
The result is one of the following:
aplay: pcm_write:2011: write error: Input/output error, sometimes continues oblivious). After this it needs a reboot to start working again.This is using a 2.5A power supply, where the pi and a speaker are the only things powered by it. We do not see low voltage warnings in this setup.
It is not clear to us whether the kernel or firmware is at fault.
Please let us know if there are other logs or traces we could enable which would help diagnose this.
We have a patch to our app that seems to prevent the problem, but we have a fair few qt apps, so we'd like to persue this, to be sure that the others aren't vulnerable at some lower probability.
[1]
CONFIG_DEBUG_INFO=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_FRAME_POINTER=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_KDB=y
CONFIG_KDB_KEYBOARD=y