Re: [FUG-BR] ALTQ + Intel Drivers.
> > Message: 5 > Date: Tue, 21 May 2013 19:38:26 -0300 > From: Marcelo Gondim > Subject: Re: [FUG-BR] ALTQ + Intel Drivers. > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" > > Message-ID: <519bf762.5030...@bsdinfo.com.br> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Em 21/05/13 18:14, Renato Botelho escreveu: > > On 05/21/2013 04:52 PM, Bruno Araújo wrote: > >> Em 21/05/2013, às 16:32, Renato Botelho escreveu: > >> > >>> On 05/21/2013 04:28 PM, Marcelo Gondim wrote: > Em 21/05/13 15:52, Renato Botelho escreveu: > > On 05/21/2013 02:57 PM, vic wrote: > >> Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: > >>> EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% > !! > >>> mas > >>> ele ainda é experimental e as panes são normais. > >>> > >>> isso tá bem documentado. > >>> > >>> eu acho que a dedicação agora esteja no bhyve (Acho que é assim que > >>> escreve :p) > >>> > >> Sim, é experimental, mas eu tenho usado com sucesso o vimage. > Contudo > >> esqueça de usar o pf ou algum módulo externo do FreeBSD (como o > >> virtualbox por exemplo). > >> > >> Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último > >> compilado mas não está em uso) e está funcionando à 128 dias sem > parar e > >> com 7 jails. > > Ah sim, o fato de ser experimental não quer dizer que absolutamente > não > > irá funcionar. Serve mais pra te alertar que pode dar problema, que > não > > é estável. > > > > É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD > 9.1 > > não está estável, sendo que ele optou por usar algo experimental. > Quando > > você faz essa escolha está sujeito as consequências :) > > > > []s > Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava > uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa > data > o bug. O uso do ntfs com leitura e escrita também dava um monte de > kernel panic. Não sei agora como está. > >>> OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por > >>> conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do > >>> kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. > >>> > Teve kernel panic que descobri também no geom mas esse foi corrigido > rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer > dump no /var/crash. Esse problema do crash vi alguns relatos também, > que > mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só > uma > preocupação que estou tendo. Todos os meus servidores em produção > estão > rodando muito bem e sem reboots. > Meu medo é termos algo que aconteceu na versão 5.0, que eu não > vivenciei, mas que muitos tiveram problemas. > >>> Esses crashs estranhos e sem explicação são coisas que têm que ser > >>> diagnosticadas, e em muitos casos no final o problema tá no hardware. > >>> Sugiro habilitar debugs no kernel e ver se consegue algo. > >>> > >>> Sobre o que aconteceu no 5.0, foi uma história bem diferente, e > acredito > >>> que o time aprendeu com o erro, uma versão com tantas mudanças como > >>> ocorreu do 4 pro 5 não deve acontecer mais. > >>> > >> Quando um mero pacote ou software derruba o S.O. não é uma falha grave > do S.O? > > Isso é relativo, o FUSE por exemplo é um pacote que compila um módulo de > > kernel, não vejo o fato de um módulo de kernel derrubar o SO como algo > > falho do SO. Mas fica difícil falar pois não tenho detalhes sobre os > bugs. > > > Opa Renato, > > Esse lance do fuse depois que fiz um pr, rapidamente foi corrigido. Era > um bug sinistro mesmo. Porque era só montar a partição ntfs e começar à > copiar para dar um panic e o sistema reiniciar. Mas acho que pouca gente > devia estar usando esse cara porque o panic era instantâneo mesmo. Bem > esse foi resolvido rápido. > Agora esse race condition que é brabo porque ele está lá em algum lugar > e tipo não posso colocar um server e pendurar 4000 assinantes nele > sabendo que se alguém na minha rede fizer um ataque de login incorreto > por um certo tempo, vai causar um kernel panic derrubando os meus 4000 > assinantes. Eu fiz uma atualização ontem no sistema e parece que não > ocorreu mais mas ainda quero testar mais e ter certeza. > Vou testar com o 8.3 ainda pra saber se isso é só do 9.1. Não tenho o > que reclamar do Freeba todos os meus servidores estão 100% estáveis. Só > tive mesmo esses pipoucos estranhos em alguns testes e fiquei preocupado. > > Grande abraço à todos > > > > Bom pessoal, já que o tópico mudou de ALTQ + INTEL para FreeBSD estabilidade, gostaria de compartilhar meu ponto de vista quanto ao 9.1-RELEASE. Estou trabalhando há mais de 1 ano em um produto que usa FreeBSD como base. FreeBSD é ótimo, robusto e etc; como todos sabem. Agora vamos para o lado ruim, e esse lado ruim é realmente ruim mesmo. 1) Multirou
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 21/05/2013, às 22:59, Marcelo Gondim escreveu: > Em 21/05/13 19:56, Bruno Araújo escreveu: >> Em 21/05/2013, às 19:38, Marcelo Gondim escreveu: >> >>> Em 21/05/13 18:14, Renato Botelho escreveu: On 05/21/2013 04:52 PM, Bruno Araújo wrote: > Em 21/05/2013, às 16:32, Renato Botelho escreveu: > >> On 05/21/2013 04:28 PM, Marcelo Gondim wrote: >>> Em 21/05/13 15:52, Renato Botelho escreveu: On 05/21/2013 02:57 PM, vic wrote: > Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: >> EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! >> mas >> ele ainda é experimental e as panes são normais. >> >> isso tá bem documentado. >> >> eu acho que a dedicação agora esteja no bhyve (Acho que é assim que >> escreve :p) >> > Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo > esqueça de usar o pf ou algum módulo externo do FreeBSD (como o > virtualbox por exemplo). > > Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último > compilado mas não está em uso) e está funcionando à 128 dias sem > parar e > com 7 jails. Ah sim, o fato de ser experimental não quer dizer que absolutamente não irá funcionar. Serve mais pra te alertar que pode dar problema, que não é estável. É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 não está estável, sendo que ele optou por usar algo experimental. Quando você faz essa escolha está sujeito as consequências :) []s >>> Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava >>> uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa data >>> o bug. O uso do ntfs com leitura e escrita também dava um monte de >>> kernel panic. Não sei agora como está. >> OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por >> conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do >> kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. >> >>> Teve kernel panic que descobri também no geom mas esse foi corrigido >>> rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer >>> dump no /var/crash. Esse problema do crash vi alguns relatos também, que >>> mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só uma >>> preocupação que estou tendo. Todos os meus servidores em produção estão >>> rodando muito bem e sem reboots. >>> Meu medo é termos algo que aconteceu na versão 5.0, que eu não >>> vivenciei, mas que muitos tiveram problemas. >> Esses crashs estranhos e sem explicação são coisas que têm que ser >> diagnosticadas, e em muitos casos no final o problema tá no hardware. >> Sugiro habilitar debugs no kernel e ver se consegue algo. >> >> Sobre o que aconteceu no 5.0, foi uma história bem diferente, e acredito >> que o time aprendeu com o erro, uma versão com tantas mudanças como >> ocorreu do 4 pro 5 não deve acontecer mais. >> > Quando um mero pacote ou software derruba o S.O. não é uma falha grave do > S.O? Isso é relativo, o FUSE por exemplo é um pacote que compila um módulo de kernel, não vejo o fato de um módulo de kernel derrubar o SO como algo falho do SO. Mas fica difícil falar pois não tenho detalhes sobre os bugs. >>> Opa Renato, >>> >>> Esse lance do fuse depois que fiz um pr, rapidamente foi corrigido. Era >>> um bug sinistro mesmo. Porque era só montar a partição ntfs e começar à >>> copiar para dar um panic e o sistema reiniciar. Mas acho que pouca gente >>> devia estar usando esse cara porque o panic era instantâneo mesmo. Bem >>> esse foi resolvido rápido. >>> Agora esse race condition que é brabo porque ele está lá em algum lugar >>> e tipo não posso colocar um server e pendurar 4000 assinantes nele >>> sabendo que se alguém na minha rede fizer um ataque de login incorreto >>> por um certo tempo, vai causar um kernel panic derrubando os meus 4000 >>> assinantes. Eu fiz uma atualização ontem no sistema e parece que não >>> ocorreu mais mas ainda quero testar mais e ter certeza. >>> Vou testar com o 8.3 ainda pra saber se isso é só do 9.1. Não tenho o >>> que reclamar do Freeba todos os meus servidores estão 100% estáveis. Só >>> tive mesmo esses pipoucos estranhos em alguns testes e fiquei preocupado. >>> >>> Grande abraço à todos >>> >>> - >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> Por favor poste o resulta pois quero substituir um concentrador pppoe >> mikrotik por freebsd. >> A única coisa que ainda tá pegando é o controle de tráfego dinâmico com pf + >> mdp; o routeros está muito impreciso aqui. >> >> >> _
Re: [FUG-BR] ALTQ + Intel Drivers.
Please confirm if you put me in your mailloop wrongly, thanks. Thanks & Best Regards Adam Xu Innoveco Electronics Ltd. From: Marcelo Gondim Date: 2013-05-22 09:59 To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" Subject: Re: [FUG-BR] ALTQ + Intel Drivers. Em 21/05/13 19:56, Bruno Araújo escreveu: > Em 21/05/2013, às 19:38, Marcelo Gondim escreveu: > >> Em 21/05/13 18:14, Renato Botelho escreveu: >>> On 05/21/2013 04:52 PM, Bruno Araújo wrote: Em 21/05/2013, às 16:32, Renato Botelho escreveu: > On 05/21/2013 04:28 PM, Marcelo Gondim wrote: >> Em 21/05/13 15:52, Renato Botelho escreveu: >>> On 05/21/2013 02:57 PM, vic wrote: Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: > EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! > mas > ele ainda é experimental e as panes são normais. > > isso tá bem documentado. > > eu acho que a dedicação agora esteja no bhyve (Acho que é assim que > escreve :p) > Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo esqueça de usar o pf ou algum módulo externo do FreeBSD (como o virtualbox por exemplo). Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último compilado mas não está em uso) e está funcionando à 128 dias sem parar e com 7 jails. >>> Ah sim, o fato de ser experimental não quer dizer que absolutamente não >>> irá funcionar. Serve mais pra te alertar que pode dar problema, que não >>> é estável. >>> >>> É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 >>> não está estável, sendo que ele optou por usar algo experimental. Quando >>> você faz essa escolha está sujeito as consequências :) >>> >>> []s >> Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava >> uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa data >> o bug. O uso do ntfs com leitura e escrita também dava um monte de >> kernel panic. Não sei agora como está. > OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por > conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do > kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. > >> Teve kernel panic que descobri também no geom mas esse foi corrigido >> rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer >> dump no /var/crash. Esse problema do crash vi alguns relatos também, que >> mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só uma >> preocupação que estou tendo. Todos os meus servidores em produção estão >> rodando muito bem e sem reboots. >> Meu medo é termos algo que aconteceu na versão 5.0, que eu não >> vivenciei, mas que muitos tiveram problemas. > Esses crashs estranhos e sem explicação são coisas que têm que ser > diagnosticadas, e em muitos casos no final o problema tá no hardware. > Sugiro habilitar debugs no kernel e ver se consegue algo. > > Sobre o que aconteceu no 5.0, foi uma história bem diferente, e acredito > que o time aprendeu com o erro, uma versão com tantas mudanças como > ocorreu do 4 pro 5 não deve acontecer mais. > Quando um mero pacote ou software derruba o S.O. não é uma falha grave do S.O? >>> Isso é relativo, o FUSE por exemplo é um pacote que compila um módulo de >>> kernel, não vejo o fato de um módulo de kernel derrubar o SO como algo >>> falho do SO. Mas fica difícil falar pois não tenho detalhes sobre os bugs. >>> >> Opa Renato, >> >> Esse lance do fuse depois que fiz um pr, rapidamente foi corrigido. Era >> um bug sinistro mesmo. Porque era só montar a partição ntfs e começar à >> copiar para dar um panic e o sistema reiniciar. Mas acho que pouca gente >> devia estar usando esse cara porque o panic era instantâneo mesmo. Bem >> esse foi resolvido rápido. >> Agora esse race condition que é brabo porque ele está lá em algum lugar >> e tipo não posso colocar um server e pendurar 4000 assinantes nele >> sabendo que se alguém na minha rede fizer um ataque de login incorreto >> por um certo tempo, vai causar um kernel panic derrubando os meus 4000 >> assinantes. Eu fiz uma atualização ontem no sistema e parece que não >> ocorreu mais mas ainda quero testar mais e ter certeza. >> Vou testar com o 8.3 ainda pra saber se isso é só do 9.1. Não tenho o >> que reclamar do Freeba todos os meus servidores estão 100% estáveis. Só >> tive mesmo esses pipoucos estranhos em alguns testes e fiquei preocupado. >> >> Grande abraço à todos >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Por favor poste o resulta pois quero substituir um concentrador pppoe > mikrotik por freebsd. > A única coisa que ainda tá pegando é o
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 21/05/13 19:56, Bruno Araújo escreveu: > Em 21/05/2013, às 19:38, Marcelo Gondim escreveu: > >> Em 21/05/13 18:14, Renato Botelho escreveu: >>> On 05/21/2013 04:52 PM, Bruno Araújo wrote: Em 21/05/2013, às 16:32, Renato Botelho escreveu: > On 05/21/2013 04:28 PM, Marcelo Gondim wrote: >> Em 21/05/13 15:52, Renato Botelho escreveu: >>> On 05/21/2013 02:57 PM, vic wrote: Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: > EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! > mas > ele ainda é experimental e as panes são normais. > > isso tá bem documentado. > > eu acho que a dedicação agora esteja no bhyve (Acho que é assim que > escreve :p) > Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo esqueça de usar o pf ou algum módulo externo do FreeBSD (como o virtualbox por exemplo). Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último compilado mas não está em uso) e está funcionando à 128 dias sem parar e com 7 jails. >>> Ah sim, o fato de ser experimental não quer dizer que absolutamente não >>> irá funcionar. Serve mais pra te alertar que pode dar problema, que não >>> é estável. >>> >>> É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 >>> não está estável, sendo que ele optou por usar algo experimental. Quando >>> você faz essa escolha está sujeito as consequências :) >>> >>> []s >> Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava >> uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa data >> o bug. O uso do ntfs com leitura e escrita também dava um monte de >> kernel panic. Não sei agora como está. > OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por > conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do > kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. > >> Teve kernel panic que descobri também no geom mas esse foi corrigido >> rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer >> dump no /var/crash. Esse problema do crash vi alguns relatos também, que >> mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só uma >> preocupação que estou tendo. Todos os meus servidores em produção estão >> rodando muito bem e sem reboots. >> Meu medo é termos algo que aconteceu na versão 5.0, que eu não >> vivenciei, mas que muitos tiveram problemas. > Esses crashs estranhos e sem explicação são coisas que têm que ser > diagnosticadas, e em muitos casos no final o problema tá no hardware. > Sugiro habilitar debugs no kernel e ver se consegue algo. > > Sobre o que aconteceu no 5.0, foi uma história bem diferente, e acredito > que o time aprendeu com o erro, uma versão com tantas mudanças como > ocorreu do 4 pro 5 não deve acontecer mais. > Quando um mero pacote ou software derruba o S.O. não é uma falha grave do S.O? >>> Isso é relativo, o FUSE por exemplo é um pacote que compila um módulo de >>> kernel, não vejo o fato de um módulo de kernel derrubar o SO como algo >>> falho do SO. Mas fica difícil falar pois não tenho detalhes sobre os bugs. >>> >> Opa Renato, >> >> Esse lance do fuse depois que fiz um pr, rapidamente foi corrigido. Era >> um bug sinistro mesmo. Porque era só montar a partição ntfs e começar à >> copiar para dar um panic e o sistema reiniciar. Mas acho que pouca gente >> devia estar usando esse cara porque o panic era instantâneo mesmo. Bem >> esse foi resolvido rápido. >> Agora esse race condition que é brabo porque ele está lá em algum lugar >> e tipo não posso colocar um server e pendurar 4000 assinantes nele >> sabendo que se alguém na minha rede fizer um ataque de login incorreto >> por um certo tempo, vai causar um kernel panic derrubando os meus 4000 >> assinantes. Eu fiz uma atualização ontem no sistema e parece que não >> ocorreu mais mas ainda quero testar mais e ter certeza. >> Vou testar com o 8.3 ainda pra saber se isso é só do 9.1. Não tenho o >> que reclamar do Freeba todos os meus servidores estão 100% estáveis. Só >> tive mesmo esses pipoucos estranhos em alguns testes e fiquei preocupado. >> >> Grande abraço à todos >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Por favor poste o resulta pois quero substituir um concentrador pppoe > mikrotik por freebsd. > A única coisa que ainda tá pegando é o controle de tráfego dinâmico com pf + > mdp; o routeros está muito impreciso aqui. > > > ___ > Bruno Araújo > > Antes de imprimir, verifique se tem papel e tinta suficiente na impressora. > - > Histórico: http://www.fug.com.br/historico
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 21/05/2013, às 19:38, Marcelo Gondim escreveu: > Em 21/05/13 18:14, Renato Botelho escreveu: >> On 05/21/2013 04:52 PM, Bruno Araújo wrote: >>> Em 21/05/2013, às 16:32, Renato Botelho escreveu: >>> On 05/21/2013 04:28 PM, Marcelo Gondim wrote: > Em 21/05/13 15:52, Renato Botelho escreveu: >> On 05/21/2013 02:57 PM, vic wrote: >>> Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! mas ele ainda é experimental e as panes são normais. isso tá bem documentado. eu acho que a dedicação agora esteja no bhyve (Acho que é assim que escreve :p) >>> Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo >>> esqueça de usar o pf ou algum módulo externo do FreeBSD (como o >>> virtualbox por exemplo). >>> >>> Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último >>> compilado mas não está em uso) e está funcionando à 128 dias sem parar e >>> com 7 jails. >> Ah sim, o fato de ser experimental não quer dizer que absolutamente não >> irá funcionar. Serve mais pra te alertar que pode dar problema, que não >> é estável. >> >> É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 >> não está estável, sendo que ele optou por usar algo experimental. Quando >> você faz essa escolha está sujeito as consequências :) >> >> []s > Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava > uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa data > o bug. O uso do ntfs com leitura e escrita também dava um monte de > kernel panic. Não sei agora como está. OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. > Teve kernel panic que descobri também no geom mas esse foi corrigido > rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer > dump no /var/crash. Esse problema do crash vi alguns relatos também, que > mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só uma > preocupação que estou tendo. Todos os meus servidores em produção estão > rodando muito bem e sem reboots. > Meu medo é termos algo que aconteceu na versão 5.0, que eu não > vivenciei, mas que muitos tiveram problemas. Esses crashs estranhos e sem explicação são coisas que têm que ser diagnosticadas, e em muitos casos no final o problema tá no hardware. Sugiro habilitar debugs no kernel e ver se consegue algo. Sobre o que aconteceu no 5.0, foi uma história bem diferente, e acredito que o time aprendeu com o erro, uma versão com tantas mudanças como ocorreu do 4 pro 5 não deve acontecer mais. >>> Quando um mero pacote ou software derruba o S.O. não é uma falha grave do >>> S.O? >> Isso é relativo, o FUSE por exemplo é um pacote que compila um módulo de >> kernel, não vejo o fato de um módulo de kernel derrubar o SO como algo >> falho do SO. Mas fica difícil falar pois não tenho detalhes sobre os bugs. >> > Opa Renato, > > Esse lance do fuse depois que fiz um pr, rapidamente foi corrigido. Era > um bug sinistro mesmo. Porque era só montar a partição ntfs e começar à > copiar para dar um panic e o sistema reiniciar. Mas acho que pouca gente > devia estar usando esse cara porque o panic era instantâneo mesmo. Bem > esse foi resolvido rápido. > Agora esse race condition que é brabo porque ele está lá em algum lugar > e tipo não posso colocar um server e pendurar 4000 assinantes nele > sabendo que se alguém na minha rede fizer um ataque de login incorreto > por um certo tempo, vai causar um kernel panic derrubando os meus 4000 > assinantes. Eu fiz uma atualização ontem no sistema e parece que não > ocorreu mais mas ainda quero testar mais e ter certeza. > Vou testar com o 8.3 ainda pra saber se isso é só do 9.1. Não tenho o > que reclamar do Freeba todos os meus servidores estão 100% estáveis. Só > tive mesmo esses pipoucos estranhos em alguns testes e fiquei preocupado. > > Grande abraço à todos > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Por favor poste o resulta pois quero substituir um concentrador pppoe mikrotik por freebsd. A única coisa que ainda tá pegando é o controle de tráfego dinâmico com pf + mdp; o routeros está muito impreciso aqui. ___ Bruno Araújo Antes de imprimir, verifique se tem papel e tinta suficiente na impressora. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 21/05/13 18:14, Renato Botelho escreveu: > On 05/21/2013 04:52 PM, Bruno Araújo wrote: >> Em 21/05/2013, às 16:32, Renato Botelho escreveu: >> >>> On 05/21/2013 04:28 PM, Marcelo Gondim wrote: Em 21/05/13 15:52, Renato Botelho escreveu: > On 05/21/2013 02:57 PM, vic wrote: >> Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: >>> EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! >>> mas >>> ele ainda é experimental e as panes são normais. >>> >>> isso tá bem documentado. >>> >>> eu acho que a dedicação agora esteja no bhyve (Acho que é assim que >>> escreve :p) >>> >> Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo >> esqueça de usar o pf ou algum módulo externo do FreeBSD (como o >> virtualbox por exemplo). >> >> Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último >> compilado mas não está em uso) e está funcionando à 128 dias sem parar e >> com 7 jails. > Ah sim, o fato de ser experimental não quer dizer que absolutamente não > irá funcionar. Serve mais pra te alertar que pode dar problema, que não > é estável. > > É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 > não está estável, sendo que ele optou por usar algo experimental. Quando > você faz essa escolha está sujeito as consequências :) > > []s Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa data o bug. O uso do ntfs com leitura e escrita também dava um monte de kernel panic. Não sei agora como está. >>> OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por >>> conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do >>> kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. >>> Teve kernel panic que descobri também no geom mas esse foi corrigido rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer dump no /var/crash. Esse problema do crash vi alguns relatos também, que mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só uma preocupação que estou tendo. Todos os meus servidores em produção estão rodando muito bem e sem reboots. Meu medo é termos algo que aconteceu na versão 5.0, que eu não vivenciei, mas que muitos tiveram problemas. >>> Esses crashs estranhos e sem explicação são coisas que têm que ser >>> diagnosticadas, e em muitos casos no final o problema tá no hardware. >>> Sugiro habilitar debugs no kernel e ver se consegue algo. >>> >>> Sobre o que aconteceu no 5.0, foi uma história bem diferente, e acredito >>> que o time aprendeu com o erro, uma versão com tantas mudanças como >>> ocorreu do 4 pro 5 não deve acontecer mais. >>> >> Quando um mero pacote ou software derruba o S.O. não é uma falha grave do >> S.O? > Isso é relativo, o FUSE por exemplo é um pacote que compila um módulo de > kernel, não vejo o fato de um módulo de kernel derrubar o SO como algo > falho do SO. Mas fica difícil falar pois não tenho detalhes sobre os bugs. > Opa Renato, Esse lance do fuse depois que fiz um pr, rapidamente foi corrigido. Era um bug sinistro mesmo. Porque era só montar a partição ntfs e começar à copiar para dar um panic e o sistema reiniciar. Mas acho que pouca gente devia estar usando esse cara porque o panic era instantâneo mesmo. Bem esse foi resolvido rápido. Agora esse race condition que é brabo porque ele está lá em algum lugar e tipo não posso colocar um server e pendurar 4000 assinantes nele sabendo que se alguém na minha rede fizer um ataque de login incorreto por um certo tempo, vai causar um kernel panic derrubando os meus 4000 assinantes. Eu fiz uma atualização ontem no sistema e parece que não ocorreu mais mas ainda quero testar mais e ter certeza. Vou testar com o 8.3 ainda pra saber se isso é só do 9.1. Não tenho o que reclamar do Freeba todos os meus servidores estão 100% estáveis. Só tive mesmo esses pipoucos estranhos em alguns testes e fiquei preocupado. Grande abraço à todos - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Suporte a CUDA
On 21/05/2013 13:48, Nilton Jose Rizzo wrote: > Em Tue, 21 May 2013 08:39:17 -0300, Otacílio escreveu >> Oi pessoal. >> >> As últimas versões do OpenCV utilizam o suporte a CUDA. Alguém sabe >> se este funciona de alguma forma no FreeBSD? > > Estou as voltas com isso tbm Otacílio, mas tenho uma esperança, que o > OpenGL 4.3 venha a ser portado logo para o Free, pois não precisaríamos > nos preocupar com cuda ou OpenCV, uma vez que ele implementa em alto nível > essas funcionalidades. > O OpenGL 4.3 vai ter suporte a visão computacional? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 21-05-2013 16:52, Bruno Araújo escreveu: Em 21/05/2013, às 16:32, Renato Botelho escreveu: On 05/21/2013 04:28 PM, Marcelo Gondim wrote: Em 21/05/13 15:52, Renato Botelho escreveu: On 05/21/2013 02:57 PM, vic wrote: Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: * Renato Botelho (rbga...@gmail.com) wrote: Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Isso mesmo Indio, confundi com a jail em si mas é o vimage. :) Posso estar enganado, mas até onde sei o VIMAGE é considerado experimental, não é? EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! mas ele ainda é experimental e as panes são normais. isso tá bem documentado. eu acho que a dedicação agora esteja no bhyve (Acho que é assim que escreve :p) Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo esqueça de usar o pf ou algum módulo externo do FreeBSD (como o virtualbox por exemplo). Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último compilado mas não está em uso) e está funcionando à 128 dias sem parar e com 7 jails. Ah sim, o fato de ser experimental não quer dizer que absolutamente não irá funcionar. Serve mais pra te alertar que pode dar problema, que não é estável. É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 não está estável, sendo que ele optou por usar algo experimental. Quando você faz essa escolha está sujeito as consequências :) []s Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa data o bug. O uso do ntfs com leitura e escrita também dava um monte de kernel panic. Não sei agora como está. OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. Teve kernel panic que descobri também no geom mas esse foi corrigido rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer dump no /var/crash. Esse problema do crash vi alguns relatos também, que mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só uma preocupação que estou tendo. Todos os meus servidores em produção estão rodando muito bem e sem reboots. Meu medo é termos algo que aconteceu na versão 5.0, que eu não vivenciei, mas que muitos tiveram problemas. Esses crashs estranhos e sem explicação são coisas que têm que ser diagnosticadas, e em muitos casos no final o problema tá no hardware. Sugiro habilitar debugs no kernel e ver se consegue algo. Sobre o que aconteceu no 5.0, foi uma história bem diferente, e acredito que o time aprendeu com o erro, uma versão com tantas mudanças como ocorreu do 4 pro 5 não deve acontecer mais. -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Quando um mero pacote ou software derruba o S.O. não é uma falha grave do S.O? ___ Bruno Araújo Antes de imprimir, verifique se tem papel e tinta suficiente na impressora. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Colegas, Vou falar um pouco da experiência que vivencio aqui com FreeBSD de diversas versões sem flames espero... O FreeBSD é um sistema que vem incorporando diversas mudanças tecnológicas como suporte a GPU, SMP de verdade, ZFS, dentre tantos outros conhecidos aqui... Isso significa que o FreeBSD está na vanguarda e quem está neste estágio corre alguns riscos, experimentando algumas novidades. Aí é o q entra o papel da comunidade que é testar, avaliar, coletar informações e reportar aos desenvolvedores que certamente como sempre darão o melhor de si para corrigir e acertar. Este é o ciclo de desenvolvimento e temos que respeitar suas limitações, sejam de recursos humanos, físicos, financeiros dentre tantos outros. E aí temos que agir com bom senso como bons administradores de rede... Fico tentado as vezes a migrar para usar a versão 9.. Leio em detalhes /usr/src/UPDATING, comparo, venho na lista e vejo o que os colegas estão fazendo, mas vejo que as vezes é melhor ser conservador e não sair sequer da 8.2... E as vezes vou de 9-CURRENT pra atender uma demanda específica mesmo sendo alertado sobre algo EXPERIMENTAL. Temos as melhores e mais estáveis ferramentas disponíveis em termos de sistema operacional senão a melhor delas...O desafio é fazer o melhor uso delas e para isso temos que saber fazer as escolhas certas. PF + ALTQ + Placa Intel ( driver em ) no meu caso funciona muito bem mas ainda estou na 8.2 e vou ficar com ela ainda por um bom tempo porque disponibilidade pra mim é a chave do meu negócio. e olhe que ainda ouso usando FLOWTABLE, CPU AFFinity dentre outras coisas interessantes do FreeBSD
Re: [FUG-BR] ALTQ + Intel Drivers.
On 05/21/2013 04:52 PM, Bruno Araújo wrote: > Em 21/05/2013, às 16:32, Renato Botelho escreveu: > >> On 05/21/2013 04:28 PM, Marcelo Gondim wrote: >>> Em 21/05/13 15:52, Renato Botelho escreveu: On 05/21/2013 02:57 PM, vic wrote: > Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: >> EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! >> mas >> ele ainda é experimental e as panes são normais. >> >> isso tá bem documentado. >> >> eu acho que a dedicação agora esteja no bhyve (Acho que é assim que >> escreve :p) >> > Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo > esqueça de usar o pf ou algum módulo externo do FreeBSD (como o > virtualbox por exemplo). > > Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último > compilado mas não está em uso) e está funcionando à 128 dias sem parar e > com 7 jails. Ah sim, o fato de ser experimental não quer dizer que absolutamente não irá funcionar. Serve mais pra te alertar que pode dar problema, que não é estável. É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 não está estável, sendo que ele optou por usar algo experimental. Quando você faz essa escolha está sujeito as consequências :) []s >>> Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava >>> uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa data >>> o bug. O uso do ntfs com leitura e escrita também dava um monte de >>> kernel panic. Não sei agora como está. >> >> OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por >> conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do >> kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. >> >>> Teve kernel panic que descobri também no geom mas esse foi corrigido >>> rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer >>> dump no /var/crash. Esse problema do crash vi alguns relatos também, que >>> mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só uma >>> preocupação que estou tendo. Todos os meus servidores em produção estão >>> rodando muito bem e sem reboots. >>> Meu medo é termos algo que aconteceu na versão 5.0, que eu não >>> vivenciei, mas que muitos tiveram problemas. >> >> Esses crashs estranhos e sem explicação são coisas que têm que ser >> diagnosticadas, e em muitos casos no final o problema tá no hardware. >> Sugiro habilitar debugs no kernel e ver se consegue algo. >> >> Sobre o que aconteceu no 5.0, foi uma história bem diferente, e acredito >> que o time aprendeu com o erro, uma versão com tantas mudanças como >> ocorreu do 4 pro 5 não deve acontecer mais. >> > > Quando um mero pacote ou software derruba o S.O. não é uma falha grave do S.O? Isso é relativo, o FUSE por exemplo é um pacote que compila um módulo de kernel, não vejo o fato de um módulo de kernel derrubar o SO como algo falho do SO. Mas fica difícil falar pois não tenho detalhes sobre os bugs. -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 21/05/2013, às 16:32, Renato Botelho escreveu: > On 05/21/2013 04:28 PM, Marcelo Gondim wrote: >> Em 21/05/13 15:52, Renato Botelho escreveu: >>> On 05/21/2013 02:57 PM, vic wrote: Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: > * Renato Botelho (rbga...@gmail.com) wrote: Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> Isso mesmo Indio, confundi com a jail em si mas é o vimage. :) >> Posso estar enganado, mas até onde sei o VIMAGE é considerado >> experimental, não é? >> > EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! > mas > ele ainda é experimental e as panes são normais. > > isso tá bem documentado. > > eu acho que a dedicação agora esteja no bhyve (Acho que é assim que > escreve :p) > Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo esqueça de usar o pf ou algum módulo externo do FreeBSD (como o virtualbox por exemplo). Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último compilado mas não está em uso) e está funcionando à 128 dias sem parar e com 7 jails. >>> Ah sim, o fato de ser experimental não quer dizer que absolutamente não >>> irá funcionar. Serve mais pra te alertar que pode dar problema, que não >>> é estável. >>> >>> É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 >>> não está estável, sendo que ele optou por usar algo experimental. Quando >>> você faz essa escolha está sujeito as consequências :) >>> >>> []s >> Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava >> uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa data >> o bug. O uso do ntfs com leitura e escrita também dava um monte de >> kernel panic. Não sei agora como está. > > OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por > conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do > kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. > >> Teve kernel panic que descobri também no geom mas esse foi corrigido >> rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer >> dump no /var/crash. Esse problema do crash vi alguns relatos também, que >> mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só uma >> preocupação que estou tendo. Todos os meus servidores em produção estão >> rodando muito bem e sem reboots. >> Meu medo é termos algo que aconteceu na versão 5.0, que eu não >> vivenciei, mas que muitos tiveram problemas. > > Esses crashs estranhos e sem explicação são coisas que têm que ser > diagnosticadas, e em muitos casos no final o problema tá no hardware. > Sugiro habilitar debugs no kernel e ver se consegue algo. > > Sobre o que aconteceu no 5.0, foi uma história bem diferente, e acredito > que o time aprendeu com o erro, uma versão com tantas mudanças como > ocorreu do 4 pro 5 não deve acontecer mais. > > -- > Renato Botelho > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Quando um mero pacote ou software derruba o S.O. não é uma falha grave do S.O? ___ Bruno Araújo Antes de imprimir, verifique se tem papel e tinta suficiente na impressora. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
On 05/21/2013 04:28 PM, Marcelo Gondim wrote: > Em 21/05/13 15:52, Renato Botelho escreveu: >> On 05/21/2013 02:57 PM, vic wrote: >>> Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: * Renato Botelho (rbga...@gmail.com) wrote: >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> Isso mesmo Indio, confundi com a jail em si mas é o vimage. :) > Posso estar enganado, mas até onde sei o VIMAGE é considerado > experimental, não é? > EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! mas ele ainda é experimental e as panes são normais. isso tá bem documentado. eu acho que a dedicação agora esteja no bhyve (Acho que é assim que escreve :p) >>> Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo >>> esqueça de usar o pf ou algum módulo externo do FreeBSD (como o >>> virtualbox por exemplo). >>> >>> Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último >>> compilado mas não está em uso) e está funcionando à 128 dias sem parar e >>> com 7 jails. >> Ah sim, o fato de ser experimental não quer dizer que absolutamente não >> irá funcionar. Serve mais pra te alertar que pode dar problema, que não >> é estável. >> >> É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 >> não está estável, sendo que ele optou por usar algo experimental. Quando >> você faz essa escolha está sujeito as consequências :) >> >> []s > Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava > uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa data > o bug. O uso do ntfs com leitura e escrita também dava um monte de > kernel panic. Não sei agora como está. OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. > Teve kernel panic que descobri também no geom mas esse foi corrigido > rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer > dump no /var/crash. Esse problema do crash vi alguns relatos também, que > mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só uma > preocupação que estou tendo. Todos os meus servidores em produção estão > rodando muito bem e sem reboots. > Meu medo é termos algo que aconteceu na versão 5.0, que eu não > vivenciei, mas que muitos tiveram problemas. Esses crashs estranhos e sem explicação são coisas que têm que ser diagnosticadas, e em muitos casos no final o problema tá no hardware. Sugiro habilitar debugs no kernel e ver se consegue algo. Sobre o que aconteceu no 5.0, foi uma história bem diferente, e acredito que o time aprendeu com o erro, uma versão com tantas mudanças como ocorreu do 4 pro 5 não deve acontecer mais. -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 21/05/13 15:52, Renato Botelho escreveu: > On 05/21/2013 02:57 PM, vic wrote: >> Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: >>> * Renato Botelho (rbga...@gmail.com) wrote: >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > Isso mesmo Indio, confundi com a jail em si mas é o vimage. :) Posso estar enganado, mas até onde sei o VIMAGE é considerado experimental, não é? >>> EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! >>> mas >>> ele ainda é experimental e as panes são normais. >>> >>> isso tá bem documentado. >>> >>> eu acho que a dedicação agora esteja no bhyve (Acho que é assim que >>> escreve :p) >>> >> Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo >> esqueça de usar o pf ou algum módulo externo do FreeBSD (como o >> virtualbox por exemplo). >> >> Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último >> compilado mas não está em uso) e está funcionando à 128 dias sem parar e >> com 7 jails. > Ah sim, o fato de ser experimental não quer dizer que absolutamente não > irá funcionar. Serve mais pra te alertar que pode dar problema, que não > é estável. > > É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 > não está estável, sendo que ele optou por usar algo experimental. Quando > você faz essa escolha está sujeito as consequências :) > > []s Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa data o bug. O uso do ntfs com leitura e escrita também dava um monte de kernel panic. Não sei agora como está. Teve kernel panic que descobri também no geom mas esse foi corrigido rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer dump no /var/crash. Esse problema do crash vi alguns relatos também, que mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só uma preocupação que estou tendo. Todos os meus servidores em produção estão rodando muito bem e sem reboots. Meu medo é termos algo que aconteceu na versão 5.0, que eu não vivenciei, mas que muitos tiveram problemas. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 2013-05-21 15:52, Renato Botelho escreveu: > On 05/21/2013 02:57 PM, vic wrote: >> Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: >>> * Renato Botelho (rbga...@gmail.com) wrote: >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > Isso mesmo Indio, confundi com a jail em si mas é o vimage. :) Posso estar enganado, mas até onde sei o VIMAGE é considerado experimental, não é? >>> >>> EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! >>> mas >>> ele ainda é experimental e as panes são normais. >>> >>> isso tá bem documentado. >>> >>> eu acho que a dedicação agora esteja no bhyve (Acho que é assim que >>> escreve :p) >>> >> >> Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo >> esqueça de usar o pf ou algum módulo externo do FreeBSD (como o >> virtualbox por exemplo). >> >> Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último >> compilado mas não está em uso) e está funcionando à 128 dias sem >> parar e >> com 7 jails. > > Ah sim, o fato de ser experimental não quer dizer que absolutamente > não > irá funcionar. Serve mais pra te alertar que pode dar problema, que > não > é estável. > > É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 > não está estável, sendo que ele optou por usar algo experimental. > Quando > você faz essa escolha está sujeito as consequências :) > > []s Eu concordo. Apenas quis deixar registrado que estou tendo uma experiência positiva com o VIMAGE apenas tomando alguns cuidados. -- vic http://choppnerd.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
On 05/21/2013 02:57 PM, vic wrote: > Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: >> * Renato Botelho (rbga...@gmail.com) wrote: > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Isso mesmo Indio, confundi com a jail em si mas é o vimage. :) >>> >>> Posso estar enganado, mas até onde sei o VIMAGE é considerado >>> experimental, não é? >>> >> >> EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! >> mas >> ele ainda é experimental e as panes são normais. >> >> isso tá bem documentado. >> >> eu acho que a dedicação agora esteja no bhyve (Acho que é assim que >> escreve :p) >> > > Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo > esqueça de usar o pf ou algum módulo externo do FreeBSD (como o > virtualbox por exemplo). > > Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último > compilado mas não está em uso) e está funcionando à 128 dias sem parar e > com 7 jails. Ah sim, o fato de ser experimental não quer dizer que absolutamente não irá funcionar. Serve mais pra te alertar que pode dar problema, que não é estável. É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD 9.1 não está estável, sendo que ele optou por usar algo experimental. Quando você faz essa escolha está sujeito as consequências :) []s -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: > * Renato Botelho (rbga...@gmail.com) wrote: Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> Isso mesmo Indio, confundi com a jail em si mas é o vimage. :) >> >> Posso estar enganado, mas até onde sei o VIMAGE é considerado >> experimental, não é? >> >> -- >> Renato Botelho > > EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! > mas > ele ainda é experimental e as panes são normais. > > isso tá bem documentado. > > eu acho que a dedicação agora esteja no bhyve (Acho que é assim que > escreve :p) > > --- > Luiz Gustavo Costa (Powered by BSD) > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ > mundoUnix - Consultoria em Software Livre > http://www.mundounix.com.br > ICQ: 2890831 / MSN: cont...@mundounix.com.br > Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 > Blog: http://www.luizgustavo.pro.br > - Sim, é experimental, mas eu tenho usado com sucesso o vimage. Contudo esqueça de usar o pf ou algum módulo externo do FreeBSD (como o virtualbox por exemplo). Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último compilado mas não está em uso) e está funcionando à 128 dias sem parar e com 7 jails. -- vic http://choppnerd.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Suporte a CUDA
Em Tue, 21 May 2013 08:39:17 -0300, Otacílio escreveu > Oi pessoal. > > As últimas versões do OpenCV utilizam o suporte a CUDA. Alguém sabe > se este funciona de alguma forma no FreeBSD? Estou as voltas com isso tbm Otacílio, mas tenho uma esperança, que o OpenGL 4.3 venha a ser portado logo para o Free, pois não precisaríamos nos preocupar com cuda ou OpenCV, uma vez que ele implementa em alto nível essas funcionalidades. Rizzo > > []'s > -Otacílio > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] erro de compilação do driver Nvid ia - GeForce Go 7 series (notebook)
Em Mon, 20 May 2013 15:26:52 -0300, Ricardo Carlini Sperandio escreveu > Em 20-05-2013 14:38, Ricardo Tweeg escreveu: > > /usr/X11R6/lib/modules/drivers: No such file or directory > Esse é o caminho do erro... Falta o pacote de devel do X11. Na versão do FreeBSD 9.x achoi que nãoesiste mais esse diretorio tbm estou longe de um BSD mas acho que é isso mesmo Rizzo > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Hardware to virtualization.
Em 20 de maio de 2013 16:26, Elias Motta escreveu: > Boa tarde Lista, > > Dias atras os colegas trocaram ideia a respeito de hardware pra > virtualização ESXi, alguns sugeriram motherboard Supermicro que vai bem com > FreeBSD. Gostaria de sugestão de onde comprar essa marca aqui no brasil. > > Obs. sou do RS. > > > Elias Motta > TI - Engemolde > 3597.2033 | 3597.8802 > t...@engemoldeengenharia.com.br Dell funciona muito bem com ESXi (até mesmo os modelos mais básicos como T300, T4xx, etc.). Welkson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
* Renato Botelho (rbga...@gmail.com) wrote: > >> Histórico: http://www.fug.com.br/historico/html/freebsd/ > >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > >> > > Isso mesmo Indio, confundi com a jail em si mas é o vimage. :) > > Posso estar enganado, mas até onde sei o VIMAGE é considerado > experimental, não é? > > -- > Renato Botelho EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% !! mas ele ainda é experimental e as panes são normais. isso tá bem documentado. eu acho que a dedicação agora esteja no bhyve (Acho que é assim que escreve :p) --- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
On 05/21/2013 11:47 AM, Marcelo Gondim wrote: > Em 21/05/13 11:25, Claudio Pereira escreveu: >> 2013/5/21 Marcelo Gondim >> >>> Em 21/05/13 08:21, Renato Botelho escreveu: 2013/5/21 Marcelo Gondim : > Em 21/05/13 07:56, Marcelo Araujo escreveu: >> Opa Povo, >> >> Gostaria de saber se existe alguém usando ALTQ com placas Intel, pode >>> ser >> ixgbe, gbe ou em. Até onde eu estou sabendo no FreeBSD 9.1-RELEASE esta >> tudo quebrado, ALTQ não funciona com as placas Intel. >> >> Caso alguém esteja usando com sucesso, favor responder usando o >>> comando: >> "pfctl -vvsr", "pfctl -vvsq" e também "uname -a" >> >> >> Grande Abraço. > Opa Marcelo, > > Não sei te dizer se é verdade mas ultimamente tenho encontrado algumas > instabilidades no 9.1-STABLE, isso até me preocupa pois o FreeBSD para > mim sempre foi um sistema robusto nesses poucos anos que tenho usado. > Atualmente estou fazendo testes com o FreeBSD 9.1-STABLE como > concentrador PPPoE utilizando o mpd + freeradius + mysql. Fiz algumas > simulações de diversas conexões simultâneas e foi muito bem. A coisa só > ficou ruim quando resolvi fazer um DoS no mpd gerando muitas conexões de > usuários inválidos, coisa que qualquer um na minha rede poderia fazer > conforme vou mostrar abaixo. O pior é que o resultado foram muitos mas > muitos kernel panics usando interfaces de rede Intel gigabit server > (igb) e o mesmo ocorreu em menor quantidade com Intel gigabit server > usando driver (em). > Troquei o hardware de todas as formas desde motherboards, memórias até o > disco, mas os kernel panics continuavam. > Estou tendo a péssima impressão que a qualidade do código está caindo. > Tipo vai testar jail com carp se eu não me engano e dá pau. OSPF tem uns > paus, vai montar sistemas de arquivos ntfs como leitura/escrita mais > paus. Fui testar o concentrador PPPoE e pau. Vou tentar usar a versão > 8.3-STABLE mas fico preocupado em como um código que deveria estar mais > estável com o passar do tempo, agora parece quebrado como o Marcelo > disse. Temos recursos novos na série 9? Temos, show mas eles deveriam > estar bem testados antes de serem liberados. > Quem quiser fazer os testes que fiz com o freebsd 9.1 + mpd + freeradius > + mysql vou fazer uma nova thread com os meus arquivos. Oi Marcelo, Eu não to sabendo desses possíveis problemas na série 9, mas assim, você reportou pros desenvolvedores os problemas que encontrou? Tentou olhar o histórico da lista freebsd-stable pra ver se mais pessoas estão com o >>> mesmo problema? A qualidade de um código só pode ser melhorada se houver report dos problemas pelos usuários, só assim eles podem ser corrigidos. >>> >> Salve Marcelo's, =) >> >> Um dos problemas no 9.1, é o carp + vimage, apenas um ping e a máquina >> desliga, nem chega a mostrar kernel panic. >> >> Abraços, ÍndioX >> -- >> Claudio P Costa >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > Isso mesmo Indio, confundi com a jail em si mas é o vimage. :) Posso estar enganado, mas até onde sei o VIMAGE é considerado experimental, não é? -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] freebsd 9.1 + mpd + freeradius + mysql + DoS = panic
Em 21/05/13 11:20, Edinilson - ATINET escreveu: > - Original Message - >> From: "Otacílio" >> To: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" >> >> Sent: Tuesday, May 21, 2013 9:08 AM >> Subject: Re: [FUG-BR] freebsd 9.1 + mpd + freeradius + mysql + DoS = panic > >> On 21/05/2013 08:41, Marcelo Gondim wrote: >> Mandei e-mail para a lista freebsd-stable e a última resposta que obtive >> pelo Adrian Chadd: >> >> No idea. Its likely there; jsut a different kind of race condition. :( >> >> Brabo mesmo. :( >> - >> Race condition, não existe nada mais medonho do que depurar um problema >> deste tipo... > Tive um problema com race condition na versao 5.xx do Freebsd. Tanto que > tive que esperar e migrar da 4.8 direto para a 6.1. > Um simples: > arp -a -d > causava o kernel panic DE IMEDIATO. > > O seu problema PARECE que é algo relacionado a criação de pipes do dummynet. > Tem como colocar, no script de login, um delay entre o login de um usuario e > outro só para testar? > Um outro teste que tambem faria seria utilizar a versao i386 (só para > testes, claro). > > > Edinilson > -- > ATINET > Tel Voz: (0xx11) 4412-0876 > http://www.atinet.com.br > > Opa Edinilson, Vou colocar um sleep para teste mas mesmo assim uma falha como essa, ficamos vulneráveis à um ataque de DoS. :( - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 21/05/13 11:25, Claudio Pereira escreveu: > 2013/5/21 Marcelo Gondim > >> Em 21/05/13 08:21, Renato Botelho escreveu: >>> 2013/5/21 Marcelo Gondim : Em 21/05/13 07:56, Marcelo Araujo escreveu: > Opa Povo, > > Gostaria de saber se existe alguém usando ALTQ com placas Intel, pode >> ser > ixgbe, gbe ou em. Até onde eu estou sabendo no FreeBSD 9.1-RELEASE esta > tudo quebrado, ALTQ não funciona com as placas Intel. > > Caso alguém esteja usando com sucesso, favor responder usando o >> comando: > "pfctl -vvsr", "pfctl -vvsq" e também "uname -a" > > > Grande Abraço. Opa Marcelo, Não sei te dizer se é verdade mas ultimamente tenho encontrado algumas instabilidades no 9.1-STABLE, isso até me preocupa pois o FreeBSD para mim sempre foi um sistema robusto nesses poucos anos que tenho usado. Atualmente estou fazendo testes com o FreeBSD 9.1-STABLE como concentrador PPPoE utilizando o mpd + freeradius + mysql. Fiz algumas simulações de diversas conexões simultâneas e foi muito bem. A coisa só ficou ruim quando resolvi fazer um DoS no mpd gerando muitas conexões de usuários inválidos, coisa que qualquer um na minha rede poderia fazer conforme vou mostrar abaixo. O pior é que o resultado foram muitos mas muitos kernel panics usando interfaces de rede Intel gigabit server (igb) e o mesmo ocorreu em menor quantidade com Intel gigabit server usando driver (em). Troquei o hardware de todas as formas desde motherboards, memórias até o disco, mas os kernel panics continuavam. Estou tendo a péssima impressão que a qualidade do código está caindo. Tipo vai testar jail com carp se eu não me engano e dá pau. OSPF tem uns paus, vai montar sistemas de arquivos ntfs como leitura/escrita mais paus. Fui testar o concentrador PPPoE e pau. Vou tentar usar a versão 8.3-STABLE mas fico preocupado em como um código que deveria estar mais estável com o passar do tempo, agora parece quebrado como o Marcelo disse. Temos recursos novos na série 9? Temos, show mas eles deveriam estar bem testados antes de serem liberados. Quem quiser fazer os testes que fiz com o freebsd 9.1 + mpd + freeradius + mysql vou fazer uma nova thread com os meus arquivos. >>> Oi Marcelo, >>> >>> Eu não to sabendo desses possíveis problemas na série 9, mas assim, você >>> reportou pros desenvolvedores os problemas que encontrou? Tentou olhar o >>> histórico da lista freebsd-stable pra ver se mais pessoas estão com o >> mesmo >>> problema? A qualidade de um código só pode ser melhorada se houver report >>> dos problemas pelos usuários, só assim eles podem ser corrigidos. >> > Salve Marcelo's, =) > > Um dos problemas no 9.1, é o carp + vimage, apenas um ping e a máquina > desliga, nem chega a mostrar kernel panic. > > Abraços, ÍndioX > -- > Claudio P Costa > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Isso mesmo Indio, confundi com a jail em si mas é o vimage. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
2013/5/21 Marcelo Gondim > Em 21/05/13 08:21, Renato Botelho escreveu: > > 2013/5/21 Marcelo Gondim : > >> Em 21/05/13 07:56, Marcelo Araujo escreveu: > >>> Opa Povo, > >>> > >>> Gostaria de saber se existe alguém usando ALTQ com placas Intel, pode > ser > >>> ixgbe, gbe ou em. Até onde eu estou sabendo no FreeBSD 9.1-RELEASE esta > >>> tudo quebrado, ALTQ não funciona com as placas Intel. > >>> > >>> Caso alguém esteja usando com sucesso, favor responder usando o > comando: > >>> > >>> "pfctl -vvsr", "pfctl -vvsq" e também "uname -a" > >>> > >>> > >>> Grande Abraço. > >> Opa Marcelo, > >> > >> Não sei te dizer se é verdade mas ultimamente tenho encontrado algumas > >> instabilidades no 9.1-STABLE, isso até me preocupa pois o FreeBSD para > >> mim sempre foi um sistema robusto nesses poucos anos que tenho usado. > >> Atualmente estou fazendo testes com o FreeBSD 9.1-STABLE como > >> concentrador PPPoE utilizando o mpd + freeradius + mysql. Fiz algumas > >> simulações de diversas conexões simultâneas e foi muito bem. A coisa só > >> ficou ruim quando resolvi fazer um DoS no mpd gerando muitas conexões de > >> usuários inválidos, coisa que qualquer um na minha rede poderia fazer > >> conforme vou mostrar abaixo. O pior é que o resultado foram muitos mas > >> muitos kernel panics usando interfaces de rede Intel gigabit server > >> (igb) e o mesmo ocorreu em menor quantidade com Intel gigabit server > >> usando driver (em). > >> Troquei o hardware de todas as formas desde motherboards, memórias até o > >> disco, mas os kernel panics continuavam. > >> Estou tendo a péssima impressão que a qualidade do código está caindo. > >> Tipo vai testar jail com carp se eu não me engano e dá pau. OSPF tem uns > >> paus, vai montar sistemas de arquivos ntfs como leitura/escrita mais > >> paus. Fui testar o concentrador PPPoE e pau. Vou tentar usar a versão > >> 8.3-STABLE mas fico preocupado em como um código que deveria estar mais > >> estável com o passar do tempo, agora parece quebrado como o Marcelo > >> disse. Temos recursos novos na série 9? Temos, show mas eles deveriam > >> estar bem testados antes de serem liberados. > >> Quem quiser fazer os testes que fiz com o freebsd 9.1 + mpd + freeradius > >> + mysql vou fazer uma nova thread com os meus arquivos. > > Oi Marcelo, > > > > Eu não to sabendo desses possíveis problemas na série 9, mas assim, você > > reportou pros desenvolvedores os problemas que encontrou? Tentou olhar o > > histórico da lista freebsd-stable pra ver se mais pessoas estão com o > mesmo > > problema? A qualidade de um código só pode ser melhorada se houver report > > dos problemas pelos usuários, só assim eles podem ser corrigidos. > > Salve Marcelo's, =) Um dos problemas no 9.1, é o carp + vimage, apenas um ping e a máquina desliga, nem chega a mostrar kernel panic. Abraços, ÍndioX -- Claudio P Costa - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] freebsd 9.1 + mpd + freeradius + mysql + DoS = panic
- Original Message - >From: "Otacílio" >To: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" > >Sent: Tuesday, May 21, 2013 9:08 AM >Subject: Re: [FUG-BR] freebsd 9.1 + mpd + freeradius + mysql + DoS = panic >On 21/05/2013 08:41, Marcelo Gondim wrote: > Mandei e-mail para a lista freebsd-stable e a última resposta que obtive > pelo Adrian Chadd: > > No idea. Its likely there; jsut a different kind of race condition. :( > > Brabo mesmo. :( > - >Race condition, não existe nada mais medonho do que depurar um problema >deste tipo... Tive um problema com race condition na versao 5.xx do Freebsd. Tanto que tive que esperar e migrar da 4.8 direto para a 6.1. Um simples: arp -a -d causava o kernel panic DE IMEDIATO. O seu problema PARECE que é algo relacionado a criação de pipes do dummynet. Tem como colocar, no script de login, um delay entre o login de um usuario e outro só para testar? Um outro teste que tambem faria seria utilizar a versao i386 (só para testes, claro). Edinilson -- ATINET Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] erro de compilação do driver Nvidia - GeForce Go 7 series (notebook)
> > De: Ricardo Carlini Sperandio >Para: freebsd@fug.com.br >Enviadas: Segunda-feira, 20 de Maio de 2013 15:26 >Assunto: Re: [FUG-BR] erro de compilação do driver Nvidia - GeForce Go 7 >series (notebook) > > >Em 20-05-2013 14:38, Ricardo Tweeg escreveu: >> /usr/X11R6/lib/modules/drivers: No such file or directory >Esse é o caminho do erro... Falta o pacote de devel do X11. > > >- >Histórico: http://www.fug.com.br/historico/html/freebsd/ >Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > Obrigado pela ajuda no entendimento Ricardo. Forte abraço meu camarada. Atenciosamente, Ricardo Tweeg Novell Certified Linux Administrator - NCLA Linux Professional Institute - LPIC-1 SUSE 11 Tech Spec Certified DC Tech Spec Certified CompTia Linux+ +55 021 9291-0584 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] freebsd 9.1 + mpd + freeradius + mysql + DoS = panic
On 21/05/2013 08:41, Marcelo Gondim wrote: > Mandei e-mail para a lista freebsd-stable e a última resposta que obtive > pelo Adrian Chadd: > > No idea. Its likely there; jsut a different kind of race condition. :( > > Brabo mesmo. :( > - Race condition, não existe nada mais medonho do que depurar um problema deste tipo... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 21/05/13 08:21, Renato Botelho escreveu: > 2013/5/21 Marcelo Gondim : >> Em 21/05/13 07:56, Marcelo Araujo escreveu: >>> Opa Povo, >>> >>> Gostaria de saber se existe alguém usando ALTQ com placas Intel, pode ser >>> ixgbe, gbe ou em. Até onde eu estou sabendo no FreeBSD 9.1-RELEASE esta >>> tudo quebrado, ALTQ não funciona com as placas Intel. >>> >>> Caso alguém esteja usando com sucesso, favor responder usando o comando: >>> >>> "pfctl -vvsr", "pfctl -vvsq" e também "uname -a" >>> >>> >>> Grande Abraço. >> Opa Marcelo, >> >> Não sei te dizer se é verdade mas ultimamente tenho encontrado algumas >> instabilidades no 9.1-STABLE, isso até me preocupa pois o FreeBSD para >> mim sempre foi um sistema robusto nesses poucos anos que tenho usado. >> Atualmente estou fazendo testes com o FreeBSD 9.1-STABLE como >> concentrador PPPoE utilizando o mpd + freeradius + mysql. Fiz algumas >> simulações de diversas conexões simultâneas e foi muito bem. A coisa só >> ficou ruim quando resolvi fazer um DoS no mpd gerando muitas conexões de >> usuários inválidos, coisa que qualquer um na minha rede poderia fazer >> conforme vou mostrar abaixo. O pior é que o resultado foram muitos mas >> muitos kernel panics usando interfaces de rede Intel gigabit server >> (igb) e o mesmo ocorreu em menor quantidade com Intel gigabit server >> usando driver (em). >> Troquei o hardware de todas as formas desde motherboards, memórias até o >> disco, mas os kernel panics continuavam. >> Estou tendo a péssima impressão que a qualidade do código está caindo. >> Tipo vai testar jail com carp se eu não me engano e dá pau. OSPF tem uns >> paus, vai montar sistemas de arquivos ntfs como leitura/escrita mais >> paus. Fui testar o concentrador PPPoE e pau. Vou tentar usar a versão >> 8.3-STABLE mas fico preocupado em como um código que deveria estar mais >> estável com o passar do tempo, agora parece quebrado como o Marcelo >> disse. Temos recursos novos na série 9? Temos, show mas eles deveriam >> estar bem testados antes de serem liberados. >> Quem quiser fazer os testes que fiz com o freebsd 9.1 + mpd + freeradius >> + mysql vou fazer uma nova thread com os meus arquivos. > Oi Marcelo, > > Eu não to sabendo desses possíveis problemas na série 9, mas assim, você > reportou pros desenvolvedores os problemas que encontrou? Tentou olhar o > histórico da lista freebsd-stable pra ver se mais pessoas estão com o mesmo > problema? A qualidade de um código só pode ser melhorada se houver report > dos problemas pelos usuários, só assim eles podem ser corrigidos. > Opa Renato, Sim sim eu sempre reporto e até comento na freebsd-stable. Alguns desses que comentei já são até conhecidos por todos. Já tive inclusive bugs reportados e consertados rapidamente. O que me preocupa são as inclusões de recursos novos e o mesmos causarem instabilidade no código que já existia e era estável. Fiz uma nova thread relatando o problema com o mpd + freeradius + mysql. :) Abração, - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] freebsd 9.1 + mpd + freeradius + mysql + DoS = panic
Pessoal,
Conforme coloquei em outra mensagem aqui vão minhas configurações e
script de teste. O kernel panic não é rápido mas depois de algumas horas
de ataque o panic vem e vem lindo: http://pastebin.com/nUXGVR3y
Meu mpd.conf:
startup:
# configure mpd users
#set user foo bar admin
set user suporte papatango
set user admin tutumineiro admin
# configure the console
set console self 192.168.8.34 5005
set console open
# configure the web server
set web self 0.0.0.0 5006
set web open
default:
load pppoe_server
pppoe_server:
create bundle template B
set iface disable proxy-arp
set iface enable tcpmssfix
set ipcp dns 8.8.8.8 8.8.4.4
#set ipcp enable vjcomp
set iface up-script /usr/local/etc/mpd5/addclient.sh
set iface down-script /usr/local/etc/mpd5/removeclient.sh
set ippool add pool1 10.10.0.1 10.10.255.254
set ipcp ranges 10.51.0.1/32 ippool pool1
create link template common pppoe
#set link enable multilink
set link action bundle B
set link disable chap pap eap
set link mtu 1492
set link mru 1492
set link enable pap
load radius
create link template igb1 common
set pppoe iface igb1
set pppoe acname "IntBSD1"
set pppoe service "*"
set link enable incoming
set auth max-logins 1
set link max-children 5000
create link template igb2 common
set pppoe iface igb2
set pppoe acname "IntBSD2"
set pppoe service "*"
set link enable incoming
set auth max-logins 1
set link max-children 5000
create link template igb3 common
set pppoe iface igb3
set pppoe acname "IntBSD3"
set pppoe service "*"
set link enable incoming
set auth max-logins 1
set link max-children 5000
radius:
set radius server localhost xuxupedra 1812 1813
set radius retries 3
set radius timeout 3
# send the given IP in the RAD_NAS_IP_ADDRESS attribute to the server.
set radius me 127.0.0.1
# send accounting updates every 5 minutes
set auth acct-update 300
# enable RADIUS, and fallback to mpd.secret, if RADIUS auth failed
set auth enable radius-auth
# enable RADIUS accounting
set auth enable radius-acct
# protect our requests with the message-authenticator
set radius enable message-authentic
###
Meu ipfw de teste:
fw="/sbin/ipfw"
ext_if="igb0"
$fw disable one_pass
$fw -f flush
$fw zero
$fw table all flush
$fw -f pipe flush
ssh_port="4321"
$fw add allow all from any to any via lo0
$fw add deny all from 127.0.0.0/8 to any
$fw add deny all from any to 127.0.0.0/8
$fw add check-state
# velocidade de 1024kbps
$fw add pipe 1 ip from "table(10)" to any in via ng*
$fw add pipe 2 ip from any to "table(10)" out via ng*
$fw pipe 1 config bw 1024Kbit/s queue 128 mask src-ip 255.255.255.255
$fw pipe 2 config bw 1024Kbit/s queue 128 mask dst-ip 255.255.255.255
# velocidade de 2048kbps
$fw add pipe 3 ip from "table(11)" to any in via ng*
$fw add pipe 4 ip from any to "table(11)" out via ng*
$fw pipe 3 config bw 2048Kbit/s queue 256 mask src-ip 255.255.255.255
$fw pipe 4 config bw 2048Kbit/s queue 256 mask dst-ip 255.255.255.255
# velocidade de 10240kbps
$fw add pipe 5 ip from "table(12)" to any in via ng*
$fw add pipe 6 ip from any to "table(12)" out via ng*
$fw pipe 5 config bw 10240Kbit/s queue 1280 mask src-ip 255.255.255.255
$fw pipe 6 config bw 10240Kbit/s queue 1280 mask dst-ip 255.255.255.255
# velocidade de 64kbps
$fw add pipe 7 ip from "table(13)" to any in via ng*
$fw add pipe 8 ip from any to "table(13)" out via ng*
$fw pipe 7 config bw 64Kbit/s queue 8 mask src-ip 255.255.255.255
$fw pipe 8 config bw 64Kbit/s queue 8 mask dst-ip 255.255.255.255
$fw add allow icmp from any to any icmptypes 0,3,8,11,12
$fw add deny icmp from any to any
=
Nas regras acima criei algumas tables para controle de velocidade de teste.
PF Rules para NAT apenas:
==
ext_if = "igb0"
table persist { 10.0.0.0/8 }
set skip on lo0
set limit states 4
nat on $ext_if from to any -> 192.168.8.34
Os scripts addclient.sh e removeclient.sh só fazem adicionar e remover o
IP que o usuário pegou na conexão, dentro da table correta da sua
velocidade.
Abaixo foi o teste que fiz com o ataque DoS usando um outro freebsd. Fiz
a conf do ppp.conf e depois o comando pra gerar as conexões.
Meu ppp.conf:
intnet:
set device PPPoE:re0
set mru 1492
set mtu 1492
set authname hercilia201254
set authkey 12345
set login
set dial
enable dns
add default HISADDR
set timeout 0
[FUG-BR] Suporte a CUDA
Oi pessoal. As últimas versões do OpenCV utilizam o suporte a CUDA. Alguém sabe se este funciona de alguma forma no FreeBSD? []'s -Otacílio - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
2013/5/21 Marcelo Gondim : > Em 21/05/13 07:56, Marcelo Araujo escreveu: >> Opa Povo, >> >> Gostaria de saber se existe alguém usando ALTQ com placas Intel, pode ser >> ixgbe, gbe ou em. Até onde eu estou sabendo no FreeBSD 9.1-RELEASE esta >> tudo quebrado, ALTQ não funciona com as placas Intel. >> >> Caso alguém esteja usando com sucesso, favor responder usando o comando: >> >> "pfctl -vvsr", "pfctl -vvsq" e também "uname -a" >> >> >> Grande Abraço. > Opa Marcelo, > > Não sei te dizer se é verdade mas ultimamente tenho encontrado algumas > instabilidades no 9.1-STABLE, isso até me preocupa pois o FreeBSD para > mim sempre foi um sistema robusto nesses poucos anos que tenho usado. > Atualmente estou fazendo testes com o FreeBSD 9.1-STABLE como > concentrador PPPoE utilizando o mpd + freeradius + mysql. Fiz algumas > simulações de diversas conexões simultâneas e foi muito bem. A coisa só > ficou ruim quando resolvi fazer um DoS no mpd gerando muitas conexões de > usuários inválidos, coisa que qualquer um na minha rede poderia fazer > conforme vou mostrar abaixo. O pior é que o resultado foram muitos mas > muitos kernel panics usando interfaces de rede Intel gigabit server > (igb) e o mesmo ocorreu em menor quantidade com Intel gigabit server > usando driver (em). > Troquei o hardware de todas as formas desde motherboards, memórias até o > disco, mas os kernel panics continuavam. > Estou tendo a péssima impressão que a qualidade do código está caindo. > Tipo vai testar jail com carp se eu não me engano e dá pau. OSPF tem uns > paus, vai montar sistemas de arquivos ntfs como leitura/escrita mais > paus. Fui testar o concentrador PPPoE e pau. Vou tentar usar a versão > 8.3-STABLE mas fico preocupado em como um código que deveria estar mais > estável com o passar do tempo, agora parece quebrado como o Marcelo > disse. Temos recursos novos na série 9? Temos, show mas eles deveriam > estar bem testados antes de serem liberados. > Quem quiser fazer os testes que fiz com o freebsd 9.1 + mpd + freeradius > + mysql vou fazer uma nova thread com os meus arquivos. Oi Marcelo, Eu não to sabendo desses possíveis problemas na série 9, mas assim, você reportou pros desenvolvedores os problemas que encontrou? Tentou olhar o histórico da lista freebsd-stable pra ver se mais pessoas estão com o mesmo problema? A qualidade de um código só pode ser melhorada se houver report dos problemas pelos usuários, só assim eles podem ser corrigidos. []s -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
Em 21/05/13 07:56, Marcelo Araujo escreveu: > Opa Povo, > > Gostaria de saber se existe alguém usando ALTQ com placas Intel, pode ser > ixgbe, gbe ou em. Até onde eu estou sabendo no FreeBSD 9.1-RELEASE esta > tudo quebrado, ALTQ não funciona com as placas Intel. > > Caso alguém esteja usando com sucesso, favor responder usando o comando: > > "pfctl -vvsr", "pfctl -vvsq" e também "uname -a" > > > Grande Abraço. Opa Marcelo, Não sei te dizer se é verdade mas ultimamente tenho encontrado algumas instabilidades no 9.1-STABLE, isso até me preocupa pois o FreeBSD para mim sempre foi um sistema robusto nesses poucos anos que tenho usado. Atualmente estou fazendo testes com o FreeBSD 9.1-STABLE como concentrador PPPoE utilizando o mpd + freeradius + mysql. Fiz algumas simulações de diversas conexões simultâneas e foi muito bem. A coisa só ficou ruim quando resolvi fazer um DoS no mpd gerando muitas conexões de usuários inválidos, coisa que qualquer um na minha rede poderia fazer conforme vou mostrar abaixo. O pior é que o resultado foram muitos mas muitos kernel panics usando interfaces de rede Intel gigabit server (igb) e o mesmo ocorreu em menor quantidade com Intel gigabit server usando driver (em). Troquei o hardware de todas as formas desde motherboards, memórias até o disco, mas os kernel panics continuavam. Estou tendo a péssima impressão que a qualidade do código está caindo. Tipo vai testar jail com carp se eu não me engano e dá pau. OSPF tem uns paus, vai montar sistemas de arquivos ntfs como leitura/escrita mais paus. Fui testar o concentrador PPPoE e pau. Vou tentar usar a versão 8.3-STABLE mas fico preocupado em como um código que deveria estar mais estável com o passar do tempo, agora parece quebrado como o Marcelo disse. Temos recursos novos na série 9? Temos, show mas eles deveriam estar bem testados antes de serem liberados. Quem quiser fazer os testes que fiz com o freebsd 9.1 + mpd + freeradius + mysql vou fazer uma nova thread com os meus arquivos. Grande abraço à todos. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ALTQ + Intel Drivers.
* Marcelo Araujo (araujobsdp...@gmail.com) wrote: > Opa Povo, > > Gostaria de saber se existe alguém usando ALTQ com placas Intel, pode ser > ixgbe, gbe ou em. Até onde eu estou sabendo no FreeBSD 9.1-RELEASE esta > tudo quebrado, ALTQ não funciona com as placas Intel. > > Caso alguém esteja usando com sucesso, favor responder usando o comando: > > "pfctl -vvsr", "pfctl -vvsq" e também "uname -a" > > > Grande Abraço. > -- > Marcelo Araujo > ara...@freebsd.org Vixi maria, eu ia usar num projeto aqui essa semana 9.1-STABLE também ? posso testar aqui e te reportar. --- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] ALTQ + Intel Drivers.
Opa Povo, Gostaria de saber se existe alguém usando ALTQ com placas Intel, pode ser ixgbe, gbe ou em. Até onde eu estou sabendo no FreeBSD 9.1-RELEASE esta tudo quebrado, ALTQ não funciona com as placas Intel. Caso alguém esteja usando com sucesso, favor responder usando o comando: "pfctl -vvsr", "pfctl -vvsq" e também "uname -a" Grande Abraço. -- Marcelo Araujo ara...@freebsd.org - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Hardware to virtualization.
Em 20/05/2013, às 16:42, Eduardo Schoedler escreveu: > Não tem na 5TI? Sinco.net? > MoBo Intel também vai muito bem com FreeBSD. > > > Em 20 de maio de 2013 16:26, Elias Motta > escreveu: > >> Boa tarde Lista, >> >> Dias atras os colegas trocaram ideia a respeito de hardware pra >> virtualização ESXi, alguns sugeriram motherboard Supermicro que vai bem com >> FreeBSD. Gostaria de sugestão de onde comprar essa marca aqui no brasil. >> >> Obs. sou do RS. >> Se não me engano no [1]Aldo tem, a uns anos atras tinha. [1] http://www.aldo.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
