Kernel Omnislash (Unofficial) - Aprendendo a voar sem segredos!!!

vampire_thunder · 22 de Julho de 2010, 22:31

Estou usando um note da HP e com o Lucid, eu nunca vi um PC travar tanto.
Depois que eu recompilei o 2.6.32, até que parou de travar, mas ainda assim um monte de coisas, como os sensores de temperaturas, não funcionam.
Como o note esquenta muuuito, aliado aos travamentos, o HD já está quase indo para o beleléu. Mas eu mantenho tudo mesmo numa partição EXT4, por considerar mais segura.

galactus · 22 de Julho de 2010, 23:52

Tenho usado o 1.4.4 pelo menos 18 horas por dia sem reiniciar a máquina e sem qualquer travamento ou Bug! O máximo de tempo com o 1.4.4 sem reiniciar a máquina foi de 41 horas!

Eu não sei, mas como vocês continuam usando um sistema que trava tanto?

vampire_thunder · 23 de Julho de 2010, 00:17

Citação de: galactus online 22 de Julho de 2010, 23:52
Eu não sei, mas como vocês continuam usando um sistema que trava tanto?

Justamente, trocando de kernel. Só assim para usar o Lucid.
Mas tem gente que dá sorte. Vejam no final da página:
http://www.vivaolinux.com.br/topico/Duvidas-em-Geral/Travando-3?num_por_pagina=12&pagina=3

vampire_thunder · 23 de Julho de 2010, 05:59

Citação de: Hqxriven online 22 de Julho de 2010, 15:43

Não tenho mais... Hd novo

Alguns interessantes

http://ck.kolivas.org/patches/bfs/2.6.33-sched-bfs-318.patch

http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.33/2.6.33-ck1/patch-2.6.33-ck1.bz2

Quanto ao resto eu não me lembro... mas já é um começo.

Falhou demais:

Código Selecionar

oot@filipo-laptop:/usr/src/linux# patch -p1 -i 2.6.33-sched-bfs-318.patch patching file Documentation/sysctl/kernel.txt
patching file include/linux/init_task.h
patching file include/linux/sched.h
Hunk #3 succeeded at 1245 (offset 3 lines).
Hunk #4 succeeded at 1291 (offset 3 lines).
Hunk #5 succeeded at 1371 (offset 3 lines).
Hunk #6 succeeded at 1595 (offset 3 lines).
Hunk #7 succeeded at 1671 (offset 3 lines).
Hunk #8 succeeded at 1992 (offset 3 lines).
Hunk #9 succeeded at 2155 (offset 3 lines).
patching file kernel/sysctl.c
Hunk #1 FAILED at 104.
Hunk #2 FAILED at 239.
Hunk #3 FAILED at 251.
Hunk #4 FAILED at 364.
Hunk #5 FAILED at 761.
5 out of 5 hunks FAILED -- saving rejects to file kernel/sysctl.c.rej
patching file kernel/sched_bfs.c
patching file kernel/posix-cpu-timers.c
Hunk #1 FAILED at 250.
Hunk #2 FAILED at 516.
Hunk #3 FAILED at 526.
Hunk #4 FAILED at 1019.
Hunk #5 FAILED at 1035.
Hunk #6 FAILED at 1043.
Hunk #7 FAILED at 1366.
7 out of 7 hunks FAILED -- saving rejects to file kernel/posix-cpu-timers.c.rej
patching file kernel/exit.c
Hunk #1 FAILED at 121.
1 out of 1 hunk FAILED -- saving rejects to file kernel/exit.c.rej
patching file mm/oom_kill.c
patching file init/Kconfig
Hunk #1 FAILED at 23.
Hunk #2 FAILED at 447.
Hunk #3 FAILED at 563.
3 out of 3 hunks FAILED -- saving rejects to file init/Kconfig.rej
patching file kernel/delayacct.c
Hunk #1 FAILED at 128.
1 out of 1 hunk FAILED -- saving rejects to file kernel/delayacct.c.rej
patching file fs/proc/base.c
Hunk #1 FAILED at 366.
1 out of 1 hunk FAILED -- saving rejects to file fs/proc/base.c.rej
patching file init/main.c
Hunk #1 FAILED at 806.
1 out of 1 hunk FAILED -- saving rejects to file init/main.c.rej
patching file Documentation/scheduler/sched-BFS.txt
patching file lib/Kconfig.debug
patching file arch/powerpc/platforms/cell/spufs/sched.c
patching file kernel/sched.c
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 11039.
2 out of 2 hunks FAILED -- saving rejects to file kernel/sched.c.rej
patching file include/linux/ioprio.h
patching file kernel/kthread.c
Hunk #1 FAILED at 167.
1 out of 1 hunk FAILED -- saving rejects to file kernel/kthread.c.rej
patching file kernel/slow-work.c
Hunk #1 FAILED at 716.
1 out of 1 hunk FAILED -- saving rejects to file kernel/slow-work.c.rej

