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

[Enrico Mioso]

thank you very much.
Unfortunately crashes on that machine are a little bit problematic now.
In case I get to render them less problematic, I'll let you know, even if I really don't know how things may go.

In case, I may try to set up a kdump or photograph the screen.
Thank you again, and sorry for the "inconcludence"....
Enrico


Enrico Mioso
Mobile Phone Number: +393807096934 ( +Telegram :) )
My Tox ID is: 7C593F402A3C8632D87AB4B948D492294C39A6A614464ECF843CA3429FB023284180472C7475

I like / recommend usage of open messaging standards when possible.

On Thu, 1 Dec 2016, Takashi Iwai wrote:

> Date: Thu, 1 Dec 2016 14:57:58
> 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 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
>