Identifica elemento solicitando chip de som para dormir

2

Desde alguns meses, o som de repente parou no meu laptop depois de algum tempo. Meu computador é um Toshiba Satellite L755 com um chip de som Conexant CX20585, executando o Ubuntu 17.04.

Descobri que isso é causado pelo chip de som ser colocado no modo sleep, como explicado aqui .

Quando o som está funcionando, a leitura de /proc/asound/card0/codec\#0 mostra:

Codec: Conexant CX20585
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x14f15069
Subsystem Id: 0x1179fc50
Revision Id: 0x100302
[...]
Node 0x1f [Pin Complex] wcaps 0x400501: Stereo
  Pincap 0x00000010: OUT
  Pin Default 0x92170110: [Fixed] Speaker at Int Front
    Conn = Analog, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Power states:  D0 D1 D2 D3 D3cold EPSS
  Power: setting=D0, actual=D0

E quando o som não está funcionando, mostra:

Node 0x1f [Pin Complex] wcaps 0x400501: Stereo
  Pincap 0x00000010: OUT
  Pin Default 0x92170110: [Fixed] Speaker at Int Front
    Conn = Analog, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Power states:  D0 D1 D2 D3 D3cold EPSS
  Power: setting=D3, actual=D3

O nó 0x1f sendo definido no estado de energia D3 é, portanto, o problema. Como descobri no link anterior, posso colocá-lo de volta no estado de energia D0 com o comando sudo hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0 . O som está de volta, mas apenas por alguns minutos.

O rastreamento dos eventos hda com echo 1 > /sys/kernel/debug/tracing/events/hda/enable mostra que nenhum evento hda é enviado pelo driver de som quando o som é cortado:

cat /sys/kernel/debug/tracing/trace 
# tracer: nop
#
# entries-in-buffer/entries-written: 20/20   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
 alsa-sink-CX205-2584  [001] d...   240.469929: snd_hdac_stream_stop: stream_tag: 5
        hda-verb-3617  [003] ....   257.329599: hda_send_cmd: [0000:00:1b.0:0] val=0x01f70500
        hda-verb-3617  [003] ....   257.329672: hda_get_response: [0000:00:1b.0:0] val=0x00000000
 alsa-sink-CX205-2584  [001] ....   279.844834: hda_send_cmd: [0000:00:1b.0:0] val=0x010a0000
 alsa-sink-CX205-2584  [001] ....   279.844888: hda_get_response: [0000:00:1b.0:0] val=0x00004011
 alsa-sink-CX205-2584  [001] ....   279.855672: hda_send_cmd: [0000:00:1b.0:0] val=0x01020011
 alsa-sink-CX205-2584  [001] ....   279.855722: hda_get_response: [0000:00:1b.0:0] val=0x00000000
 alsa-sink-CX205-2584  [001] ....   279.855725: hda_send_cmd: [0000:00:1b.0:0] val=0x011a0000
 alsa-sink-CX205-2584  [001] ....   279.855758: hda_get_response: [0000:00:1b.0:0] val=0x00004011
 alsa-sink-CX205-2584  [001] ....   279.867648: hda_send_cmd: [0000:00:1b.0:0] val=0x01120011
 alsa-sink-CX205-2584  [001] ....   279.867701: hda_get_response: [0000:00:1b.0:0] val=0x00000000
 alsa-sink-CX205-2584  [001] d...   279.867829: snd_hdac_stream_start: stream_tag: 5
 alsa-sink-CX205-2584  [001] d...   297.821668: snd_hdac_stream_stop: stream_tag: 5
[Set sound on with hda-verb]
        hda-verb-3649  [002] ....   300.602038: hda_send_cmd: [0000:00:1b.0:0] val=0x01f70500
        hda-verb-3649  [002] ....   300.602087: hda_get_response: [0000:00:1b.0:0] val=0x00000000
[Start/stop a Youtube video]
 alsa-sink-CX205-2584  [001] d...   312.264676: snd_hdac_stream_start: stream_tag: 5
 alsa-sink-CX205-2584  [001] d...   376.447668: snd_hdac_stream_stop: stream_tag: 5
 alsa-sink-CX205-2584  [001] d...   389.212522: snd_hdac_stream_start: stream_tag: 5
 alsa-sink-CX205-2584  [001] d...   405.072648: snd_hdac_stream_stop: stream_tag: 5
 alsa-sink-CX205-2584  [001] d...   410.938035: snd_hdac_stream_start: stream_tag: 5
[Sound cuts]

Eu tentei inicializar com a opção de kernel "acpi=off" para verificar se a ACPI tinha um papel nessa questão, como este bug sugeriu que isso pode ser causado por um gerenciamento de energia excessivamente agressivo. Mas o som ainda corta depois de algum tempo sem ACPI.

O chip de som é, portanto, colocado em suspensão por outro elemento que não consigo localizar, apenas alterando o estado de energia de um pino. Alguma ideia de como eu poderia identificá-lo? Poderia ser o BIOS?

    
por dohseven 07.05.2017 / 21:36

1 resposta

2

Isso ocorre porque o chip de som superaquece.

Uma correção de hardware apropriada conectaria um pequeno dissipador de calor ao chip de som.

Existe um puxão de software para o chip que atrasa o superaquecimento. Coloquei o comando no /etc/rc.local do Toshiba Satellite da minha irmã. Vou ter que contatá-la para obter o comando, pois não me lembro da memória. Vou atualizar essa resposta assim que tiver os detalhes.

Atualização:

# turn on power management for audio codec
# to solve loosing sound after a few minutes
echo "1" > /sys/module/snd_hda_intel/parameters/power_save
    
por heynnema 07.05.2017 / 23:46