Suspensão completa do sistema em umount e 'ls / dev / sd *'

Question

Eu tenho um disco rígido portátil que montei em /mnt/ext . Normalmente funciona bem. Mas se eu deixá-lo montado sem atividade por tempo suficiente, isso pode fazer com que o meu sistema fique completamente travado. Isso aconteceu duas vezes até agora. Nenhum movimento do mouse, o relógio não atualiza, ctrl-alt-f1 não funciona. (Eu não tenho uma chave sysrq para tentar usar o sistema mágico.) Quando saí de casa hoje de manhã, já era assim há mais de dez minutos; última vez eu reiniciei depois de provavelmente cinco minutos ou mais. (Atualização: ainda estava congelado quando cheguei em casa depois de quase dez horas.)

Da última vez, tenho certeza de que o problema aconteceu quando eu corri ls /dev/sd* (ou possivelmente com -l ). Isso parece muito estranho para mim, então é possível que eu esteja me esquecendo. Esta manhã eu corri ls /dev/sd* e ele não travou, mas parou quando eu corri umount /mnt/ext . Na verdade, a primeira vez que tentei desmontar, reclamou que o dispositivo estava ocupado; Eu parei o shell que estava dentro de cdd, tentei desmontar novamente, e depois desliguei. Em ambos os casos, o comando em execução não foi executado até a conclusão (não recebi outro prompt de shell) ou produziu qualquer saída.

Este é um laptop relativamente novo, mas antigo disco rígido. Eu não tive esse problema no meu laptop antigo com o mesmo disco rígido. Eu não me lembro de estar nesta situação com o novo laptop e ele não está quebrando, mas isso não significa necessariamente que eu não tenha sido. Eu não tentei outros discos rígidos.

O disco rígido reduz alguns minutos de inatividade, mas leva mais tempo do que esse problema para entrar em ação. Não me lembro de testar períodos entre "algumas horas" e "alguns dias".

Estou usando o genkernel do gentoo, não me lembro qual versão, mas só instalei há alguns meses.

Esta parece ser a seção relevante dos meus registros do sistema: link . 08:44 é quando meu sistema congelou; a próxima entrada é de 18:26, quando eu iniciei novamente.

    

Answer 1

Isso parece muito com falha de disco. Quando um disco rígido começa a falhar ou contém blocos ilegíveis (ruins), tentar ler a partir dele às vezes leva a um problema sério. No caso de blocos ruins, é sempre que um arquivo que inclui esses blocos é lido.

O problema sério é que a E / S de hardware é ininterrupta por razões técnicas, o que significa que, se esse hardware for quebrado, as leituras dele podem resultar no processo de chamada entrando em um "sono ininterrupto", ¹ e isso bloqueia o kernel, e é por isso que o seu sistema congela.

Você deve encontrar evidências disso nos registros do sistema.

Se o problema for simplesmente blocos defeituosos, você poderá consertá-lo, pelo menos temporariamente, executando e2fsck -cy nas partições (veja a página man sobre esses switches). Como isso requer leitura do disco, ele causará o mesmo travamento em certos pontos, portanto, talvez seja necessário deixá-lo funcionando por um longo período (possivelmente, horas ou durante a noite). Esta não é uma solução garantida, mas funcionará para alguns problemas. Se você achar que ainda está funcionando de manhã, eu desistiria - o problema é possivelmente mais sério do que apenas blocos ruins aleatórios.

Outra possibilidade, desde que seus logs dos erros de I / O começam com usb 5-1: USB disconnect, device number 3 é que algo errado está acontecendo com os drivers USB do kernel; isso seria consistente com o problema que começa especificamente no novo laptop. Parece semelhante a este problema , que aparentemente foi corrigido pela remoção do suporte ehci do kernel; se isso é modular, você poderia tentar isso colocando o módulo na lista negra ou temporariamente removendo-o de /lib/modules ; o módulo é ehci-hcd (em seguida, execute depmod e reinicialize). Você também pode querer consultar este e considerar se seu kernel está mal configurado. Eu não acho que funcionaria com um driver OHCI no lugar de um UHCI ou vice-versa, mas eu não sei, e o mesmo vale para a diferença entre o EHCI e o novo XHCI. Descubra exatamente o que é seu hardware (isso pode não ser fácil, você provavelmente terá que fazer referência à folha de especificações do fabricante para o laptop, procurar o controlador usb) e quais drivers de kernel estão sendo executados e procurar por bugs nesses drivers para sua versão do kernel.

^{1. Elas aparecem em top e ps output com um estado D .}