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@xxxxxxx>
To: Enrico Mioso <mrkiko.rs@xxxxxxxxx>
Cc: hui.wang@xxxxxxxxxxxxx, alsa-devel@xxxxxxxxxxxxxxxx, kailang@xxxxxxxxxxx
Subject: Re: 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@xxxxxxx>
To: Enrico Mioso <mrkiko.rs@xxxxxxxxx>
Cc: hui.wang@xxxxxxxxxxxxx, alsa-devel@xxxxxxxxxxxxxxxx, kailang@xxxxxxxxxxx
Subject: Re: 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
