Início / ubuntu / Perguntas / 1535560
Accepted
G.S.
Asked: 2024-12-15 12:40:28 +0800 CST

O desktop Ubuntu (Studio) 24.10 congela ao tentar sair do modo de espera/suspensão

  • 772

O Problema

Sempre que tento acordar o PC do modo de suspensão/suspensão, o sistema inicialmente parece responder, mas então a tela congela e não responde a nada que eu faço. Neste ponto, a única saída parece ser forçar o desligamento da máquina segurando o botão de energia por 5 segundos e, em seguida, reiniciando-a.

Isso ocorre independentemente de o sono ter sido acionado manualmente ou automaticamente após inatividade suficiente, e independentemente de a tentativa de despertar ter sido feita movendo o mouse, pressionando o teclado ou pressionando o botão de energia. Às vezes, ele traz visivelmente a tela de login novamente, mas às vezes (acho que se eu já estiver logado), ele mostra uma tela que é totalmente preta, exceto pelo cursor do mouse. Em qualquer caso, nem mover o mouse nem digitar no teclado produz qualquer resposta visível.

Sistema

Estou usando o Ubuntu Studio 24.10, mas se bem me lembro, o problema também se manifestava quando eu ainda estava na versão 24.04.x.

Meu hardware é o seguinte:

Placa-mãe: ASUS Z790 GAMING WIFI7
CPU: Intel Core i9-14900K (x86_64)
GPU: AMD Radeon RX 7900XT
Armazenamento: 8 TB SSD
RAM: 96 GB NVMe DDR5

Soluções que já tentei (sem sucesso)

  • Quando congelado, alternar para um TTY diferente usando Ctrl+ Alt+ F2– F6: Simplesmente não faz nada.
    • (Aliás, quando não estou congelado, Ctrlo + Alt+ F2em particular, em vez de me levar para uma nova sessão de shell, exibe uma tela totalmente preta com apenas um cursor do mouse, muito semelhante ao que às vezes vejo durante os congelamentos de ativação, exceto que posso mover o mouse, bem como retornar à sessão gráfica principal usando Ctrl+ Alt+ F1.)
  • Limitando o C-state máximo da CPU na configuração do GRUB: Eu tentei criar um novo arquivo em /etc/default/grub.d/ e adicionar a linha GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT intel_idle.max_cstate=1", então executar sudo update-grube reinicializar. Eu também tentei mudar o nome da variável para processor.max_cstatee o valor para 4. Nenhuma permutação dos passos acima mencionados parece fazer diferença no final.
  • Aumentando o espaço de swap: O tamanho de /swap.img já era 8 GB, mas eu o aumentei para 10 GB de acordo com o conselho que li afirmando que o arquivo de swap deveria ser a raiz quadrada da RAM total do sistema. Em retrospecto, não tenho certeza de que diferença eu esperava que isso fizesse em primeiro lugar.
  • Desabilitando o congelamento de sessão do systemd: Seguindo outros conselhos online, experimentei adicionar as seguintes variáveis ​​de ambiente para configuração do systemd 256+:
    • Criado /etc/systemd/system/systemd-suspend.service.d/freeze_fix.conf : 
      [Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"
    • Criado /etc/systemd/system/systemd- sleep .service.d/ como um link simbólico para /etc/systemd/system/systemd- suspend .service.d .
    • Criado /etc/systemd/system/systemd-homed.service.d/freeze_fix.conf : 
      [Service]
Environment="SYSTEMD_HOME_LOCK_FREEZE_SESSION=false"

(As pessoas que vi postando problemas semelhantes na internet no passado geralmente eram instruídas a verificar seus logs de sistema em /var/log/syslog e/ou a saída de journalctl(ou mais especificamente, journalctl -b -1). As versões iniciais desta postagem tinham os resultados desses logs do processo de suspensão colados abaixo, mas eu os removi porque eles continham apenas mensagens do processo de suspensão em si, e não do processo de ativação novamente, que é quando o problema real ocorre.)

suspend

1 respostas

  1. Best Answer

    Finalmente encontrei a fonte do problema! Acontece que, por algum motivo, o problema só ocorre para mim quando o Bluetooth está habilitado. Embora isso indique um problema mais profundo com a maneira como o systemd e minha placa de rede interagem entre si durante as rotinas de suspensão/suspensão, também revela uma solução alternativa muito simples: basta garantir que o Bluetooth esteja desabilitado sempre que a suspensão/suspensão for acionada.

    A maneira mais limpa de fazer isso era criar um pequeno serviço systemd que usa o rfkill para verificar se o Bluetooth está desbloqueado (ou seja, ligado) ou não e, se estiver, bloqueá-lo durante o período de suspensão/hibernação e, em seguida, desbloqueá-lo novamente quando o sistema for ativado.

    Criado o arquivo de unidade /etc/systemd/system/bt_workaround.service :

    [Unit]
Description=Bluetooth Workaround for Suspension
Before=sleep.target suspend.target hybrid-sleep.target suspend-then-hibernate.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecCondition=/usr/bin/env sh -c 'test "$(rfkill -no SOFT list bluetooth)" = unblocked'
ExecStart=/usr/bin/env rfkill block bluetooth
ExecStop=/usr/bin/env rfkill unblock bluetooth

[Install]
RequiredBy=sleep.target suspend.target hybrid-sleep.target suspend-then-hibernate.target

    Corri sudo systemctl daemon-reloadpara reconhecer o arquivo da unidade e sudo systemctl enable bt_workaroundcolocá-lo para funcionar.

    (Adaptado deste comentário do Reddit , com algumas melhorias minhas adicionadas.)

    • 1

relate perguntas