Ubuntu 24.04.2 LTS, Dell Inc. Latitude 7390, Intel® Core™ i5-8350U × 8 Este é um relatório e uma pergunta. Há pouco tempo, minha suspensão estava acordando. Tanto se eu simplesmente me afastasse e ele suspendesse automaticamente quanto se eu o colocasse em suspensão, ele não acordava. Minha pesquisa indicou que esse é um problema bastante comum e as atualizações do kernel geralmente são as culpadas. Então, reiniciei no último kernel, que é 6.8.0-52.53-genérico 6.8.12, e a suspensão começou a funcionar novamente. Minha pergunta é: isso é mais provável porque meu laptop é mais antigo? Ele tem cerca de 7 anos agora. Além disso, como devo abordar futuras atualizações do kernel? Alguma razão para não deixá-lo com o kernel 6.8? Obrigado a todos!
AskOverflow.Dev
Não, não tem relação. (para dar uma curiosidade, no meu trabalho anterior as pessoas não conseguiam fazer a placa de rede rodar em alguns computadores porque não havia drivers para Windows 7. A placa funcionava muito bem no Ubuntu moderno) .
Bem, isso é um bug, algum tipo de regressão.
Como usuário, se você não quiser se aprofundar nisso, você pode simplesmente evitar atualizar o kernel. Não é o ideal, mas funcionaria.
Se você tiver motivação e tempo livre, você pode tentar dar uma olhada. Primeiro, vale a pena testar o último kernel lançado, porque o 6.11 não é o único. A versão marcada como "estável" neste site é a mais recente. Então você pode tentar instalá-lo seguindo estas instruções e testar se funciona.
Então, se isso acontecer, você pode decidir novamente deixar seu sistema naquele kernel. Softwares mais novos são sempre melhores, o 6.13 (o mais recente no momento em que escrevo) tem tantas otimizações e recursos ! Se não funcionar, você pode relatar um bug no kernel bugzilla . O objetivo de testar o kernel mainline mais recente aqui é para que você possa relatar o upstream em vez do downstream (o downstream aqui é o "launchpad" do Ubuntu, e na minha experiência não é o melhor lugar para relatar bugs…) .
Nesse ponto, se você ainda estiver motivado, você pode tentar fazer git-bisect no kernel para ver qual commit introduziu o problema. Isso exigiria construir o kernel manualmente, então realmente requer alguma motivação da sua parte. Mas se você fizer isso, regressões com commits conhecidos geralmente são facilmente corrigidas, você apenas envia para a lista de discussão um e-mail dizendo "[REGRESSION][BISECTED] …" e descrevendo o bug e o resultado da bissecção, e adicionando ao CC o autor do commit ofensivo, bem como os mantenedores (os mantenedores e a lista de discussão podem ser encontrados executando
perl scripts/get_maintainer.pl -f path/to/problematic/source-code/filena árvore de origem) .