[Bug]: Kernel panic on master v5.9 and others with 4mic Circular array #312
Comments
|
From the log you posted it looks like you have a USB device fadecandy which has stopped responding, and that in turn has caused the raspberry pi firmware to time out. Nothing to do with audio at all. You may need to review which part of your applications are using fadecandy, and perhaps contact the Adafruit people (who sell these, and presumably wrote the drivers too) for help. |
|
Yes, I saw that as well and did find it interesting. I'm sure there is an issue with the 4mic array driver though there may be some interplay with USB. I think what is happening there though is that something related to the seeed driver is dominating things in the kernel and causing a hose of other quasi-intensive low level resources to randomely fail sometimes. As long as I don't access the 4mic array though the system is stable on a week+ timescale. I've found it very hard to capture any sort of debugging data as generally the system becomes completely unresponsive and connections drop before I get any info in my tail of the journal. For example if I open paman, elect the multichannel input of the mic and try to show its levels pulse crashes instantly. If I try to open any of the various seed options with also in e.g. mumble the system dies, If I open the input in mumble via pulse pulse dies. One thought I've had but do not know how to test for: If the various programs are opening the mic with few than the 4 channels perhaps there is a buffer that is overflowing. One thought here would be do force pulse to properly open all of the channels (or only a single channel) and redirectly it to a null sink, then put a monitor on that and try opening that in an application. There are so many different devices that appear though I'm not even sure where to begin even if I was sure of what command to use. Some i2c timeouts:
Another kernel log I did get (related to the GPU perhaps, which seems odd):
And a pulse failure:
|
|
"I think what is happening there though is that something related to the seeed driver is dominating things in the kernel and causing a hose of other quasi-intensive low level resources to randomely fail sometimes." is issue #251 ! I thought it is disastrous on 64-bit kernel, didn't know it is observable on 32-bit kernel too.
And it certainly looks like it is the same section of code in ac10x_update_bits() as in #251 .
|
|
Sigh. Reading through these other tickets has me suspecting its time to invest in a different mic hat... I'm willing to offer some help debugging/and thinking, but I've just delivered the hardware to someone so I'm a bit limited for the moment. |
Describe the bug
I'm seeing kernel panics and improper operation arecord -L does seem to work, but using of the device via paman, Mumble, or other programs brings the system to a stop.
Expected behavior
Successfully use the microphone via pulse input in e.g. Audacity or Mumble.
Platform
Relevant log output
The text was updated successfully, but these errors were encountered: