Estado D


[Home] [Dissertação] [Biba] [Linux] [Conjugue] [br.ispell] [axw3] [uplink]

As this page has been accessed by guys that cannot read portuguese, I'm adding an english note.

State D means uninterruptible sleep.

Yes, you cannot kill a process in uninterruptible sleep. If you could do that, it would not be "uninterruptible". Such sleeps use to be the wait for an event (that may never occur).

If you're a programmer, you know that it's not easy to write code able to recover from traps. First of all, it must discover that it's in a trap. Then, it must carefully exit from that state, without compromise the system integrity.

It seems that a bug in some Linux kernels 2.0.3x causes deadlocks that put processes in state D. For each proccess the load is increased by 1, and after a while the load average may reach 10, 20 or 30. As a consequence, some softwares stop working (like sendmail, that refuses connections when the load reported by the kernel is too high, as configured on sendmail.cf).

The solution? upgrade. It seems that the bug remains on 2.0.36, at least for some controllers.

Estado D significa "uninterruptible sleep". Nao sei a que se
refere o "uninterruptible". Esse termo aplica-se a trechos de
codigo que necessitam ser executados do inicio ao fim sem
interrupcoes, em geral para evitar corrupcao em estruturas de
dados compartilhadas, mas nao sei se e' esse o caso.

Um processo que esta' aguardando a resposta de um device (por
exemplo uma leitura do disco) e' colocado em "D". Apos algumas
tentativas pode-se fotografar um processo em "D":

  # (ps&);mount -t msdos /dev/fd0 /mnt
    PID TTY STAT  TIME COMMAND
     45 v01 S     0:00 -bash
    143 v01 R     0:00 ps
    144 v01 D     0:00 mount -t msdos /dev/fd0 /mnt

O fato do seu mount nao se completar significa que a operacao de
i/o esta' pendente. Voce pode tentar verificar nas mensagens do
kernel (use dmesg ou veja o syslog) se o linux esta' aguardando a
interrupcao do driver mitsumi ou se esta' fazendo novas
solicitacoes. Atraves do /proc/interrupts voce pode saber se o
mitsumi gerou alguma interrupcao durante esse periodo.

Quando voce mata o mount, o kernel precisa decidir o que fazer
quando o system call feito pelo mount quiser retornar (apos
receber a resposta do mitsumi ou desistir), pois o processo
solicitante nao existira' mais. Eu conjecturo que o kernel
interrompa o pai e acerte os ponteiros para que ao termino do
call ele retorne para o pai, reativando-o (por isso o seu estado
torna-se "D").

No seu caso infelizmente o call nao retorna, por isso o shell
permanece interrompido. O razoavel seria que apos um timeout o
sistema desistisse de esperar a resposta do hardware e fizesse o
call retornar indicando uma condicao de erro. Eu nao estou
sugerindo fazer isso, em todo caso voce pode descobrir qual call
esta' pendente executando o mount com o strace:

  # strace mount -t iso9660 /dev/? /cdrom

O strace pode eventualmente nao estar instalado na sua
maquina. Se voce usa slackware, ele e' um pacote `a parte da
serie D. Um abraco,

Ricardo Ueda.