Re: [FUG-BR] Listar drivers em uso
Bom dia !!! Resolvi essa questão voltando o kernel GENERIC (kernel.old) e atualizando o FreeBSD para 8.2-STABLE. O boot não apresentou mais o PANIC. Pode ser alguma falha no 8.0-RELEASE. Obrigada, Em 10 de março de 2011 16:31, Ricardo Tweeg rtw...@yahoo.com.br escreveu: Renata, Seria interessante você buscar detalhes do seu hardware na página do fabricante. De qualquer forma, segue aqui mais algumas coisas que eu faria 1) Olhar a saida do comando 'kldstat -v' em busca de maiores detalhes. 2) Olhar a saida do comando o 'dmesg'. 3) Ligar a tecla 'Scroll Lock' e paginaria a tela (page UP e pag Down) em busca de mais informações do hardware. Obs.: A opção de olhar no site do fabricante é ao meu ver a melhor saida. O kernel GENERIC nem sempre detecta ou suporta todos os nossos devices. Sendo assim, você pode achar que o que esta sendo listado no kernel GENERIC com o 'kldstat' é tudo o que você precisa e para o seu hardware e na verdade pode ainda estar faltando o suporte para alguns devices. Espero que te ajude. abraços, att, Ricardo Tweeg --- Em qui, 10/3/11, Renata Dias renatchi...@gmail.com escreveu: De: Renata Dias renatchi...@gmail.com Assunto: [FUG-BR] Listar drivers em uso Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Quinta-feira, 10 de Março de 2011, 15:03 Caros, Estou compilando o kernel de uma máquina com FreeBSD 8.0-RELEASE, porém após a compilação e o reboot da máquina o sistema apresenta um PANIC na hora do boot loader e reboota após 15segundos. Voltei o kernel GENERIC através do terminal de Fixit do CD. Rodei pciconf -lv e me retornou os dispositivos e os drivers utilizados, porém os mesmos ja estavam também no meu novo kernel. # kldstat Id Refs AddressSize Name 11 0xc040 b6dfe0 kernel Preciso saber quais o drivers estão em uso pelo kernel GENERIC para que eu possa mante-los no novo arquivo de Kernel. Obrigada. -- Renata Dias - 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 -- Renata Dias - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Timecounters: Efficient and precise timekeeping in SMP kernels.
Em Sun, 13 Mar 2011 21:58:12 -0300 Mario Augusto Mania m3.bsd.ma...@gmail.com, conhecido consumidor/usuário de drogas (Windows e BigMac com Coke) escreveu: Oloco irado... baixa de novo vc tinha razão: baixei aqui no trampo e está bem diferente do primeiro. TKS :) -- saudações, irado furioso com tudo Linux User 179402/FreeBSD BSD50853/FUG-BR 154 Não uso drogas - 100% Miko$hit-free Tem casa tão pequena que um quarto parece um oitavo. [Wilson Figueiredo] - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Listar drivers em uso
Corrigindo, mesmo com a versão 8.2-STABLE após a recompilação do kernel com o arquivo personalizado voltou a apresentar o PANIC trap 12 no boot. O problema só foi corrigido depois que eu tirei do arquivo de kernel as linhas abaixo que foram adicionadas por mim: # Processamento #optionsHZ=1000 #maxusers 4096 Resumo de Hardware: CPU: AMD Phenom(tm) 9150e Quad-Core Processor (1808.24-MHz 686-class CPU) real memory = 4294967296 (4096 MB) nfe0: NVIDIA nForce MCP61 Networking Adapter port 0xe480-0xe487 mem 0xdff7e000-0xdff7efff irq 21 at device 7.0 on pci0 miibus0: MII bus on nfe0 acd0: DVDR TSSTcorp CDDVDW SH-S223C/SB02 at ata2-master UDMA100 SATA 1.5Gb/s ad6: 1907729MB Seagate ST32000542AS CC34 at ata3-master UDMA100 SATA 3Gb/s Em 14 de março de 2011 08:35, Renata Dias renatchi...@gmail.com escreveu: Bom dia !!! Resolvi essa questão voltando o kernel GENERIC (kernel.old) e atualizando o FreeBSD para 8.2-STABLE. O boot não apresentou mais o PANIC. Pode ser alguma falha no 8.0-RELEASE. Obrigada, Em 10 de março de 2011 16:31, Ricardo Tweeg rtw...@yahoo.com.brescreveu: Renata, Seria interessante você buscar detalhes do seu hardware na página do fabricante. De qualquer forma, segue aqui mais algumas coisas que eu faria 1) Olhar a saida do comando 'kldstat -v' em busca de maiores detalhes. 2) Olhar a saida do comando o 'dmesg'. 3) Ligar a tecla 'Scroll Lock' e paginaria a tela (page UP e pag Down) em busca de mais informações do hardware. Obs.: A opção de olhar no site do fabricante é ao meu ver a melhor saida. O kernel GENERIC nem sempre detecta ou suporta todos os nossos devices. Sendo assim, você pode achar que o que esta sendo listado no kernel GENERIC com o 'kldstat' é tudo o que você precisa e para o seu hardware e na verdade pode ainda estar faltando o suporte para alguns devices. Espero que te ajude. abraços, att, Ricardo Tweeg --- Em qui, 10/3/11, Renata Dias renatchi...@gmail.com escreveu: De: Renata Dias renatchi...@gmail.com Assunto: [FUG-BR] Listar drivers em uso Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Quinta-feira, 10 de Março de 2011, 15:03 Caros, Estou compilando o kernel de uma máquina com FreeBSD 8.0-RELEASE, porém após a compilação e o reboot da máquina o sistema apresenta um PANIC na hora do boot loader e reboota após 15segundos. Voltei o kernel GENERIC através do terminal de Fixit do CD. Rodei pciconf -lv e me retornou os dispositivos e os drivers utilizados, porém os mesmos ja estavam também no meu novo kernel. # kldstat Id Refs AddressSize Name 11 0xc040 b6dfe0 kernel Preciso saber quais o drivers estão em uso pelo kernel GENERIC para que eu possa mante-los no novo arquivo de Kernel. Obrigada. -- Renata Dias - 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 -- Renata Dias -- Renata Dias - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Listar drivers em uso
Em 14/03/2011 11:12, Renata Dias escreveu: Corrigindo, mesmo com a versão 8.2-STABLE após a recompilação do kernel com o arquivo personalizado voltou a apresentar o PANIC trap 12 no boot. O problema só foi corrigido depois que eu tirei do arquivo de kernel as linhas abaixo que foram adicionadas por mim: # Processamento #optionsHZ=1000 #maxusers 4096 Resumo de Hardware: CPU: AMD Phenom(tm) 9150e Quad-Core Processor (1808.24-MHz 686-class CPU) real memory = 4294967296 (4096 MB) nfe0:NVIDIA nForce MCP61 Networking Adapter port 0xe480-0xe487 mem 0xdff7e000-0xdff7efff irq 21 at device 7.0 on pci0 miibus0:MII bus on nfe0 acd0: DVDRTSSTcorp CDDVDW SH-S223C/SB02 at ata2-master UDMA100 SATA 1.5Gb/s ad6: 1907729MBSeagate ST32000542AS CC34 at ata3-master UDMA100 SATA 3Gb/s Em 14 de março de 2011 08:35, Renata Diasrenatchi...@gmail.com escreveu: Bom dia !!! Resolvi essa questão voltando o kernel GENERIC (kernel.old) e atualizando o FreeBSD para 8.2-STABLE. O boot não apresentou mais o PANIC. Pode ser alguma falha no 8.0-RELEASE. Obrigada, Em 10 de março de 2011 16:31, Ricardo Tweegrtw...@yahoo.com.brescreveu: Renata, Seria interessante você buscar detalhes do seu hardware na página do fabricante. De qualquer forma, segue aqui mais algumas coisas que eu faria 1) Olhar a saida do comando 'kldstat -v' em busca de maiores detalhes. 2) Olhar a saida do comando o 'dmesg'. 3) Ligar a tecla 'Scroll Lock' e paginaria a tela (page UP e pag Down) em busca de mais informações do hardware. Obs.: A opção de olhar no site do fabricante é ao meu ver a melhor saida. O kernel GENERIC nem sempre detecta ou suporta todos os nossos devices. Sendo assim, você pode achar que o que esta sendo listado no kernel GENERIC com o 'kldstat' é tudo o que você precisa e para o seu hardware e na verdade pode ainda estar faltando o suporte para alguns devices. Espero que te ajude. abraços, att, Ricardo Tweeg --- Em qui, 10/3/11, Renata Diasrenatchi...@gmail.com escreveu: De: Renata Diasrenatchi...@gmail.com Assunto: [FUG-BR] Listar drivers em uso Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Data: Quinta-feira, 10 de Março de 2011, 15:03 Caros, Estou compilando o kernel de uma máquina com FreeBSD 8.0-RELEASE, porém após a compilação e o reboot da máquina o sistema apresenta um PANIC na hora do boot loader e reboota após 15segundos. Voltei o kernel GENERIC através do terminal de Fixit do CD. Rodei pciconf -lv e me retornou os dispositivos e os drivers utilizados, porém os mesmos ja estavam também no meu novo kernel. # kldstat Id Refs AddressSize Name 11 0xc040 b6dfe0 kernel Preciso saber quais o drivers estão em uso pelo kernel GENERIC para que eu possa mante-los no novo arquivo de Kernel. Obrigada. -- Renata Dias - 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 -- Renata Dias A variável maxusers foi setada com um valor muito alto pro seu hardware...e como ela serve de parâmetro de entrada pra diversos outros ajustes internos do kernel como número de processos dentre outras só podia dar PANIC mesmo por exaustão de recursosDe uma lida em http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html pra vc ajustar este valor de froma adequada... -- Cordialmente, Ricardo Ferreira Telecom, Tecnologia e Segurança da Informação CCDP, CCNP, CCDA, CCNA, MCSE, MCP --- Sotech Soluções Tecnologicas Rua da Alfazema, 761, 1o. andar - 102/103 41820-710 - Caminho das Árvores - Salvador-BA - Brasil Tel : 55 71 3472.9400 Cel : 55 71 9138 4630 Email: ricardo.ferre...@sotechdatacenter.com.br Site: www.sotechdatacenter.com.br Esta mensagem é dirigida apenas ao seu destinatário e pode conter informações confidenciais, não passíveis de divulgação nos termos da legislação em vigor. Caso tenha recebido esta mensagem por engano, solicitamos notificar a Sotech Soluções Tecnológicas e excluí-la de sua caixa postal. This message, including its attachments, may contain confidential information. If you have improperly received this message, please delete it from your system and notify immediately the sender. Any form of utilization, reproduction, forward, alteration, distribution and/or disclosure of this content in whole or in part, without the prior written authorization of the sender, is strictly prohibited. Thanks for your cooperation. attachment: ricardo_ferreira.vcf- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Fwd: HEADS UP: sysinstall is no longer the default installer
-- Forwarded message -- From: Nathan Whitehorn nwhiteh...@freebsd.org Date: 2011/3/14 Subject: HEADS UP: sysinstall is no longer the default installer To: freebsd-current freebsd-curr...@freebsd.org, freebsd-sysinst...@freebsd.org, FreeBSD Arch freebsd-a...@freebsd.org I just committed (r219641) changes that make the release infrastructure (src/release/Makefile) use bsdinstall by default instead of sysinstall on install media. A big thank you is in order to everyone who provided advice, criticism, and testing for this project over the last few months! Along with sysinstall, the original sysinstall build stuff has been preserved (now /usr/src/release/Makefile.sysinstall) and will continue to be for the lifetime of the 9.x release series, although it will not be used by default. This change modifies the process of building releases somewhat, so I'll outline changes that people who run snapshot buildbots will have to make below, and some next steps planned with the installer. Changes to release(7) - Release builds work and look slightly different now, so everyone who snapshot tinderboxes will likely find them breaking shortly. The nearest analog to the old make release (with version-control checkouts and a chroot) is src/release/generate-release.sh, which can be run as generate-release.sh head /path/to/chroot/dir. If you want to include ports and documentation on the release media, CVSUP_HOST must be defined in the environment to point to a cvsup mirror. The output is placed in /R in the chroot directory, as before. If the chroot is unimportant (it ensures a total clean-room build, but may not be necessary in most cases), you can get a release build using the regular makefile, like so: cd /usr/src make buildworld buildkernel cd /usr/src/release make obj release By default, this will include ports and documentation if you have them checked out to /usr/ports and /usr/doc, though this behavior can be modified (see the top of the makefile). In addition, some architectures (i386, amd64, powerpc, powerpc64, and maybe ia64) have release media that can be cross-built, so you can set TARGET/TARGET_ARCH appropriately for those. Output goes to .OBJDIR, which is /usr/obj/usr/src/release in the case of the above commands. The equivalent to disc1 is called release.iso, the memstick image (i386, amd64 only) is called memstick, and a directory of distfiles for FTP mirrors is generated named ftp. Next steps -- The new installer is feature-complete at this time (except for a merge with the pc-sysinstall code base and the possible addition of ZFS support in the partition editor), so the next steps mostly involve documentation updates to manpages and the handbook. Generation of a bootonly ISO is another thing that should happen soon. Given time (or external patches), I would also like to update sysinstall to use the new-style distribution files so it can be an option on the 9.0 install CDs. Beyond that, please test this code as much as possible, and report any bugs, suspicious behaviors, or bad interfaces (or patch them -- patches for anything are always very welcome!). We have another several months before 9.0, so let's try to find all the bugs long before then. Thanks again to everyone who helped this project with comments and testing, especially to Bjoern Zeeb who got me irritated enough by sysinstall to start working on this project. -Nathan -- Vinícius Zavam profiles.google.com/egypcio - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede
Já troquei. Coloquei o CMTS ligado na placa Intel (em1) e mesmo assim o desempenho é ruim. Depois do servidor travar constantemente este final de semana, instalei o FreeBSD 7.4 nesta madrugada. Infelizmente por ser um ambiente de produção com milhares de usuários não posso ficar fazendo testes, e a máquina também está alguns kilometros de distância o que dificulta ainda mais. Uma das coisas que eu vi e já resolvi é a questão da perda de pacote do CMTS para o FreeBSD. O pessoal mandava 1000 pacotes e o kernel tem limite de 200 pacotes por segurança. Deixando como 0 essa perda parou. Quando desabilito a opção net.isr.direct eu também quase não tenho perda só que a latencia ta alta. Por exemplo: PING 10.20.0.2 (10.20.0.2): 56 data bytes 64 bytes from 10.20.0.2: icmp_seq=0 ttl=255 time=0.439 ms 64 bytes from 10.20.0.2: icmp_seq=1 ttl=255 time=0.285 ms 64 bytes from 10.20.0.2: icmp_seq=2 ttl=255 time=0.280 ms 64 bytes from 10.20.0.2: icmp_seq=3 ttl=255 time=0.492 ms 64 bytes from 10.20.0.2: icmp_seq=4 ttl=255 time=0.257 ms 64 bytes from 10.20.0.2: icmp_seq=5 ttl=255 time=0.302 ms 64 bytes from 10.20.0.2: icmp_seq=6 ttl=255 time=0.342 ms 64 bytes from 10.20.0.2: icmp_seq=7 ttl=255 time=0.266 ms [snip] 64 bytes from 10.20.0.2: icmp_seq=17 ttl=255 time=79.075 ms 64 bytes from 10.20.0.2: icmp_seq=18 ttl=255 time=12.466 ms 64 bytes from 10.20.0.2: icmp_seq=19 ttl=255 time=45.409 ms 64 bytes from 10.20.0.2: icmp_seq=20 ttl=255 time=45.705 ms 64 bytes from 10.20.0.2: icmp_seq=21 ttl=255 time=7.613 ms 64 bytes from 10.20.0.2: icmp_seq=22 ttl=255 time=7.436 ms 64 bytes from 10.20.0.2: icmp_seq=23 ttl=255 time=7.609 ms 64 bytes from 10.20.0.2: icmp_seq=24 ttl=255 time=7.541 ms [snip] 64 bytes from 10.20.0.2: icmp_seq=28 ttl=255 time=113.203 ms [snip] 64 bytes from 10.20.0.2: icmp_seq=36 ttl=255 time=8.471 ms 64 bytes from 10.20.0.2: icmp_seq=37 ttl=255 time=12.514 ms 64 bytes from 10.20.0.2: icmp_seq=38 ttl=255 time=24.049 ms 64 bytes from 10.20.0.2: icmp_seq=39 ttl=255 time=66.910 ms 64 bytes from 10.20.0.2: icmp_seq=40 ttl=255 time=88.233 ms ^C --- 10.20.0.2 ping statistics --- 41 packets transmitted, 41 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.226/18.730/113.203/27.405 ms Repare que não houve perdas de pacote, mas o tempo de resposta variou muito, tendo pico de 113ms. Se eu cancelo o ping e mando outro, começa novamente abaixo de 1ms até aumentar o tempo de resposta. Preciso saber se existe alguma coisa que eu possa fazer em termos de tuning pra que esse valor fique na faixa de 1ms, já que está ligado diretamente, sem switch no meio. (mesmo com switch o problema persiste). E uma vez o tempo de resposta alto, ele não volta novamente na casa de 1ms ou menor que 1ms. Mas se dispara outro ping, começa novamente em menor que 1ms. Outra coisa, deixei somente o pf habilitado. O kernel resolvi compilar sem o ipfw/dummynet pra ver se iria mudar alguma coisa no desempenho. Mesmo deixando controle de banda so pra rede interna (192.168.0.0/24). Em 11 de março de 2011 17:52, mantunes mantunes.lis...@gmail.com escreveu: existe possibilidade de trocar a placa de rede, porta do Switch.. Em 11 de março de 2011 17:41, kmkz bleh jsi...@gmail.com escreveu: Já verifiquei o CMTS sim... não vi nada errado nele. O negócio é que quando passa pelo servidor ou perde pacote ou a latência fica muito alta. Por exemplo, o ping de uma estação na outra, so switch msm, o tempo é menor que 1 ms. Quando pinga o servidor já apresenta perda ou o tempo fica na casa de 4 ms (rede interna) com picos de 20, 30, 50 ms. Em 11 de março de 2011 17:08, Edinilson - ATINET edinil...@atinet.com.brescreveu: Baseado neste problema (e outros similares), gostaria de perguntar aos experts em Freebsd da lista: nos casos como este, faz diferença o scheduler que está sendo utilizado? Se sim, qual o melhor? No Freebsd 8, ainda está vindo como padrao o bom e velho 4BSD ou já vem o ULE? Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: kmkz bleh jsi...@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Friday, March 11, 2011 3:48 PM Subject: Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede - 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 -- Marcio Antunes Powered by FreeBSD == * Windows: Where do you want to go tomorrow? * Linux: Where do you want to go today? * FreeBSD: Are you, guys, comming or what? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da
[FUG-BR] IBM x3550
Boa tarde senhores, tenho alguns IBMs x3550 e neste fim de semana um deles começou a dar problemas. de repente a ventoinha disparou como se estivesse super aquecendo a máquina, porém o local é refrigerado a 20º, portanto não está aquecido. De 8 equipamentos somente este está com o barulho infernal. alguém já teve problema parecido? Att, Kivanio Barbosa - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: IBM x3550
Não tenho boas lembranças dessa linha de servidores da IBM. Sei que esses servidores de rack disparam os coolers quando você abre o gabinete. Se não abriu, pode ter sido um problema no sensor. Outra hipótese é se um cooler dá problema, ele sobe o giro de todos os outros para compensar o perdido. Chegou a ver no Light Path Diagnostics se há algum led aceso ? -- Eduardo Schoedler -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Kivanio Barbosa Enviada em: segunda-feira, 14 de março de 2011 16:09 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: [FUG-BR] IBM x3550 Boa tarde senhores, tenho alguns IBMs x3550 e neste fim de semana um deles começou a dar problemas. de repente a ventoinha disparou como se estivesse super aquecendo a máquina, porém o local é refrigerado a 20º, portanto não está aquecido. De 8 equipamentos somente este está com o barulho infernal. alguém já teve problema parecido? Att, Kivanio Barbosa - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IBM x3550
Existe algum LED acesso? M2 ou M3? Possui garantia ainda? Att Afranio Em 14 de março de 2011 16:08, Kivanio Barbosa kiva...@gmail.com escreveu: Boa tarde senhores, tenho alguns IBMs x3550 e neste fim de semana um deles começou a dar problemas. de repente a ventoinha disparou como se estivesse super aquecendo a máquina, porém o local é refrigerado a 20º, portanto não está aquecido. De 8 equipamentos somente este está com o barulho infernal. alguém já teve problema parecido? Att, Kivanio Barbosa - 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
[FUG-BR] php_module_shutdown_wrapper
Boa tarde a todos Instalei o PHP 5.3.5 com o Apache/2.2.17 no FreeBSD 8.1-RELEASE amd64 64bit mas quando vou levantar o Apache ele da o seguinte erro: Syntax error on line 56 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: /usr/local/apache2/modules/libphp5.so: Undefined symbol php_module_shutdown_wrapper sempre instalei o PHP com o Apache e nunca tive esse tipo de erro, alguém pode me ajudar? grato Helizonaldo Alves de Morais Teresina-PI Brasil. +-+ o _ _ _ _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] pfSense - Brigde Transparente
Montei um pfSense trabalhando em Firewall como bridge transparente, está parte de firewall e bridge está funcionando corretamente, minha estrutura segue abaixo: roteador-pfsense-servidor 10.0.0.110.0.0.210.0.0.x Trabalhando em modo bridge, os ips dos servidores são roteados pelo roteador e não pelo pfsense, isso funcionando certinho, porem, pra sair, os servidores em vez de usar os ips 10.0.0.x cada um com seu ip, está saindo com o ip 10.0.0.2, que é o ip do pfsense, mais preciso que cada servidor saia com seu ip, alguem sabe como arrumo isso? -- Luan Tasca luanta...@gmail.com +55 (48) 99494665 @luantasca http://www.beersd.com.br BSD User: 51785 - Amar é.. deletar o Windows do HD - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: pfSense - Brigde Transparente
Em 14/03/2011 17:13, Luan Tasca escreveu: pra sair, os servidores em vez de usar os ips 10.0.0.x cada um com seu ip, está saindo com o ip 10.0.0.2, que é o ip do pfsense, mais preciso que cada servidor saia com seu ip, alguem sabe como arrumo isso? o PFSense deve estar fazendo NAT... ou então você está com proxy ativado. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: pfSense - Brigde Transparente
Em 14-03-2011 18:13, Eduardo Schoedler escreveu: Em 14/03/2011 17:13, Luan Tasca escreveu: pra sair, os servidores em vez de usar os ips 10.0.0.x cada um com seu ip, está saindo com o ip 10.0.0.2, que é o ip do pfsense, mais preciso que cada servidor saia com seu ip, alguem sabe como arrumo isso? o PFSense deve estar fazendo NAT... ou então você está com proxy ativado. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Consegui fazer funcionar, pra ficar documentado e se alguem passar por isso.. Firewall: NAT: Outbound Ativar *Manual Outbound NAT rule generation (Advanced Outbound NAT (AON)) *e apagar a regra que ele cria sozinho. -- Luan Tasca luanta...@gmail.com +55 (48) 99494665 @luantasca http://www.beersd.com.br BSD User: 51785 - Amar é.. deletar o Windows do HD - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: pfSense - Brigde Transparente
Poderia ainda ter criado uma regra de NO NAT. Mas como dizem por aí: quanto menos regras, melhor! :-) Chegou a notar diferença entre um firewall roteado e um bridge ? Consumo de CPU... latência... etc. Abs. -- Eduardo Schoedler -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Luan Tasca Enviada em: segunda-feira, 14 de março de 2011 18:39 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] RES: pfSense - Brigde Transparente Em 14-03-2011 18:13, Eduardo Schoedler escreveu: Em 14/03/2011 17:13, Luan Tasca escreveu: pra sair, os servidores em vez de usar os ips 10.0.0.x cada um com seu ip, está saindo com o ip 10.0.0.2, que é o ip do pfsense, mais preciso que cada servidor saia com seu ip, alguem sabe como arrumo isso? o PFSense deve estar fazendo NAT... ou então você está com proxy ativado. -- Eduardo Schoedler Consegui fazer funcionar, pra ficar documentado e se alguem passar por isso.. Firewall: NAT: Outbound Ativar *Manual Outbound NAT rule generation (Advanced Outbound NAT (AON)) *e apagar a regra que ele cria sozinho. -- Luan Tasca luanta...@gmail.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] Servidores USA
www.softlayer.com 2011/2/26 Akamaru cooperm...@bol.com.br: Alguem sabe um lugar onde eu possa alugar um servidor a baixo custo no EUA? - 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
[FUG-BR] RES: Servidores USA
www.iweb.com -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Leonardo Augusto Enviada em: segunda-feira, 14 de março de 2011 19:35 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] Servidores USA www.softlayer.com 2011/2/26 Akamaru cooperm...@bol.com.br: Alguem sabe um lugar onde eu possa alugar um servidor a baixo custo no EUA? - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede
Pessoal, mais uma informação que acho que pode ajudar: gw# sysctl net.inet.ip.intr_queue_drops net.inet.ip.intr_queue_drops: 36943 gw# vmstat -i interrupt total rate irq28: ciss0 73109 67 irq1: atkbd0 10 0 irq17: atapci0+ 242 0 irq22: uhci0 2 0 cpu0: timer 2152906 1998 irq256: em0 2386318 2215 irq257: em021311 19 irq258: em02 0 irq259: em1 665 0 irq260: bce011311742 10503 irq261: bce1 59430 55 irq262: em2 1954193 1814 irq263: em2 2460842 2284 irq264: em21 0 irq265: em3 6807389 6320 irq266: em3 6870682 6379 irq267: em3 14 0 irq268: bge0 1936273 1797 irq269: bge1 1504853 1397 cpu2: timer 2144394 1991 cpu3: timer 2144549 1991 cpu1: timer 2144367 1991 Total 43973294 40829 Outra coisa, vi que meu servidor deu PANIC com a msg abaixo: reboot after panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated Com 4GB de RAM, o que eu devo fazer pra resolver esse problema? Qual valor devo colocar no KVA_PAGES pra compilar o kernel, seria 1024? Meu kernel ta compilado com a opção PAE. Desde já agradeço. Em 14 de março de 2011 14:23, kmkz bleh jsi...@gmail.com escreveu: Já troquei. Coloquei o CMTS ligado na placa Intel (em1) e mesmo assim o desempenho é ruim. Depois do servidor travar constantemente este final de semana, instalei o FreeBSD 7.4 nesta madrugada. Infelizmente por ser um ambiente de produção com milhares de usuários não posso ficar fazendo testes, e a máquina também está alguns kilometros de distância o que dificulta ainda mais. Uma das coisas que eu vi e já resolvi é a questão da perda de pacote do CMTS para o FreeBSD. O pessoal mandava 1000 pacotes e o kernel tem limite de 200 pacotes por segurança. Deixando como 0 essa perda parou. Quando desabilito a opção net.isr.direct eu também quase não tenho perda só que a latencia ta alta. Por exemplo: PING 10.20.0.2 (10.20.0.2): 56 data bytes 64 bytes from 10.20.0.2: icmp_seq=0 ttl=255 time=0.439 ms 64 bytes from 10.20.0.2: icmp_seq=1 ttl=255 time=0.285 ms 64 bytes from 10.20.0.2: icmp_seq=2 ttl=255 time=0.280 ms 64 bytes from 10.20.0.2: icmp_seq=3 ttl=255 time=0.492 ms 64 bytes from 10.20.0.2: icmp_seq=4 ttl=255 time=0.257 ms 64 bytes from 10.20.0.2: icmp_seq=5 ttl=255 time=0.302 ms 64 bytes from 10.20.0.2: icmp_seq=6 ttl=255 time=0.342 ms 64 bytes from 10.20.0.2: icmp_seq=7 ttl=255 time=0.266 ms [snip] 64 bytes from 10.20.0.2: icmp_seq=17 ttl=255 time=79.075 ms 64 bytes from 10.20.0.2: icmp_seq=18 ttl=255 time=12.466 ms 64 bytes from 10.20.0.2: icmp_seq=19 ttl=255 time=45.409 ms 64 bytes from 10.20.0.2: icmp_seq=20 ttl=255 time=45.705 ms 64 bytes from 10.20.0.2: icmp_seq=21 ttl=255 time=7.613 ms 64 bytes from 10.20.0.2: icmp_seq=22 ttl=255 time=7.436 ms 64 bytes from 10.20.0.2: icmp_seq=23 ttl=255 time=7.609 ms 64 bytes from 10.20.0.2: icmp_seq=24 ttl=255 time=7.541 ms [snip] 64 bytes from 10.20.0.2: icmp_seq=28 ttl=255 time=113.203 ms [snip] 64 bytes from 10.20.0.2: icmp_seq=36 ttl=255 time=8.471 ms 64 bytes from 10.20.0.2: icmp_seq=37 ttl=255 time=12.514 ms 64 bytes from 10.20.0.2: icmp_seq=38 ttl=255 time=24.049 ms 64 bytes from 10.20.0.2: icmp_seq=39 ttl=255 time=66.910 ms 64 bytes from 10.20.0.2: icmp_seq=40 ttl=255 time=88.233 ms ^C --- 10.20.0.2 ping statistics --- 41 packets transmitted, 41 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.226/18.730/113.203/27.405 ms Repare que não houve perdas de pacote, mas o tempo de resposta variou muito, tendo pico de 113ms. Se eu cancelo o ping e mando outro, começa novamente abaixo de 1ms até aumentar o tempo de resposta. Preciso saber se existe alguma coisa que eu possa fazer em termos de tuning pra que esse valor fique na faixa de 1ms, já que está ligado diretamente, sem switch no meio. (mesmo com switch o problema persiste). E uma vez o tempo de resposta alto, ele não volta novamente na casa de 1ms ou menor que 1ms. Mas se dispara outro ping, começa novamente em menor que 1ms. Outra coisa, deixei somente o pf habilitado. O kernel resolvi compilar sem o ipfw/dummynet pra ver se iria mudar alguma coisa no desempenho. Mesmo deixando controle de banda so pra rede interna (192.168.0.0/24). Em 11 de março de 2011 17:52, mantunes mantunes.lis...@gmail.comescreveu: existe possibilidade de trocar a placa de rede,