Hqxriven · 23 de Julho de 2010, 06:04

CitarEu não sei, mas como vocês continuam usando um sistema que trava tanto?

Fui ingênio por acreditar que o problema era hardware e não o kernel.

O problema na maioria dos usuários (pcp os que não usam cheatcodes normalmente) se resume a dois pontos

libata e acpi

Se colocarem acpi_skip_timer_override diminui muito a ocorrência dos dois bugs, já que pelo que percebi o acpi é responsável pelo crash do sistema e o libata é responsável pela perda de partição, pelos badblocks e óbvio o crash com badblocks dá danos no hd

Se vc não tiver os crashs é mais difícil a falha do libata entrar em funcionamento.

Acho que fui o único que até agora viu uma "solução" (não é solução total ela só impede o crash do acpi)

Acho que isso também pode ser substituido com noapic, mas aí teremos probleminhas chatos na hora de desligar a máquina em alguns sistemas (algumas vezes desliga, em outras não)

E coloquei ela no fórum ubuntu

http://ubuntuforums.org/showpost.php?p=9612800&postcount=731

Felizmente alguns usuários já viram...

http://ubuntuforums.org/showpost.php?p=9613921&postcount=734

http://ubuntuforums.org/showpost.php?p=9625580&postcount=753

Infelizmente acho que agora temos um novo bug danificador de discos rígidos...

Hqxriven · 23 de Julho de 2010, 06:05

É o 2.6.33 puro ou o 2.6.33.algum número??

vampire_thunder · 23 de Julho de 2010, 11:00

Citação de: Hqxriven online 23 de Julho de 2010, 06:05
É o 2.6.33 puro ou o 2.6.33.algum número??

Puro ele não é, pois já está com o patch do LZMA. O nome é 2.6.33-grml.02

Hqxriven · 23 de Julho de 2010, 12:34

CitarPuro ele não é, pois já está com o patch do LZMA. O nome é 2.6.33-grml.02

Ele deve ter alguma modificação que está atrapalhando...

Vamos tentar diferente:

Pegue o 2.6.33 puro e acrescenta o bfs

E esses dois do mandriva

http://svn.mandriva.com/svn/packages/cooker/kernel/current/PATCHES/patches/fs-squashfs-lzma.patch

http://svn.mandriva.com/svn/packages/cooker/kernel/current/PATCHES/patches/lzo-Fix-up-add-support-for-lzo-compressed-kernels.patch

vampire_thunder · 23 de Julho de 2010, 15:50

Citação de: Hqxriven online 23 de Julho de 2010, 12:34

Ele deve ter alguma modificação que está atrapalhando...

Vamos tentar diferente:

Pegue o 2.6.33 puro e acrescenta o bfs

E esses dois do mandriva

http://svn.mandriva.com/svn/packages/cooker/kernel/current/PATCHES/patches/fs-squashfs-lzma.patch

http://svn.mandriva.com/svn/packages/cooker/kernel/current/PATCHES/patches/lzo-Fix-up-add-support-for-lzo-compressed-kernels.patch

Obrigado, amigo. Mas vou deixar para lá. Os patches entraram, com pouquíssimos hunks, mas nem ele nem qualquer outro que eu testei dá essa opção que vem no kernel que funcionou:

Quem sabe o cara lá não cria um 2.6.34. Aí eu volto a testar. Só não vá mudar de HD e jogar os patches fora, não, eim

Hqxriven · 23 de Julho de 2010, 16:19

Vc usa o squashfs com criptografia em lzma... esse é raro!! Eita...

Tá aí um patch que é bem raro mas distros.

Assim que criar alguma coisa te dou um alô. Por enquanto o máximo que consigo mesmo sem problemas é o AUFS (pq o sidux usa), o squashfs dá uma trabalheira....

vampire_thunder · 23 de Julho de 2010, 18:54

Citação de: Hqxriven online 23 de Julho de 2010, 16:19
Vc usa o squashfs com criptografia em lzma... esse é raro!! Eita...

Tá aí um patch que é bem raro mas distros.

Assim que criar alguma coisa te dou um alô. Por enquanto o máximo que consigo mesmo sem problemas é o AUFS (pq o sidux usa), o squashfs dá uma trabalheira....

Sim, isso é raro, por isso essa dificuldade.
Depoimento do Big Bruno:

Citarpra colocar no Big foi uma novela enorme.
esse kernel foi o mais complicado que já tive que colocar pra funcionar LZMA, além de ser comum a imagem falhar, refazer ela com os mesmos métodos e funcionar, acho que está relacionado com a alocação de memória do mksquashfs, algumas vezes ele está no meio do processo e da falha de segmentação.

Parece que quando era o 3.1 (que por acaso compactava até mais) era mais fácil.

Arkage · 24 de Julho de 2010, 03:27

Olá meus caros, eu estou a um tempo tentando usar essa kernel tenho recebido o mesmo erro.
Já tentei umas gambiarraszinhas hehehe... e consegui eliminar um dos erros... mas esse persiste...
Se alguém souber como solucionar eu agradeço.

Abraços!

Configurando linux-image-2.6.34-omnislash1.4.4 (x86) ...

Hmm. There is a symbolic link /lib/modules/2.6.34-omnislash1.4.4/build
However, I can not read it: Arquivo ou diretório não encontrado
Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/build

Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/nvidia-common 2.6.34-omnislash1.4.4
run-parts: executing /etc/kernel/postinst.d/pm-utils 2.6.34-omnislash1.4.4 /boot

Andreson Goveia · 24 de Julho de 2010, 04:22

Citação de: Arkage online 24 de Julho de 2010, 03:27
Olá meus caros, eu estou a um tempo tentando usar essa kernel tenho recebido o mesmo erro.
Já tentei umas gambiarraszinhas hehehe... e consegui eliminar um dos erros... mas esse persiste...
Se alguém souber como solucionar eu agradeço.

Abraços!

Configurando linux-image-2.6.34-omnislash1.4.4 (x86) ...

Hmm. There is a symbolic link /lib/modules/2.6.34-omnislash1.4.4/build
However, I can not read it: Arquivo ou diretório não encontrado
Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/build

Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/nvidia-common 2.6.34-omnislash1.4.4
run-parts: executing /etc/kernel/postinst.d/pm-utils 2.6.34-omnislash1.4.4 /boot

Ele finaliza a instalação??
Acontece o que depois?
Você consegue entrar no sistema com o omnislash???
De mais detalhes pois estes dois "erros" ai que eu me lembro apareceu aqui e não são erros e sim avisos do que está sendo feito o sistema.
Tentou fazer os demais procedimentos??
Se não aconselho que faça e tente dar boot pelo omnislash.
[]s.

galactus · 24 de Julho de 2010, 08:24

