[qubes-users] Re: Fwd: Audio not working: "snd_hda_intel: No response from codec, resetting bus"

2020-08-24 Thread 54th Parallel
On Monday, 27 July 2020 at 23:52:20 UTC+8 fiftyfour...@gmail.com wrote:

>
> Hi Claudia,
>
> I'm suffering from the same problem as you, and 'dmesg | grep -i 
> snd_hda_intel' brought me to this thread. 
>
> My sound was originally working fine after I updated dom0 and domus 
> (tested via Youtube) but somewhere along the line something broke and the 
> next time I did the same thing, no sound. I did everything in my 
> non-technical power but it's dead, bub. No idea what caused it.
>
> dmesg output in short:
>
> snd_hda_intel [Audio device PCI code thing]: azx_get_response timeout, 
> switching to polling mode: last cmd=0xX
>
> snd_hda_intel [Audio device PCI code thing]: No response from codec, 
> resetting bus: last cmd=0xX(this line keeps repeating)
>
> snd_hda_intel [Audio device PCI code thing]: azx_get_response timeout, 
> switching to single_cmd mode: last cmd=0xX
>
> snd_hda_codec_realtek hdaudioC0D0: Unable to sync to register 0xXXX. -5
> snd_hda_codc_hdmi hdaudioC0D2: HDMI: invalid ELD buf size   (note I'm not 
> using HDMI)
>

Update for the benefit thread readers:

On Dell Inspiron 5593, updating dom0 to kernel 5.7 solved the audio problem 
(audio starts unreliably after boot--sometimes it works tens of minutes or 
hours after boot, making it hard to narrow down which actions caused it to 
start, if any did), but left hibernation and suspension inoperable.  On the 
current kernel (4.19) the problem for some reason seems to have solved 
itself. Maybe it's because I don't use audio on that machine near boot 
(unless for testing).

Oh, and this is important to those who value their hearing--keeping your 
headphones plugged into the headphone jack when booting on 4.19 leads to 
loud screeching noises resembling the death throes of autistic parrots 
suffocating on helium. The sound is apparently correlated with CPU use. Not 
sure what's going on there,  but my guess is the kernel confused the output 
with some other channel or there's some leaking somewhere.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/27605dfc-f4be-4619-8c5e-0193f3006bd0n%40googlegroups.com.


[qubes-users] Re: Fwd: Audio not working: "snd_hda_intel: No response from codec, resetting bus"

2020-07-27 Thread fiftyfourthparallel


On Monday, 16 December 2019 01:11:25 UTC+8, Claudia wrote:
>
> Claudia: 
> > [...] 
> > So, to recap what I've found so far: 
> > Fedora 25 live cd: works 
> > Qubes without Xen: works 
> > Qubes with Xen: codec probe error 
> > Qubes with Xen, VT-x & VT-d disabled: codec probe error 
> > Qubes with Xen, single_cmd=1: codec detected, but no sound 
> > 
> > [...] 
>
> Just following up. Audio works flawlessly out of the box in 
> R4.1-20181013 with kernel 4.19.76-1. Didn't work in R4.0.2 with 4.19 or 
> even 5.0 kernels even after days of tinkering with it. So it could be 
> due to the Xen version (4.8 -> 4.12), Fedora userland version (25 -> 
> 29), or changes to qubes-specific code/config (4.0 -> 4.1). I was hoping 
> to get it working in stable, but I'll probably just keep using 4.1 for 
> now. 
>
> - 
> This free account was provided by VFEmail.net - report spam to 
> ab...@vfemail.net  
>   
> ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of 
> the NSA's hands! 
> $24.95 ONETIME Lifetime accounts with Privacy Features!   
> 15GB disk! No bandwidth quotas! 
> Commercial and Bulk Mail Options!   
>

Hi Claudia,

I'm suffering from the same problem as you, and 'dmesg | grep -i 
snd_hda_intel' brought me to this thread. 

My sound was originally working fine after I updated dom0 and domus (tested 
via Youtube) but somewhere along the line something broke and the next time 
I did the same thing, no sound. I did everything in my non-technical power 
but it's dead, bub. No idea what caused it.

dmesg output in short:

snd_hda_intel [Audio device PCI code thing]: azx_get_response timeout, 
switching to polling mode: last cmd=0xX

snd_hda_intel [Audio device PCI code thing]: No response from codec, 
resetting bus: last cmd=0xX(this line keeps repeating)

snd_hda_intel [Audio device PCI code thing]: azx_get_response timeout, 
switching to single_cmd mode: last cmd=0xX

snd_hda_codec_realtek hdaudioC0D0: Unable to sync to register 0xXXX. -5
snd_hda_codc_hdmi hdaudioC0D2: HDMI: invalid ELD buf size   (note I'm not 
using HDMI)


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ab53b185-c661-4493-bb16-8a126fed1b99o%40googlegroups.com.


[qubes-users] Re: Fwd: Audio not working: "snd_hda_intel: No response from codec, resetting bus"

2019-12-15 Thread Claudia

Claudia:

[...]
So, to recap what I've found so far:
Fedora 25 live cd: works
Qubes without Xen: works
Qubes with Xen: codec probe error
Qubes with Xen, VT-x & VT-d disabled: codec probe error
Qubes with Xen, single_cmd=1: codec detected, but no sound

[...]


Just following up. Audio works flawlessly out of the box in 
R4.1-20181013 with kernel 4.19.76-1. Didn't work in R4.0.2 with 4.19 or 
even 5.0 kernels even after days of tinkering with it. So it could be 
due to the Xen version (4.8 -> 4.12), Fedora userland version (25 -> 
29), or changes to qubes-specific code/config (4.0 -> 4.1). I was hoping 
to get it working in stable, but I'll probably just keep using 4.1 for now.


-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/11cbb4e3-25fb-f795-ebdf-f049b9ff3d1c%40vfemail.net.


[qubes-users] Re: Fwd: Audio not working: "snd_hda_intel: No response from codec, resetting bus"

2019-11-24 Thread Claudia

Claudia:

(cc xen-users; see original message below)

So I was able to boot Qubes as a regular kernel, without Xen, and the 
codec is properly detected as Realtek ALC3234. Same exact kernel, same 
commandline, same userspace, just without Xen. (Xen 4.8.5-11.fc25)


Any ideas on what might be causing this, or how to debug further?

Here's some useful information I found on snd_hda_intel:
https://help.ubuntu.com/community/HdaIntelSoundHowto#Playing_with_probe_mask 

https://www.kernel.org/doc/html/v4.18/sound/hd-audio/notes.html#codec-probing-problem 

https://www.kernel.org/doc/html/v4.18/sound/alsa-configuration.html#module-snd-hda-intel 



Note: I found a *lot* of info telling me to set the model= parameter, 
however the documentation states that model is specific to the codec 
driver, e.g. snd_hda_intel_realtek. The problem here is that 
snd_hda_intel cannot even detect the make/model of the codec chip, and 
thus the realtek driver doesn't even get loaded under Xen. Just in case, 
I tried several model= options, including model=auto, and none of them 
had any effect.


 Forwarded Message 
Subject: Audio not working: "snd_hda_intel: No response from codec, 
resetting bus"

Date: Wed, 13 Nov 2019 19:11:55 +
From: Claudia 
To: qubes-users 

Audio works fine in Fedora 25-1.3 livecd and codec is detected as 
"ALC3234 Analog", alsa version k4.8.6-300.fc25.x86_64. It also works in 
F30.


On Qubes 4.0.2-rc2, I can't get audio to work at all. Codec shows up as 
"Generic Analog" in `aplay -l`, in alsamixer chip (codec) is "Generic 
 Generic", and kernel logs show


snd_hda_intel :03:00.1: no codecs initialized
snd_hda_intel :03:00.6: azx_get_response timeout, switching to 
polling mode: last cmd=0x000f
snd_hda_intel :03:00.6: No response from codec, disabling MSI: last 
cmd=0x000f

snd_hda_intel :03:00.6: Codec #0 probe error; disabling it...
snd_hda_intel :03:00.6: No response from codec, resetting bus: last 
cmd=0x000f


... followed by a stack trace.

:03:00.6 is the speaker/headphone interface, and .1 is HDMI. I'm not 
concerned with HDMI at the moment.


I get a variety of different errors from aplay in dom0, or it just hangs 
indefinitely; it seems random. And I obviously can't hear anything 
playing in VMs.


ALSA version is k4.19.81-1.pvops.qubes.x86_64

I tried playing around with some modprobe options, such as probe_mask=1, 
probe_mask=8, model=auto, and index=1, but none of them get rid of the 
errors or cause the codec to be detected as anything other than "Generic 
Analog".


I get the same result when booting Qubes with VT-x and VT-d disabled. I 
also tried booting the Qubes installer, but it appears the installer 
doesn't attempt to load any sound drivers (no success or failure 
messages) and it doesn't appear to have alsa-utils.


Any idea why audio would work in Fedora 25 with 4.8.6, but not Qubes 
R4.0.2 with 4.18.81?


As a workaround, I was able to get Xen to detect the codec and get rid 
of the error by using single_cmd=1. However the snd_hda_intel 
documentation warns that single_cmd is meant for debugging purposes only 
and is generally not recommended.


However, even with the error gone and the codec driver loading now, I 
still can't get any sound in Xen, even after reordering the cards, 
disabling the HDMI card, trying various model= options, disabling power 
save, and trying speaker-test with pulseaudio disabled. At best I get a 
quiet static from headphones, and can hear a slight pop when the channel 
is unmuted. Additionally, speaker-test and aplay occasionally seem to 
hang indefinitely, as if the device is blocking, but not always. Audio 
works fine using the same configuration when booted without Xen.


So, to recap what I've found so far:
Fedora 25 live cd: works
Qubes without Xen: works
Qubes with Xen: codec probe error
Qubes with Xen, VT-x & VT-d disabled: codec probe error
Qubes with Xen, single_cmd=1: codec detected, but no sound

I suppose I could try installing F25 with Xen and see if I get sound. 
But I'm pretty well convinced it's Xen (not Qubes) at this point.


I tried pci=noacpi but the keyboard wouldn't work, so I couldn't test 
sound. The console said something about "couldn't find IRQ ... please 
try using pci=biosirq". Exact same result when I replaced it with 
acpi=noirq. pci=biosirq had no effect as far as I could tell.


I don't know what else to try at the moment. Any ideas would be highly 
appreciated.


-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving