[alsa-devel] Intel HDA audio on EEE PC 1101HGo

[Takashi Iwai]

On Thu, 01 Dec 2016 14:50:30 +0100,
Enrico Mioso wrote:
> 
> On Thu, 1 Dec 2016, Takashi Iwai wrote:
> 
> > Date: Thu, 1 Dec 2016 11:12:25
> > From: Takashi Iwai <tiwai at suse.de>
> > To: Enrico Mioso <mrkiko.rs at gmail.com>
> > Cc: hui.wang at canonical.com, alsa-devel at alsa-project.org, kailang at realtek.com
> > Subject: Re: [alsa-devel] Intel HDA audio on EEE PC 1101HGo
> >
> > On Wed, 23 Nov 2016 09:19:07 +0100,
> > Enrico Mioso wrote:
> >>
> >> Hello guys.
> >> With the these last settings the system seems able to survive. However, I think I am a little bit drastic with these settings.
> >>
> >> here my hardware infos: I remember of being asked to send them as an attachment, so I'll do so.
> >> No upload has been made: when the script aked me, I choosen "Save locally". But there is an "upload=true" or something like that at the beginning.
> >
> > The single_cmd is really the last resort, and it already means that
> > something wrong in the codec/controller communication.
> >
> > What does actually crash and how is the exact symptom?  You seem to
> > always cut the citation, so I cannot remember the exact issue.
> > Please keep the normal ML style, no top-posting.
> >
> >
> > thanks,
> >
> > Takashi
> >
> 
> Sorry for the inconvenience. I usually did that because, when reading
> e-mails with a screen reader (e.g.: from my phone), having all the
> text preceeded by things like ">>" is a little bit unconfortable. But
> I understand this can be a problem, and ML worked this way since a
> long time I guess.
> 
> So I recap: my computyer identifies itself as:
> ASUSTeK Computer INC. 1101HAG/1101HAG, BIOS 0102    08/17/2009
> (it's an EEE PC and this message has been extracted from the dmesg, DMI data).
> 
> Once back, the HDA audio controller exhibited some strange behaviours,
> and in particular, audio wasn't routed the normal way when I plugged
> my headphones or unplugged them (so, if I din't wait for the
> controller to go in low-power mode, I could hear audio both form
> headphones and laptop speakers). Waiting instead, resulted in the
> controller working properly.
> You suggested me a method to report back some useful infos, but I
> didn't do that, sorry. (I posted a mail with those infos some day ago
> if I am not wrong.)
> 
> Then time passed,and I upgraded my kernel to the git version I
> reported in my previous mail, and now btw I am following current -git
> kernel with this system.
> I haven't noticed strange behaviours regarding audio routing, but it
> may well be due to lack of testing in this. But another strange thing
> started happening: in particular, kernel panics when an application
> tries to open the audio device (in my case it was Music Player Daemon,
> but also mplayer triggered it once).

The kernel panic is bad.  If you can get Oops message reliably, it'd
be helpful to catch the stack trace.  You can also set up kdump to
capture the crash.

> So I tried setting power_save_controller and power_save both to 0
> (yes, I know power_save_controller is a boolean)... I tried this
> without much reasoning if reasoning at all.

Note that many desktop environments adjust already the power-saving
stuff by themselves, so your setup would be overridden.

> No matter, I could still observe a panic (a single one I think).

Again, if you can get an Oops, try to catch the oops message.  This
would help analysis.

> So I tried with single mode: and I did so because I think the driver
> reverted to single cmd mode at some point on this device, in the past.
> Now the system doesn't panic anymore, still in my dmesg there are lots of messages like:
> snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x170a10

Well, I'm not going to debug it any longer, as this is about
single_cmd mode, and using single_cmd is only for the last-resort
debugging.  Any inconvenience is expected.

So, at best, let's try to catch the kernel oops at first.


thanks,

Takashi