 |
gildot |
 |
| |
| | Linux: histórias de horror | | |  | Contribuído por BladeRunner em 06-12-01 0:01
do departamento dr-jekill-and-mr-hide | |  | |  | | |  Astrónomo escreve "Não, não vos venho falar de horas passadas a tentar por um periférico a funcionar, a configurar o X num portátil ou de ficheiros que perdi por causa de um bug num Kernel recente.
Vou-vos relatar dois episódios reais de problemas que me aconteceram recentemente e que, ao contrário dos problemas do primeiro parágrafo, é menos frequente ouvir falar. | | | | | | História de horror 1: O mount fatal
Estava eu um dia a trabalhar no meu desktop quando quis aceder ao conteúdo de um CD. Fiz um vulgar "mount" como sempre havia feito. Mas, desta vez, algo diferente aconteceu: em vez da shell me devolver logo a seguir o controlo, o mount ficou ali pendurado, e a luz do disco rígido permanentemente acesa... Esperei um bocado. Tentei matar o processo, mas o sistema não respondia às combinações de teclas habituais. Só houve uma solução que foi desligar o computador.
Porém, quando o computador voltou a iniciar, a BIOS já não conseguia fazer a detecção automática dos discos... Abri o computador, verifiquei os cabos, nada... Troquei uns cabos, e verifiquei que sem o leitor de CD-Rom (um Philips 48x) ligado, a detecção já era feita. Resultado, tenho o meu leitor de CD-Rom arrumado num canto à espera de o testar noutro computador para dar o veredito final: foi ou não o Linux que o estragou? História de horror 2: O suspend fatal
Instalei o SuSE 7.2 no meu portátil há uma semana. Algumas dificuldades com a configuração do X foram ultrapassadas importando as actualizações do site da SuSE. Estando os componentes essenciais instalados e a funcionar, a páginas tantas resolvi experimentar o APM no Linux (afinal num portátil o APM é mesmo essencial). Verifiquei que o Kernel estava configurado para carregar o módulo de APM, e iniciei o "daemon" com
# rcapmd start
Executei depois os comandos:
# apm -S
# apm -s
Até aqui tudo bem, o daemon fazia, aparentemente, tudo bem.
Fui então para o KDE e resolvi experimentar um utilitário que, salvo erro, tem o nome de Laptop Power Control ou algo parecido. Accionei o comando Suspend a partir desse programa, e o computador desligou. Pareceu-me abrupto mas não imaginava o que aconteceria a seguir: o portátil não mais voltou a ligar! É isso mesmo que estão a ler: o portátil nunca mais deu sinais de vida, nem uma ténue luz ou ruído, nada! Moral da história
Se eu contasse estas histórias e dissesse que foi com o Windows, apareciam logo uns finórios com os chavões e ironias do costume. Acontece que, em 10 anos, nunca o Windows me estragou qualquer hardware e nunca ouvi falar de que isso tenha acontecido a alguém. No Linux, isto aconteceu-me em dois computadores diferentes, a executar operações triviais, e a utilizar um Kernel estável (2.4.4).
Que confiança posso eu, então, depositar no Linux? Por muito menos, outros já teriam simplesmente mandado este sistema operativo às urtigas! É difícil de configurar e, ainda por cima, estraga hardware?!
Porém, eu sou um idealista, e estou disposto a perdoar o Linux e dar-lhe mais uma oportunidade. Receio, no entanto, que seja a última... " < O negócio da programação | Gildot na Sic Radical > | | gildot Login | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Primeiro, os CD IDE actuais, salvo umas honrosas excepcoes, sao uma bosta. E os Philips 48x nao estao na lista das excepcoes... Alem disso, eu quase que aposto que era um CDR, nao um CD prensado, certo ? Se fores ver os logs dessa data, vais ver que deves ter varios erros de IDE, bus reset, etc...
E' verdade que eu ultimamente tenho visto esse comportamento, uma falha no mount que parece irrecuperavel, mesmo tentado matar processos, reset's, etc. Tenho uma maquina com um processo desses pendurado ha' meses...
Quanto ao facto do Philips nao funcionar mais, duvido MUITO que tenha sido o Linux. Podia estar nas ultimas e esse processo foi a gota de agua que transbordou o copo... experimenta noutro PC para ter a certeza... Quanto ao portatil, e' sabido que o APM tem problemas. Depende da BIOS, e' quase feito de maneira diferente de modelo para modelo, etc.
Ao contrario do que tu disses, eu ja' vi isso acontecer MUITAS vezes em Windows. O que tens a fazer e' desligar o portatil da corrente, tirar a bateria, esperar 5 minutos e depois liga-lo. Vais ver que vai bootar lindamente. Alguns portateis teem um botao/switch/combinacao de teclas que faz um full-reset, ve no manual...
|
| | | | | | Como já foi dito, o hardware estraga-se... agora pensa assim.. és um sistema operativo... tens supostamente um cd-rom esperas dizer olá e ele dizer-te olá de volta aquando do mount acontece... que ele nada diz ou lixo retorna... Como duvido muito que andem a queimar cd-roms para saber como o mount se comporta nesse caso, é possível que essa seja até a causa do mount ter encravado.
(Tenho dois cdroms ide queimados na gaveta mas, por acaso deram o ultimo suspiro em windows... e não vim para o gildot queixar-me que o windows queimou-me os cdroms)
Quanto ao apm... bem... o apm é uma coisa quase só de bios e a culpa aí pode até ser de linux.. passo a explicar... qualquer sistema operativo limita-se a fazer as chamadas apm à bios que por sua vez executa o que tem a executar. Acontece que as bios tb são programas, tb precisam de ser testadas e a realidade é que normalmente só são testadas para ver se funcionam em windows... pelo que uma ordem diferente de invocar os comandos pode ser o que baste para uma bios mal conseguida cause problemas em linux. Infelizmente não tem muito que se possa fazer em linux a não ser tentar contornar os problemas da bios à medida que vão aparecendo. Podes tentar usar ACPI em vez de apm ou não usar nada de todo (à custa de tempo de utilização).
Quanto ao portátil, podes reclamar ao fabricante (visto que é suposto que a bios funcione direitinha o suficiente para ser usável) ou seguir a explicação já muitas vezes dada de como a ressuscitar.
|
| | | | Gostava de saber a marca/modelo do portatil.
Ja foste ver ao www.linux-laptop.net se mais alguem teve problemas com o portatil?
--- |
| | | | | Sugiro que compres o Linux for Dummies. Vou-te contar uma historia em contra-partida 'a tua novela. Joao: pa', o meu tio tem uma casa tao grande, tao grande que lhe leva 30 minutos a conduzir do portao ate' a' garagem! Manel: pois e' pa', o meu pai tinha um carro assim mas vendeu-o. Moral da historia: se nao achas que Linux nao e' para ti, usa Windows ou seja la' que for com que te sintas melhor. Eu tambem nao acho que Linux serve para tudo -- por exemplo, se eu tiver que correr uma RDBMS Oracle com 1TB de dados corro-a numa V880 a correr Solaris -- mas se quiser gastar pouco £££ num sistema de desenvolvimento compro um par de servidores Intel baratos, meto-lhe Linux com um bom ambiente de desenvolvimento e toca a andar. Se so' queres correr Linux para "experimentar" ou para pareceres "trendy" entao mais vale te ficares com Win32. Regards,
-- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
|
| | | | | | eu respondo-te assim, se te disser que um disco de 20gb ide se foi às urtigas depois dum reboot inofensivo em linux (erm... foi mais a controladora do disco... aquele circuitozito bonito "colado" ao disco... queimou... fez pufff... que fiz? troquei por uma controladora dum disco de 6gb, e funciona às mil maravilhas)... mas foi com toda a certeza por causa de linux... ou dum erro que deu... que ainda nao percebi como, mas queimou a circuito... agora funciona 3 horas seguidas, deixas o disco quieto um mes, e funciona mais 3 horas :P giro :P (sorte a minha ter trocado o circuito... ao menos nao tenho de esperar 1 mes para continuar o backup das coisas que la' tinha)....
moral da historia, eu usava linux, continuo a usar, mas duvidas não há, foi o linux que fez aquilo (ou o linux e erro no circuito integrado, mas os dois juntos, e nao só o circuito integrado em si :P)
HiTek DeVil |
| | | |
moral da historia, eu usava linux, continuo a usar, mas duvidas não há, foi o linux que fez aquilo (ou o linux e erro no circuito integrado, mas os dois juntos, e nao só o circuito integrado em si :P)
Como é que podes ter tanta certeza? Porque é que assumes que foi "o linux" e não simplesmente "a acção normal de qq sistema operativo que estivesse a usar na altura"? Ou seja, o que é que te leva a pensar que foi o uso em particular do linux que desencadeou a acção? Dizes que aquilo aconteceu após "um reboot", poderia ter sido também desencadeado pelos testes normais da BIOS no POST. Ou por um pico de corrente. Ou por... sei lá o quê (homenzinhos verdes de marte?). Não estou a dizer que não tenha sido o linux (até pode ter sido, a minha experiencia não me faz supor que os drivers de linux tenham menos bugs do que os de outros SOs) mas não apresentas nada de convincente para justificar essa posição.
Duvido que uma análise estatistica séria indique o linux associado a mais problemas de hardware que outros sistemas operativos (a minha experiencia pessoal pelo menos não me indica tal coisa, mas o número de máquinas de que trato é da ordem das centenas apenas, e a maior parte é Windows, pelo que é normal que sejam mais estas que se estraguem).
JB |
| | | | bem, basicamente porque a controladora "flipou" na altura em que começou a montar a primeira partição que tinha para montar como Read/Write... e ficou a fazer loop infinito... nao sei porque... não é normal, que eu saiba... e pelo que li, nunca tinha acontecido a ninguem... por mais que perguntasse... :P
mas como eu disse, pode ter sido do linux, da controladora, dos dois... :P
HiTek DeVil |
| | | | hummmm.... hei-de te mandar um prog feito por mim para um projecto duma cadeira... serve basicamente para mandar info para as flash memories... mas funciona bem com as bios... :P
Não, mas se leres um post acima que escrevi, percebes... alem disso o disco era praticamente novo... ainda nem acabou um ano de fabrica :P
HiTek DeVil |
| | | | Estável????????? AHAHAHAHAHAHAHAHAHAHAH!
O Linux é um sistema operativo excelente (bem o posso dizer, tenho máquinas em produção há uns 5 anos com ele). Mas 1) aventurar-se com versões comerciais 2) andar a brincar com a porcaria do X 3) querer utilizar mecaniscmos (como o APM) feitos para "proprietarizar" os WinTel: é uma completa receita para o desastre.
Estragar o hardware???? AHAHAHAHAHAHAHAHAH!
O hardware estraga-se sózinho. Há quanto tempo não consigo mexer num simples leitor de FDD sem dar chatice? Há tempo demais. E os leitores de CD vão pelo mesmo caminho. Objectivamente, a qualidade do hardware tem vindo a decrescer há pelo menos 10 anos. E o facto (de que não duvido) de um leitor de CD da Philips deixar de funcionar não indicia absolutamente *nada* no que diz respeito ao sistema operativo... que cabo? que fonte? que controlador IDE? que motherboard? Facto facto é que nenhum periférico deveria ser susceptível de ser avariado por qualquer acção do software... se isso acontece, o periférico não presta, e nada pode impedir de 1) virus 2) bug 3) um CD específico (no caso) o avariar.
Em suma: não usar o Linux para workstations (não presta, ou melhor, Linux ainda é pior); não instalar versões "redmondizadas" do Linux (incluindo o Mandrake, Suse, RedHat, etc); não esquecer de agitar antes de usar (é pra dar espaço aos bits do CD para ficarem no sítio :).
|
| | | | | | | Em suma: não usar o Linux para workstations (não presta, ou melhor, Linux ainda é pior); não instalar versões "redmondizadas" do Linux (incluindo o Mandrake, Suse, RedHat, etc); Exacto, acho que o melhor até é nem usar uma distro, nem X nem nada dessas mariquices. Usa-se só uma bash, em single user, sem rato, rede, etc... Assim é muita bom, não é? Ou pelo menos quase tão bom como BSD...
|
| | | | Em suma: não usar o Linux para workstations (não presta, ou melhor, Linux ainda é pior); não instalar versões "redmondizadas" do Linux (incluindo o Mandrake, Suse, RedHat, etc); não esquecer de agitar antes de usar (é pra dar espaço aos bits do CD para ficarem no sítio :).
<Lança-chamas>
Acho que sim!
Linux from Scratch ao poder!
Abaixo os fracos do rpm!
Abaixo a inclusão de drivers e módulos de kernel!
Para quê se é muito mais divertido e educativo escrevê-los???
E porque não divertirmo-nos a compilar o GCC SEM O GCC?!
<Lança-chamas>
Cada um usa o Linux como quer e muito bem lhe apetece! Ou queres que o Linux continue no seu cantinho dos geeks?
Não vou ensinar a minha avó a a recompilar um kernel, pois não?
Sinceramente, espero que estejas a brincar...
Yours,
McB!
They told me it need Windows 95 or better, so I chose Linux |
| | | | <Lança-chamas>
[...]
</Lança-chamas>
Assim sim!
Peço desculpa pelo meu XML mal construído! :)
Yours,
McB!
They told me it need Windows 95 or better, so I chose Linux |
| | | por Anonimo Cobarde em 06-12-01 4:17 GMT (#5)
|
| É de facto horrível....agora dizer que o CD ficou estrado por causa de um mount....convenhamos...deve ter sido uma infeliz coincidência. Os devices tem interfaces de acesso que foram feitas para precisamente evitar danos por sotware.
Sugiro que vejas o url para laptops que já recomendaram e para informações geral sobre hardware por exemplo:
http://mega.ist.utl.pt/~gach/hardware/hwg.html
|
| | | | bem, mais um caso de conclusoes precipitadas...
o hardware avaria sabes... tive a 2 anos um 486 que durante um arranque do win98lite (para ir ver um doc do word) encravou e desligou mal entrou no windows e "desligou" (fonte AT, monitor desligou, apenas luz de power acesa)
ao voltar a ligar apenas acendia a luz de power e mais nada, nao piscava, nao fazia barulho, nada...
abri e apenas fui descobrir que a MB tinha queimado uma ligacao que ia dar ao cpu (a "linha" tava mesmo toda queimada, parecia um rastilho)
vou dizer que o windows que e' pessimo (que e' 8), que queimou a MB ou vou dizer que a MB queimou?!
na altura que acedeste ao CD ele estragou, o kernel ficou preso com algo inesperado (que poderia recuperar ou nao), nao implica que o kernel tenha estragado o CD (ou a porta IDE)
quase nenhum software pode destruir o hardware e os que existem e' porque o hardware e' foleiro ou e' mal controlado, ao permitir fazer coisas que nao poderia fazer
(coisas tipo: mandar lixo para a bios (bem, nao arranca, mas nao e' bem um problema de hardware 8), havia um programa nos tempos dos 286 que conseguia destruir monitor simplesmente ajustando de proposito a frequencia do monitor para valores malucos, as placas e/ou monitores mais foleiros podia queimar, overburn de CDs pode queimar o gravador, overclock por software nao protegido, benchmark a discos em random access pode estragar o disco se ele ja' estiver fragil,etc)
o "caso" do CD esta' resolvido (e com facilidade)
o do APM... nem deverias saber que bugs nas bios sobre APM e' aos camioes (e com o acpi tambem ja' agora)
independentemente do OS (ja' que o OS apenas faz as chamadas para a bios actuar para as funcoes mais complicadas, em que o kernel nao pode actuar sem a ajuda da bios) e da marca, existem milhoes de computadores e portateis que dao problemas nos suspend, hibernar, etc
alguns portateis ja' nem trazem apm, trazem so' acpi, outros trazem o apm, mas apenas para dizer que teem, pois esta' tao mau que so' da' asneira
a regra basica antes de brincar com o apm e' saber os problemas conhecidos do apm do portatil...
agora ao teu problema...
parece-me que o suspend do programa que correste estava mais preparado para um portatil que nao o teu e pos-lo num estado semi-adormecido/encravado
ele nao arranca porque a bio ficou num estado que "pensa" que esta' a dormir e ao tentar ler a memoria para acordar o OS, nao existe nada e encrava automaticamente
tens de fazer um reset ao portatil, desliga da corrente, saca as baterias, carrega no botao para descarregar qualquer energia que possa haver e volta a montar tudo e voila', o portatil vive
e ja' agora, o 2.4.4 deveria ser estavel, mas tem problemas (nao sei se no apm tambem), assim que poderes, actualiza para o 2.4.16 que ja' corrigiu uma tonelada de bugs desde o 2.4.4
agora uma coisa e' certa, o OS nao destroi o hardware, qualquer que ele seja, se assim fosse, o windows ja' teria destruido muito material, com a quantidade de acessos indevidos ao hardware
o que o pessoal esta' sempre pronto a apontar o dedo a aquilo que estavam a testar na altura, mas geralmente esquecem-se de ver o mais obvio primeiro
Higuita |
| | | | | Um sistema operativo, normalmente comunica com o hardware atraves de IO (assembler: in/out) e interrupcoes, que os devices disponibilizam (atraves de ioports, por exemplo). No caso do CD, acho que nem é o CD propriamente dito que é acedido via in/out, mas sim o controlador, que, ironicamente, é que controla as operacoes do CD. Normalmente o mesmo controlador é usado para o CD e para o disco. Por isso, se estas realmente convencido que foi o linux a lixar o CD, entao tem cuidado com o disco :) No entanto, nao deve ter sido. A unica forma de estragar HW , é usar os interfaces que estes facilitam, para alem dos limites que estes definem. Algum HW dos ultimos anos (ou seja, nem sequer é apenas o mais recente), já impoe os proprios limites de utilizacao a nivel do chip, mesmo assim ha sempre margem para problemas (como excesso de temperatura, ou IO a frequencias demasiado altas, mas que nao tratadas pelo chip). E isso pode ser de facto feito por SW (while (1){inb(port); outb(port+1,0x40); } pode estragar muitos chips), via Sistema operativo. Mas isso normalmente nao acontece. Em relacao ao mount ter bloqueado, isso é normal a partir do momento em que ha um falha do dispositivo (device). O mount é uma "blocking call", e quando está a fazer o mount propriamente disto, está a correr em kernel mode, ou seja, kill -9 nao funciona. O problema aqui é que o mount deveria ter saido do kernel mode quando houve falha do device, mas por uma razao qualquer que eu desconheco (nunca investiguei as sources do mount -- como esta implementado no kernle, e nao do comando; este ultimo usa a mount(2) call), o mount mantem-se em kernel mode, mesmo quando existem falhas. Em relacao ao APM, sao os bugs e a falta de especificacao. Fazer um suspend nao é algo que seja trivial, ha que avisar todos os devices que vao ser parados, para-los :), e manter o estado para que o sistema possa ser retomado como estava. As BIOS podem ser mais ou menos inteligentes para o fazer. Por exemplo, é muito dificil uma BIOS suportar todos os modos graficos que todas as combinacoes de placas de video suportam. Aqui entram os BUGS, se uma BIOS nao consegue fazer X, deve avisar que nao consegue. Se for BUGGY crasha. Foi o que te aconteceu. Provavelmente quando fizeste "apm -s", foi a partir da consola (em modo texto), e quando usaste a outra aplicacao, foi obviamente em modo grafico. Se assim foi, entao a BIOS do teu portatil nao consegue fazer suspend do modo grafico. A minha tb nao, so que avisa! Ou seja, quando tento fazer suspend em X11, ouve-se um beep e fica tudo como esta. Quando o quero fazer, faco: ctrl-alt-f1 (mudo para a consola linux) e entao faco o apm -s. quanto ao sistema nao ligar, como foi dito e bem: usa uma combinacao de teclas para desligar realmente o portatil (normalmente é a de suspend e a de off ao mesmo tempo), e se nao funcionar desliga da energia externa e tira a bateria. cya
-- carlos |
| | | | | Este artigo faz-me lembrar um caso que aconteceu com um colega há uns anos. Tinha acabado de comprar um portátil Compaq (não perguntem o modelo, não sei) e está na faculdade, e farto de usar o écran pequeno e o teclado, resolve desligar as fichas a um computador desligado e ligar ao portátil. Portanto, com o portátil a trabalhar ele está com a tampa fechada e a usar um monitor e um teclado externo (ah, e um rato claro). Estivemos perto de umas duas horas a trabalhar até que ele diz: "vou para casa" e faz shutdown do computador, desliga as fichas e vai-se embora. No dia seguinte foi o descalabro. Aparece na faculdade extremamemnte preocupado, liga-nos o portátil e diz que não aparece imagem no écran. De facto, o portátil ligava mas não aparecia nada no écran. Se ligasses um monitor externo e exportasses o écran ele dava no monitor externo. Se voltavas a ligar o LCD do portátil ele não mostrava nada. O meu colega foi falar com professores (de informática) e as respostas foram as mais disparatadas: "Um problema na bios", "Não tinhas nada de usar o Turbo Pascal para trabalhar no portátil, porque é software em DOS é velho e acabaste por queimar a placa gráfica INTERNA (????)... e assim, um chorrilho de parvoices. Ele ligou à Compaq e eles também não souberam resolver o problema. Até que um técnico da Compaq combinou encontrar-se com ele para ver onde estaria o problema. E nem imaginam quão simples era o problema! É que existe um pequenino switch que desliga o LCD interno quando se fecha a tampa e o switch encravou. Tão simples quanto isso. Não foi um problema de hardware causado por software mas pelo uso físico do hardware. E é assim tão simples quanto isso. Longe vão os tempos em que era possível "rebentar" com um disco rígido ao tentar mover as cabeças para posições inválidas. Ou como já se disse, estoirar CRTs ou outras coisas.
----
//\anuel /|zevedo |
| | | | A questão do CDROM, bem as coisas avariam de vez em quando... quando me avariaram varios CD-ROMs, sim ja tive bastantes... Da ultima vez que tinha utilizado estavam a funcionar, neste caso foi o Windows que os avariou ? E' exactamente igual... Mudando apenas o OS... O hardware avaria, seja por picos de tensão, seja por desgaste, defeito de fabrico, etc etc etc...
SuSE e KDE e' uma combinação explosiva, eu processava a SuSE pelo dano... :]
Que queres que diga mais ?
Jovem ja passaram pelas minhas maos centenas de maquinas e centenas de instalações de Linux, nunca vi ou notei que o software pudesse killar hardware da forma que descreves... :) Eu mandava era o electricista ver as ligaçoes electricas e arranjava uma UPS activa!.
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it... |
| | | | | | Tens duvidas ? :] Para quem se inicia, SuSE até que é jeitoso, mas com o tempo a versatilidade da Red Hat torna-se um factor mais importante que GUI's para confs e coisas assim... Deixei a SuSE porque ja estava farto de crash's com o YaST2, o SaX2 estoirava com uma Viper 550 da Diamond, enfim.. problemas que deixei de ter com a Red Hat... 'E uma questao de escolha... Red Hat / Gnome ou SuSE KDE :] ou ReD Hat KDE com SuSE Gnome... :] Eu tomei a minha, tu tomas-te a tua... cada um defende o seu ponto de vista... bah... andamos mas e' para aqui a perder tempo :]
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it... |
| | | | | Vá, mostra lá o cartãozinho da micro$oft... Aquele Bill Gates não pára diante de nada! Agora até infiltra agitadores no GilDot! Livra!
|
| | | | | | | estava eu a programar em C++ quando me deparei com um problema que nao consegui resolver! andei de volta daquilo horas e horas, dias, semanas meses! sempre a olhar para aquela prompt da bash... até que me apercebi que tinha de usar o emacs para inserir texto no .cc e o monitor de tanto # que apareceu ficou com o fósforo queimado! fiquei tremendamente desiludido com o Linux, então ele não me podia ter dito logo?? será que ele merece outra oportunidade? veja cenas dos próximos capitulos nos includes que se seguem
|
| | | | Viva,
Eu acredito que os problemas de hardware acontecem, nao porque determinado sistema operativo estava a funcionar, mas porque a máquina estava ligada (as peças tem desgaste), claro que se usarmos o linux numa máquina que tem problemas de hardware vamos ter problemas no linux, mas fiquem a saber que com o windows é melhor, nao o consegues instalar (lol, às vezes). Eu podia descrever aqui problemas que tive com o windows, que me estragou X e Y, mas acredito que o que estragou X e Y foram ou os anos do equipamento, ou os problemas de fabrico! Hugs, Kaser
|
| | | |
|
