como determinar a origem de: um núcleo para estar em 100% e “congelar” a máquina?

Question

Às vezes, depois de ligar o PC, aleatoriamente, um dos 4 núcleos chega a 100% e a máquina "congela".

Bem, tenho htop em execução a partir de uma conexão remota e vejo que todos os processos ainda estão funcionando.

Uma coisa interessante que acontece é ex .: um vídeo do youtube continuará tocando seu áudio, mas a tela fica toda congelada, até o mouse não muda sua posição.

No topo da lista no htop, desta vez foi kworker com 100% de uso da CPU, mas outras vezes não houve processo em 100%. A CPU 1 (índice central 0) estava em 100%. Então, o núcleo 0 estava sendo usado ativamente por cerca de 10% e a barra restante era toda vermelha, preenchendo até 100%. Eu acho que o indicador de preenchimento vermelho é IO, certo?

Em seguida, a média de carga não para de aumentar.

Então, eu acho que isso está relacionado a algum tipo de IO, eu acho que o vídeo IO? Quais comandos eu poderia usar para testá-lo?

Nesse caso, não posso nem criar uma nova conexão remota, ela não aceita, apenas congelará a tentativa. Então, eu começarei esse comando em um loop e monitorarei sua saída sempre que o próximo congelamento acontecer.

    

Answer 1

Sim, provavelmente é vídeo io. Como há um kworker em 100%, há também um estouro de interrupção.

Interrupções são tratadas no linux em duas etapas: 1) o manipulador de interrupção direta coleta todos os dados de interrupção em uma fila temporária 2) os trabalhadores não estão trabalhando nos manipuladores de interrupção, mas como encadeamentos de kernel separados. Eles são essencialmente processos - mas sem um espaço de usuário, eles são executados inteiramente no kernel.

É assim, porque os manipuladores de interrupção ... interrompem. Isso pode acontecer a qualquer momento, ignorando quaisquer bloqueios, etc. Assim, eles devem fazer o menor número possível de manipulação complexa da estrutura de dados. O problema é semelhante, pois você pode chamar apenas algumas funções de um manipulador de sinal de espaço do usuário. Assim, eles coletam os dados interruot em uma fila e, em seguida, os trabalhadores processam essa fila, já fora do espaço do kernel.

Agora, o problema é que os chips de vídeo não interrompem demais, a tarefa dos drivers de vídeo é apenas configurar as configurações de vga e produzir um buffer mapeado para a tela. Eles não devem interromper muitos, mas apesar disso acontece muito.

O áudio do youtube não para porque é uma coisa multithread e seu segmento de processamento de áudio nem sequer sabe que o player de vídeo é enforcado.

O que está no seu dmesg?

Eu suspeito de hardware buggy vga ou um problema de driver.