gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Uptime
Contribuído por scorpio em 26-05-01 22:17
do departamento quem-o-tem-maior?
Linux higuita escreve "Quem ja' nao viu/leu pessoal a gabar-se sobre os uptimes do linux?!
O autor deste artigo gostava de ter um alto uptime (498 dias) mas viu-se confrontado com o regresso a zero na sua maquina...
Acabou por descobrir a origem do problema, uma explicacao simples (o bug aplica-se aos 2.2.x, provavelmente tambem para os 2.4.x)
Pelo menos agora ja' se sabe quem esta' a mentir nos uptimes...
Tambem me faz lembrar o problema do windows 95 que encravava passados 35(?) dias... ambos demoraram uma eternidade para serem descobertos 8) "

Estados Policiais Unidos da Europa | Softwares livres administrativos para Linux  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • artigo
  • Mais acerca Linux
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Isso ja e conhecido a muito tempo... (Pontos:2, Informativo)
    por skinbits em 27-05-01 12:55 GMT (#1)
    (Utilizador Info)
    Esse problema que estas a falar nao e novo, nem nunca vai ser arranjado... Quando tiveres computadores de 64 bits passas de 1 ano e tal para bilioes de anos... O problema todo e que no kernel a um contador chamado jiffies que e actualizado cada vez que ha um timer (10ms). A maior parte dos drivers usam esse contador para fazer tempos de esperas e saber como e que esta a situação do hardware... Por isso, quando passam os tais 400 e tal dias, o jiffies volta a 0. E muitos drivers, muitos timers e contadores deixam de funcionar ate passar mais 400 e tal dias... :))
    No problem! (Pontos:2)
    por CrLf em 27-05-01 14:29 GMT (#2)
    (Utilizador Info) http://students.fct.unl.pt/~cer09566
    Errr, nada deixa de funcionar passados 400 e tal dias (tens máquinas com uptimes de 1000+ dias), simplesmente o valor retornado pelo uptime recomeça do zero outra vez. Além disso os drivers não usam o contador uptime, e o contador jiffies não é usado como comparação directa pelos drivers, há alguns truques para evitar o wraparound. Para saber mais ir aqui e procurar por "jiffies wraparound" ou "uptime wrap".

    -- Carlos Rodrigues

    - "I think my men can handle one little penguin!"
    - "No, Mr. Gates, your men are already dead!"
    Re:No problem! (Pontos:2, Esclarecedor)
    por skinbits em 27-05-01 19:39 GMT (#4)
    (Utilizador Info)
    Nao e bem assim: esta linha e do driver do SIS900(linha 873,kernel 2.4.4). Como estas ha outras:
    sis_priv->timer.expires = jiffies + HZ;
    Isto depende dos jiffies. Se ha o wraparound, este timer nunca mais funciona... Engracado nao e? :)
    Quotes (Pontos:2)
    por CrLf em 28-05-01 0:28 GMT (#5)
    (Utilizador Info) http://students.fct.unl.pt/~cer09566
    Como não estou com vontade de entrar numa análise profunda do funcionamento dos timers do linux deixo apenas dois copy-pastes:

    Um de Ingo Molnar:

    I've tested it once by setting jiffies to 0xFFFFF000 in main.c, and nothing bad happened. Some of the hardware timeouts are handled by using absolute jiffies values and comparing them with <, but these timers are usually for error detection. Important timings are done with kernel timers, and they are wraparound-insensitive :) And who needs timers with more than 400 days timeout :) [well ...]

    E outro do Linus Torvalds:

    On Tue, 20 Aug 1996, Mike Kilburn wrote:
    >
    > On Mon, 19 Aug 1996, mlord wrote:
    >
    > > The one that really worries me is having the "jiffies" wrap around,
    > > an event which will happen every 17 months or so on production systems.
    > >
    > > A *lot* of the kernel will malfunction when that happens.
    >
    > I would hope not. We always do diff = jiffies - oldtime; GCC handles
    > the wrap correctly (look at the asm output) if all are the same unsigned
    > type. What else could go wrong?

    In _many_ places we do the jiffies handling correctly. Not in every place, though (or even most places). So jiffies wrapping is potentially a real problem, although I do have one report that when the jiffies wrapped nothing bad happened (various minor things, but the machine didn't crash). (Oh, and it's not gcc handling the wrap correctly: it's the C language. The C language defines that unsigned arithmetic _has_ to work the way we want it to work, so you don't even need to look at the asm output).
    Linus


    Este problema foi bastante discutido (e encarado como um problema sério) na mailing-list do kernel antes do 2.2, por isso, na sua forma actual não acredito que seja um problema real, porque repito, existem muitas máquinas que já passaram pelo ponto de wraparound dos jiffies várias vezes e continuaram a funcionar (o maior uptime que já tive notícia foi de 1800+ dias o que dá uns 3 wraparounds).

    -- Carlos Rodrigues

    - "I think my men can handle one little penguin!"
    - "No, Mr. Gates, your men are already dead!"
    Re:Quotes (Pontos:1)
    por skinbits em 28-05-01 12:33 GMT (#6)
    (Utilizador Info)
    Os crashs depende dos drivers. Alguns drivers nao tem problemas com o warparound, outros depende dos timers para bom funcionamento, e quando ha o warparound, deixam de funcionar bem. Como o linus diz:


    Not in every place, though (or even most places). So jiffies wrapping is potentially a real problem,

    Alem disso, quem tem um computador com 1800 dias de uptime (quase 5 anos) tem um kernel 1.2, que deve ter muitos problemas de seguranca e que deve ser actualizado. E como ja e muito antigo, os problemas sao bem conhecidos.

    Este problema so se manifesta nestes casos...

    não só no linux... (Pontos:2, Informativo)
    por peyote em 27-05-01 17:24 GMT (#3)
    (Utilizador Info)
    segundo o netcraft, não só o linux, como também hp-ux, solaris e releases recentes de freebsd fazem reset ao timer de uptime passados 497 dias...


    peyote

    ---
    'God is as real as I am', the old man said. I was relieved since I knew Santa wouldn't lie to me...

     

     

    [ Topo | FAQ | Editores | Contacto ]