Kernel 6.6.y and DAC Allo Piano 2.1+Kali fails init #6527
Comments
|
The last working kernel version was 6.1.y. |
|
517 is EPROBEDEFER, which means "not yet" - the kernel will try again later. It's nice if drivers suppress those error messages as they can be confusing, but otherwise I don['t see anything wrong there. The stall is probably caused by something failing to release a mutex. Like most of the drivers we host in our kernel, we can't offer any support for them unless they reveal an underlying problem in the bits we do maintain. Our involvement consists of forward-porting the patches to new kernel versions, which is basically just a matter of getting them to compile again when the APIs change. Allo seems to be long gone - your best hope would be that one of the users out there has some coding experience. Even a relative novice could learn quite a bit about the problem by scattering a few pr_info() calls around the driver. |
|
Thank you for looking into this. Appreciated. Being a "novice" as you mention I can dive into the module, however will need a bit of guidance: mutex. What troubleshooting steps or actions would you suggest? |
|
Here's a rough plan of action:
|
|
Thank you for the steps. This round, the module was built against "stock" Pi kernel - 6.6.62-v7+ #1816 using cross-compiler. load dtoverlay -> http://paste.debian.net/1339146/ I would expect a bit more output at this time, however the test was on Pi 3B+, moving to Pi5 or CM5 to speed-up the native build work. |
|
Stock kernel: dmesg -l err,warn
There are no new messages from test other than |
|
Kernel from repo: dmesg -l err,warn
Same behaviour as before. |
|
Odd. Can you put another pr_err (any message you like) before the "return 0;" at the end of snd_allo_piano_dac_probe? That should confirm whether the driver initialisation is completing or not. |
|
Kernel with updated module: dmesg -l err,warn
Same behaviour as before. |
Result: https://paste.debian.net/hidden/0aaf8bb3/ Looks like it does. |
|
(I'll take your word that there is no change - you don't need to upload the logs each time) |
|
|
Nothing, just empty: |
It doesn't. |
This is getting interesting - https://paste.debian.net/hidden/168f11aa/ Purely boot only, nothing touched... yet. |
|
Well that's a bit of a relief - I was beginning to wonder how you could be getting so far if the probe() had never succeeded. |
The fact it is still deferred would be listed, just not what the dependency was. |
|
Honestly, I'm scratching my head for past two weeks, doubting my sanity with this. |
|
It seems unlikely, since it only provides a static configuration - by the time you've exited the probe function, the overlay plays no further part. |
|
To add to the confusion, when using basic overlay: allo-piano-dac-pcm512x-audio the DAC works with limited functionality. This bypasses all channels separation 2xPCM, lowpass, etc. |
|
Are you seeing any of my debug output when you use the controls? If not, which controls are available to you in this subset? |
|
I think I made my last remark confusing.
Will add debug params to |
|
The Comparing with working DAC on kernel 6.1.y, the node |
|
A simple test, forcing bogus return 0; from snd_allo_piano_dac_probe and it is clear that all the params are not available to alsa. There is literally nothing in dmesg nor journalctl to follow up on. Any ideas? |
|
Hey @pelwell, This is getting interesting. After adding #include <linux/i2c.h> all of the sudden: |
|
The output here (https://paste.debian.net/hidden/168f11aa/) showed it reaching the end of snd_allo_piano_dac_probe ("DAC issue #6527"), so why do you need to force it? And what changed between that run and the previous one (that produced much less output), other than the addition of the "DAC probe begin" message? |
|
The only differences at this point were:
|
|
Your log above shows the output from snd_allo_piano_dual_mode_put, turning dual_mode off. Do any other controls exist/work? |
|
The amixer is used to set specific hwdevice with params. However, module once loaded renders alsa completely unresponsive and console hungs. No other controls are available. The continuous message |
|
Well, the DAC init is stuck here, indefinite loop: I think without addressing this part, we can't progress further. |
|
In such case I will put my spyglass down, for a bit at least. |
|
One thing you can try quickly is removing the |
|
Rebuild module with? |
|
With above code commented out, the same deadlock: |
|
Oh - it defaults to being enabled. Either restore that code and use "dtoverlay=...,24db_digital_gain=off", or replace the commented out code with I have a patch I'm just about to push that may solve the problem, but this confirmation would be useful. |
Calling snd_soc_limit_volume from within a kcontrol put handler seems to cause a deadlock as it attempts to claim a write lock that is already held. Call snd_soc_limit_volume from the main initialisation code instead, to avoid the recursive locking. See: raspberrypi#6527 Signed-off-by: Phil Elwell <[email protected]>
Calling snd_soc_limit_volume from within a kcontrol put handler seems to cause a deadlock as it attempts to claim a write lock that is already held. Call snd_soc_limit_volume from the main initialisation code instead, to avoid the recursive locking. See: raspberrypi#6527 Signed-off-by: Phil Elwell <[email protected]>
|
See #6532. |
reverted comment and
|
Nice!. Do you have a spare thinking head that I can borrow? |
|
This one's showing signs of aging. I'm hoping that with the patch in the pull request that the digital gain limit will still work, but it will have to be verified. I'm not sure if the code was arranged as it was for good reasons or just carelessness. If you wait another half hour you'll be able to install a trial build with |
|
I am looking into future kernels too. The following suggest that references Lines 1154 to 1157 in 574ea34 When looking into the module code codes for kernel like 6.13.y it is already replaced there. As a suggestion - wouldn't now be an ideal time to future-proof module a bit? |
|
I'll bear that in mind. |
shows the changes needed when dragging downstream patches to newer kernels. It is a pain. |
|
Thank you for your above and beyond support. Building module for |
|
Internal testing confirmed that the patch works as expected. There is some extra "chatter" from module logged (-517), however this can be addressed at some point in future. |
Calling snd_soc_limit_volume from within a kcontrol put handler seems to cause a deadlock as it attempts to claim a write lock that is already held. Call snd_soc_limit_volume from the main initialisation code instead, to avoid the recursive locking. See: #6527 Signed-off-by: Phil Elwell <[email protected]>
Calling snd_soc_limit_volume from within a kcontrol put handler seems to cause a deadlock as it attempts to claim a write lock that is already held. Call snd_soc_limit_volume from the main initialisation code instead, to avoid the recursive locking. See: raspberrypi#6527 Signed-off-by: Phil Elwell <[email protected]>
|
Also, related to this #6534 |
Calling snd_soc_limit_volume from within a kcontrol put handler seems to cause a deadlock as it attempts to claim a write lock that is already held. Call snd_soc_limit_volume from the main initialisation code instead, to avoid the recursive locking. See: #6527 Signed-off-by: Phil Elwell <[email protected]>
Calling snd_soc_limit_volume from within a kcontrol put handler seems to cause a deadlock as it attempts to claim a write lock that is already held. Call snd_soc_limit_volume from the main initialisation code instead, to avoid the recursive locking. See: #6527 Signed-off-by: Phil Elwell <[email protected]>
Calling snd_soc_limit_volume from within a kcontrol put handler seems to cause a deadlock as it attempts to claim a write lock that is already held. Call snd_soc_limit_volume from the main initialisation code instead, to avoid the recursive locking. See: #6527 Signed-off-by: Phil Elwell <[email protected]>
|
Hey @pelwell, It seems that we have lost the control over Should we carry on here, or open a new issue? Kind Regards, |
|
You can leave it here. In what way have you lost the control? Is it stuck on or off? The variable |
|
Thank you for looking into this. If you can spare a bit of time, and take a look into the last week discussions in community thread. dmesg: |
Calling snd_soc_limit_volume from within a kcontrol put handler seems to cause a deadlock as it attempts to claim a write lock that is already held. Call snd_soc_limit_volume from the main initialisation code instead, to avoid the recursive locking. See: #6527 Signed-off-by: Phil Elwell <[email protected]>
Calling snd_soc_limit_volume from within a kcontrol put handler seems to cause a deadlock as it attempts to claim a write lock that is already held. Call snd_soc_limit_volume from the main initialisation code instead, to avoid the recursive locking. See: #6527 Signed-off-by: Phil Elwell <[email protected]>
Describe the bug
It seems that sound/soc/bcm/allo-piano-dac-plus.c is not parsing parameters for alsa use. What I can observe is that the dtoverlay partly fails register the card:
However module somewhat loads:
ls -la /sys/module/snd_soc_allo_piano_dac_plus/
Simple test with alsa-info shows that the expected DAC's control parameters are missing:
In addition, there seems to be a deadlock after module load preventing init level change.
Steps to reproduce the behaviour
Load overlay with config.txt:
Load manually:
sudo dtoveraly allo-piano-dac-plus-pcm512x-audioDevice (s)
Raspberry Pi 3 Mod. B+, Raspberry Pi 4 Mod. B, Raspberry Pi 400, Raspberry Pi 5, Raspberry Pi CM4, Raspberry Pi CM4 Lite, Other
System
cat /etc/rpi-issue
vcgencmd version
uname -a
Linux bookworm 6.6.62+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.62-1+rpt1 (2024-11-25) aarch64 GNU/LinuxLogs
dmesg shows continuously:
Additional context
No response
The text was updated successfully, but these errors were encountered: