Marcos FRM

@rodrigo.dcvieira Sim, com aplicativos altamente otimizados como o HandBrake (especificamente falando, a biblioteca principal usada por ele: libx264), mais núcleos fazem grande diferença. Resta esperar que os demais programas que usamos no dia a dia comecem a aproveitar melhor vários núcleos.

Cabe um esclarecimento aqui. A glibc e libstdc++, mesmo compiladas com um conjunto de instruções antigo (à la do Pentium Pro), possuem uma penca de assembly que autodetecta durante a execução instruções adicionais. Portanto, as principais funções usadas por programas que as linkem (strcpy(), strlen(), etc) aproveitam sim instruções pós-Pentium Pro mesmo quando o código é compilado com -march=i686. Contudo, o menor número de registradores continua sendo um fator limitante, muito relevante com binários PIE. E ter um conjunto de instruções base maior (x86-64) permite ao compilador otimizar mais códigos, inclusive aqueles que não fazem parte das bibliotecas do sistema que possuem otimização.

https://www.techpowerup.com/234476/amd-readies-b2-stepping-of-the-ryzen-summit-ridge-silicon Finalmente vai sair um novo stepping dos Ryzen. O primeiro eu passo... Vou jogar uns links aqui que dizem respeito ao bug dos Ryzen com Unix-like. https://community.amd.com/thread/215773 (já citado) https://fujii.github.io/2017/06/23/how-to-reproduce-the-segmentation-faluts-on-ryzen/ https://github.com/suaefar/ryzen-test (o famoso script que facilita a reprodução do bug) FreeBSD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029 https://svnweb.freebsd.org/base?view=revision&revision=321899 DragonFly BSD: https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/11ba7f73d6e534d54da55d5c4a1ac1553cc62b45 https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20 Discussões: http://www.realworldtech.com/forum/?threadid=170454 http://www.realworldtech.com/forum/?threadid=170994 https://www.phoronix.com/forums/forum/hardware/processors-memory/971859-new-ryzen-is-running-solid-under-linux-no-compiler-segmentation-fault-issue https://www.reddit.com/r/programming/comments/6f08mb/compiling_with_ryzen_cpus_on_linux_causing_random/ Para quem usa qualquer Unix-like: cuidado, você pode ser premiado com um chip defeituoso.

Mas por que a AMD estaria fazendo RMA do processador se pudesse ser consertado via microcódigo? A discussão no fórum da AMD é esta: https://community.amd.com/thread/215773 De novo, não estou gostando nada de como a AMD está lidando com esse problema. Não tem nenhuma informação oficial. Não tem errata. Ninguém sabe nada. Apenas consigo inferir que há algo de errado com alguns Ryzen e que até o momento a única forma de resolver, para aqueles infelizes "premiados" com um chip ruim, é via RMA. E que os chips livres de problema possuem o mesmo stepping, o que complica ainda mais. Ignorem a palavra Linux. Tem cara de ser defeito no chip, que cedo ou tarde pode se manifestar em qualquer sistema operacional. Parece que conseguiram reproduzir no FreeBSD, que usa ferramentas de desenvolvimento diferentes do Linux.

Estou achando isso preocupante. Se o conserto envolveu mexer no silício, o stepping do processador tem que ser incrementado. Mas pelo jeito não foi. Lendo a discussão lá no Phoronix, o único meio de identificar é pela data de fabricação. Chips livres de problemas seriam 1725+ (semana 25, ano 2017). Porém não sabemos se todos os anteriores são afetados, ou apenas alguns que fizeram parte de uma fornada ruim. Ou seja, uma bagunça da AMD.

Pela foto do site da Foxconn, o chip que armazena o BIOS está num soquete. Você pode retirá-lo e mandar regravar o arquivo com alguém que tenha um programador de EPROM. Ou, se seu segundo PC usar o mesmo tipo de soquete (e tensão/protocolo), usá-lo como cobaia para hot swap. Consiste em iniciar a placa que funciona e, com ela ligada, retirar o chip original, colocar esse a ser programado e atualizar (os programas de atualização precisam de algumas opções específicas nesse cenário para não abortarem).

Tente com esse de MEBIOS\BIOS.

Ahhh, eu acho que os caras fizeram besteira. Esse arquivo C12F1P04.BIN com 4 MiB deveria estar no lugar do que está truncado em SYSBIOS. Mas sabe-se lá. O Afuwin você baixou da onde? Como fez para tentar atualizar?

Eu acho que aí está o BIOS. Abra o arquivo flash.bat com o Bloco de notas.

Esquisito. Na especificação, consta um chip de 4 MiB mesmo. O que tem dentro de MEBIOS\BIOS?

@Walter C. Catelan Mas é importante ressaltar que instalações rodando com os processadores citados não recebem mais atualizações. Nessas circunstâncias, não usaria o Windows 7 nem por cinco minutos.

O site da Foxconn é horrivelmente lento. Não consegui baixar arquivo nenhum de lá. O que tem dentro do arquivo C12F1P05.zip?

"Errado" não é o termo exato. O sistema funcionará, porém a primeira partição começará no setor (de 512 bytes) 8192 ao invés do padrão 2048. Por quê? Por razão nenhuma! Memorize que esse "align=4096" não serve para nada e nunca mais o utilize. Aliás, como já falei mais de uma vez, não precisa criar partição alguma com o diskpart: deixe para o instalador fazer o serviço se você quiser ocupar todo o disco. Selecione-o (select disk) e apenas rode "clean", como, de novo, já foi dito. Mais nada. Saia do diskpart com "exit", feche o prompt de comando e prossiga. Selecione "espaço não alocado" lá mais adiante e clique direto em avançar. Não falo mais.

"align=4096" está errado. Releia o tópico porque não vou explicar novamente.

Windows 7 receberá atualizações de segurança até 2020, desde que você não tenha um AMD Ryzen (e APUs Bristol Ridge) ou Intel Kaby Lake ou posterior. De qualquer forma, o 7 é um sistema obsoleto e deve ser evitado quando possível.

Use o primeiro link, que traz o programa que atualiza dentro do Windows. Em teoria é só executar e seguir as instruções... EDIT: Aqui estão as instruções: https://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkcentre_bios/5jjy65usa.txt

Só um "clean" é o suficiente.

Pelo que eu saiba, a AOC não disponibiliza atualizações de BIOS. Você terá que entrar em contato com eles explicando a situação e pedindo uma atualização que habilite (ou que permita habilitar) o suporte a virtualização por hardware do processador (AMD-V). Fora isso, não há o que fazer.

Seu processador suporta AMD-V sim: http://www.cpu-world.com/CPUs/Bobcat/AMD-E Series E2-1800.html Estranho o Windows dizer que está habilitado no gerenciador de tarefas e os programas de identificação dizerem o contrário. Na janela da máquina virtual do VirtualBox, na parte inferior direita, tem um ícone de "V". O que diz se você colocar o mouse ali?

Parece que sim. A empresa decidiu, enquanto desenvolvia o RHEL 7, investir no XFS como substituto do cansado EXT4. Deu uma injeção de desenvolvimento bem a tempo, pois a SGI tinha demitido seu time de desenvolvimento. As características do XFS dão conta do público alvo do RHEL: suporta com folga grandes volumes, possui bom desempenho com arranjos RAID com muitos discos e sua escalabilidade (devido ao seu design) e robustez são melhores do que dos EXT nesses cenários. Trocar o EXT4 pelo XFS nos servidores da bolsa de valores de Nova Iorque faz sentido. Para os discos rígidos tartaruga dos nossos PCs, não faz diferença. Sobre o XFS, tentarão construir esse novo sistema de arquivos. Vamos ver no que vai dar.

Ao mesmo tempo me surpreende e não me surpreende. Não surpreende pois a Red Hat não tem nenhum especialista no Btrfs em sua folha de pagamento faz alguns anos e tem expertise no XFS por empregar os principais desenvolvedores, como Dave Chinner e Eric Sandeen, que trabalham nele desde o tempo da Silicon Graphics (XFS é uma das bases desse Stratis pelo que entendi). Surpreende pois o Btrfs já é usado em produção pela SUSE, Facebook, Netgear. Mas de fato está demorando demais para ser declarado oficialmente estável.

Qual versão do HandBrake foi utilizada?

Dê uma olhada no recém lançado openSUSE 42.3. O pacote plasma5-workspace dele tem mais backports, incluindo os commits: https://cgit.kde.org/plasma-workspace.git/commit/?id=9df815e843a4385465fff0cb9a76ddc94ed35b38 https://cgit.kde.org/plasma-workspace.git/commit/?id=7df184afa19f148c1cd09ae9588645bb2b4556fc https://cgit.kde.org/plasma-workspace.git/commit/?id=a17de5957d4ba0f07c77fa99860c9046ff8aa1be

Esse é o problema de ficar adicionando repositórios para substituir pacotes críticos. Descarte essa instalação aí, pois virou um Frankenstein. Basicamente você depende da competência dos empacotadores do openSUSE. Eles precisam resolver isso e disponibilizar uma nova versão do pacote plasma5-workspace no repositório "Updates".

@Walter C. Catelan Quando se deparar com esse problema novamente, abra, se possível, um tópico no fórum, me mencione e poste a saída dos comandos: icacls <unidade>: icacls <unidade>:\PASTA Para sabermos quais ACLs estão causando problema. As ACLs padrão aplicadas à raiz de volumes NTFS não possuem nenhuma negação (que sempre têm prioridade) que possa influenciar numa ACL liberando acesso a usuários específicos. Algo que poderia complicar seria um Integrity Level (IL) alto em alguma pasta, porém é muito raro ver ILs configurados em dados de usuários.