Gente, esse LZMA tem que ser bucha mesmo. Se até essa altura do campeonato o Tio Linus tá passando o maior sabão no desenvolvedor e não aceita a inclusão disso no kernel oficial, tem algum motivo né? Só ver o maior aperto que vocês passam pra tentar fazer isso funcionar direito!

Quanto aos problemas com o kernel oficial do 10.04, no meu caso, o que mais ocorria era o consumo exagerado de memória de maneira "aleatória"! Assim, algumas vezes o Ubuntu subia comsumindo 320MB, outras 1.3GB, em outras 270MB. Com os mesmos serviços e programas que eu uso sempre. Não adiantava remover programas ou desligar serviços que isso sempre acontecia! Eu tenho testado o Linux Mint 9 e isso não acontece com ele.

Outra coisa interessante, instalei o Mint 9 LXDE na versão mais nova do VirtualBox. E o VirtualBox mesmo avisa em letras em negrito que o uso do EXT4 com gravação de cache e com taxas de I/O altas, tem provocado o corrompimento do sistema de arquivos da máquina virtual!!!! Basicamente ele te diz para usar outro sistema de arquivos, pois o uso do EXT4 pode moer todo o sistema!!!
E no site da Canonical ele também avisa que em certas condições o EXT4 pode ficar muito lento!!!

É o tipo de coisa que não entendo, se tanta gente ainda tá tendo problema com o ext4, porque todos estão partindo pro uso dele como padrão! Até a Red Hat, com a nova versão 6, que está em reta final de lançamento, também vai trazer o ext4 como padrão!!!! Com certeza o kernel do Red Hat 6 vai vir bem amarradinho quanto a essas questões! To ancioso pelo Centos 6!

MSXManiac · 24 de Julho de 2010, 09:17

root@mobile:/home/marcos/Área de Trabalho# dpkg -i linux-*.deb
Selecionando pacote previamente não selecionado linux-headers-2.6.34-omnislash1.4.4.
(Lendo banco de dados ... 124457 arquivos e diretórios atualmente instalados).
Desempacotando linux-headers-2.6.34-omnislash1.4.4 (de linux-headers-2.6.34-omnislash1.4.4_x86_i386.deb) ...
Selecionando pacote previamente não selecionado linux-image-2.6.34-omnislash1.4.4.
Desempacotando linux-image-2.6.34-omnislash1.4.4 (de linux-image-2.6.34-omnislash1.4.4_x86_i386.deb) ...
Done.
Configurando linux-headers-2.6.34-omnislash1.4.4 (x86) ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/nvidia-common 2.6.34-omnislash1.4.4 /boot/vmlinuz-2.6.34-omnislash1.4.4
Configurando linux-image-2.6.34-omnislash1.4.4 (x86) ...

Hmm. There is a symbolic link /lib/modules/2.6.34-omnislash1.4.4/build
However, I can not read it: Arquivo ou diretório não encontrado
Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/build

Hmm. The package shipped with a symbolic link /lib/modules/2.6.34-omnislash1.4.4/source
However, I can not read the target: Arquivo ou diretório não encontrado
Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/source

Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.34-omnislash1.4.4 /boot/vmlinuz-2.6.34-omnislash1.4.4
run-parts: executing /etc/kernel/postinst.d/nvidia-common 2.6.34-omnislash1.4.4 /boot/vmlinuz-2.6.34-omnislash1.4.4
run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 20
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.34-omnislash1.4.4.postinst line 341.
dpkg: erro processando linux-image-2.6.34-omnislash1.4.4 (--install):
sub-processo script post-installation instalado retornou estado de saída de erro 128
Erros foram encontrados durante o processamento de:
linux-image-2.6.34-omnislash1.4.4

Alguma sugestão?
Todas as vezes que compilava aparecia isto1 Usando os pacotes deb também! Testei numa instalação limpa do maverick, iso que baixei dia 20 ou 21 mas só pude testar hj...