[alsa-devel] snd_hda_intel locking up on VIA CX700M2 with VT1708A codec
Hello,
I'm trying to work out what's going wrong with the HDA controller in our VIA CX700M2 board; there's a full bug report at https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3910, but briefly, I'm seeing it lock up and refuse to DMA after long enough transferring audio data.
Does anyone have any ideas that would help me track down this lockup and find a workaround?
Simon Farnsworth wrote:
Hello,
I'm trying to work out what's going wrong with the HDA controller in our VIA CX700M2 board; there's a full bug report at https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3910, but briefly, I'm seeing it lock up and refuse to DMA after long enough transferring audio data.
Following up on myself; the last command sent to the codec is always 0x014f000a in my testing. Is it likely that the digital output (node 0x14) is causing problems (it's not wired to anything)?
Simon Farnsworth wrote:
Simon Farnsworth wrote:
Hello,
I'm trying to work out what's going wrong with the HDA controller in our VIA CX700M2 board; there's a full bug report at https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3910, but briefly, I'm seeing it lock up and refuse to DMA after long enough transferring audio data.
Following up on myself; the last command sent to the codec is always 0x014f000a in my testing. Is it likely that the digital output (node 0x14) is causing problems (it's not wired to anything)?
I've manually crippled the code that enables the digital output (commented out the following lines in patch_via.c at line 846 ish):
if (spec->autocfg.dig_out_pin) spec->multiout.dig_out_nid = VT1708_DIGOUT_NID; if (spec->autocfg.dig_in_pin) spec->dig_in_nid = VT1708_DIGIN_NID;
This hasn't helped, beyond removing the last_cmd message from dmesg. Back to the drawing board for me.
participants (1)
-
Simon Farnsworth