Boa tarde,
Desde que adquiri meu Acer Nitro V15 (13th Gen Intel® Core™ i7-13620H, originalmente com 16 GB DDR5 e atualmente com 32 GB DDR5), venho enfrentando problemas recorrentes de estabilidade. Reconheço que utilizo um setup avançado, composto por GNU/Linux (Debian 13), Wayland, Hyprland e, inicialmente, drivers proprietários da NVIDIA, o que naturalmente foge do cenário oficialmente homologado. Ainda assim, os sintomas observados apontam para um problema mais profundo.
Os erros manifestavam-se inicialmente como kernel panics espontâneos, ocorrendo principalmente após longos períodos de ociosidade do sistema. Após diversos ajustes e testes, consegui mitigar parcialmente o problema, reduzindo-o a congelamentos apenas durante eventos de suspend/resume (por exemplo, ao fechar a tampa do notebook).
Contudo, após um processo de investigação mais detalhado, cheguei à conclusão de que a origem do problema não está diretamente no sistema operacional ou nos drivers gráficos, mas sim em comportamentos inconsistentes do Embedded Controller (EC).
Essa conclusão foi sustentada por dois pilares principais:
- Histórico de atualizações de BIOS da própria ACER, que demonstra sucessivas correções relacionadas ao EC. A versão 1.31, atualmente instalada em meu equipamento, inclusive menciona explicitamente ajustes nesse componente.
- Análise direta das tabelas ACPI, obtidas por meio de ferramentas como
acpidump e acpica-tools, seguidas de descompilação via iasl. Ao examinar as tabelas DSDT e SSDT resultantes, identifiquei diversos trechos potencialmente problemáticos.
Um exemplo particularmente sensível envolve o controle direto da GPU dedicada pelo EC, conforme ilustrado no trecho abaixo (extraído da DSDT):
If ((DGPV == 0x10DE)){ Acquire (PPCF, 0xFFFF) If ((VRDY == 0xAA)) { If ((DGDX != Zero)) { Notify (^^^PEG0.PEGP, Local1) } Else { Notify (^^^PEG0.PEGP, 0xD1) } } Release (PPCF)}
Esse código é executado em resposta a eventos _Qxx, que são disparados diretamente por interrupções do Embedded Controller. Esse tipo de notificação assíncrona pode ocorrer enquanto o driver da GPU (especialmente o proprietário da NVIDIA) se encontra em estados intermediários de energia ou inicialização, o que cria um cenário propenso a condições de corrida e inconsistências de estado.
Embora esse seja um dos trechos mais críticos, há outros pontos na implementação ACPI que seguem o mesmo padrão e podem contribuir para os problemas observados.
Tenho plena consciência de que este relato possui um nível técnico elevado e que talvez não seja o canal mais adequado para uma análise aprofundada. Ainda assim, considero importante que a equipe de engenharia da ACER tenha ciência desse comportamento, pois ele pode afetar outros usuários em cenários semelhantes — inclusive em sistemas operacionais diferentes, dependendo da forma como o firmware interage com o hardware.
Desde já, agradeço a atenção e coloco-me à disposição para fornecer logs, dumps ACPI ou quaisquer outras informações que possam auxiliar na investigação.
Atenciosamente,
