Re: [FUG-BR] balanceamento entre os cores
Em 25/06/2014 12:35, Patrick Tracanelli escreveu: > > -- > Patrick Tracanelli > > FreeBSD Brasil LTDA. > Tel.: (31) 3516-0800 > 316...@sip.freebsdbrasil.com.br > http://www.freebsdbrasil.com.br > "Long live Hanin Elias, Kim Deal!" > > On 25/06/2014, at 12:16, Marcelo Gondim wrote: > >> Em 25/06/2014 09:30, Renato Botelho escreveu: >>> On Jun 25, 2014, at 9:23, Felipe N. Oliva wrote: Olá, Experimente executar make -j buildworld, ele vai criar mais jobs e assim ocupar mais os cores. >>> O indicado é -jN, onde N é o dobro do número de cores, desde que N seja <= >>> 16. Com mais de 16 jobs a eficiência é afetada. >>> >>> >> Opa Pessoal, >> >> Tentei com -j16 porque aqui são 12 cores e piorou a situação rsrsrsrrs >> Ficaram vários cores com quase 100% só se o clang tá chupando à rodo na >> compilação rsrsrsrsrs >> >> Bem vou fazer outros testes aqui pessoal. :D > Mas é isso que você fez. O -jN paraleliza a compilação em N jobs de objetos > pra depois que estiverem prontos juntar tudo e linkar no objeto final. > > Não, diferente do que você acha, não é ruim um ou N core ficarem 100% em uso > enquanto os outros ficam IDLE. Se existem poucas threads ou o job é > monothread o máximo de CPU que ele pode consumir é uma mesmo (por thread). > Nesse caso as outras ficam IDLE e a função do escalonador do kernel é por > qualquer outra coisa pra processar nos que estiverem IDLE mantendo a CPU > ocupada essencialmente pra aquela função. > > Processos que eventualmente ja estavam naquela CPU que agora está no talo, se > mantém nela enquanto estão em estados de execussão diferente de RUN. Mas > assim que saem de espera e vão pra RUN vão ser mudados de CPU pra uma mais > IDLE. > > Essa mudança é a famosa troca de contexto e ela é pesada, perde-se vários > ciclos de processamento só fazendo a troca de contexto. Envolve gravar > registrar, restaurar, mudar estado do processo na run queue e monitorar isso > tudo. > > Ou seja se acontecesse o que você quer, ficar alternando entre as CPUs o > processamento, não teria vantagem e ainda teria toda a perda de tempo e > esforço pra fazer a troca de contexto. > > O que acontece e as vezes achamos que troca de CPU são processos multithread > que ocupam CPU1 depois CPU3 depois CPU4 mas nesses casos as threads > finalizaram e são iniciadas em outras CPU, dando a impressão que o mesmo > “processo” esta mudando de CPU, mas são threads independentes. Em outros > casos como Apache com Worker ou qmail ou qualquer server que instância > múltiplas cópias de si mesmo voce vai reparar que são PIDs distintos nas > CPUs, ou seja outro processo, não há também a troca de CPU à esmo. > > Ou seja deixa como ta que ta certo hehehe ;-) E se quiser tirar melhor > proveito de TODAS as CPUs ai sim usa -jNCPU ou -jN onde N pode ser menos CPU > do que voce tem, -j8 vai por objetos paralelos em 8 CPUs deixando as outras 8 > livres pro que for necessário na demanda autênca do seu server. > > Eu pessoalmente nunca vi ganho realmente justificável em usar acima de -j4 no > buildkernel e buildworld. Mas claro que usando apenas a lógica -j8 vai ser > mais rápido que -j4 hehehe mas pra mim nunca foi, talvez porque nunca medi > com outra forma que não seja time -h hehehe, mas o ganho é irrelevante, ao > menos com HDD. Já com SSD acho que você tem menos gargalos no processo todo. > > :-) > hehehe valeu Patrick pela explicação e agora fiquei mais tranquilo quanto à isso. :) Grande abraço povo! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Asterisk rodando em FreeBSD Jail
Algumas informações novas... Meu cenário é o seguinte: Máquina host: em0 -> 192.168.137.254 wlan0 -> 10.143.143.159 (gateway) Jails (10 no total): asterisk -> 192.168.137.10 demais serviços -> 192.168.137.20 até 192.168.137.100, variando o último octeto de 10 em 10 Ativei o bug do protocolo SIP e obtive o seguinte resultado: <--- SIP read from UDP:192.168.137.70:5060 ---> REGISTER sip:192.168.137.10 SIP/2.0 CSeq: 563 REGISTER Via: SIP/2.0/UDP 0.0.0.0:5060 ;branch=z9hG4bKacec2a5a-01fb-e311-8a34-882e59337c01;rport User-Agent: Ekiga/4.0.1 From: Call-ID: c85e3639-01fb-e311-8a34-882e59337...@host.mydomain.com.br To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Expires: 3600 Content-Length: 0 Max-Forwards: 70 <--- SIP read from UDP:192.168.137.80:5060 ---> REGISTER sip:192.168.137.10 SIP/2.0 CSeq: 2 REGISTER Via: SIP/2.0/UDP 0.0.0.0:5060 ;branch=z9hG4bK026ef518-00fbe311-85c1-95a2dff01189;rport User-Agent: Ekiga/4.0.1 From: Call-ID: c8b6c809-00fb-e311-85c1-95a2dff01...@host.mydomain.com.br To: Contact: Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Expires: 3600 Content-Length: 0 Max-Forwards: 70 <-> --- (12 headers 0 lines) --- <--- SIP read from UDP:192.168.137.90:5060 ---> REGISTER sip:192.168.137.10 SIP/2.0 CSeq: 2 REGISTER Via: SIP/2.0/UDP 0.0.0.0:5060 ;branch=z9hG4bK8201f618-00fbe311-85c1-95a2dff01189;rport User-Agent: Ekiga/4.0.1 From: Call-ID: c8b6c809-00fb-e311-85c1-95a2dff01...@host.mydomain.com.br To: Contact: Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Expires: 3600 Content-Length: 0 Max-Forwards: 70 <-> --- (12 headers 0 lines) --- <--- SIP read from UDP:192.168.137.10:5060 ---> REGISTER sip:192.168.137.10 SIP/2.0 CSeq: 564 REGISTER Via: SIP/2.0/UDP 0.0.0.0:5060 ;branch=z9hG4bK02722c5a-01fb-e311-8a34-882e59337c01;rport User-Agent: Ekiga/4.0.1 From: Call-ID: c85e3639-01fb-e311-8a34-882e59337...@host.mydomain.com.br To: Contact: ;q=1, ;q=0.917, ;q=0.834, ;q=0.751, ;q=0.668, ;q=0.585, ;q=0.502, ;q=0.419, ;q=0.336, ;q=0.253, ;q=0.170, ;q=0.087 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Expires: 3600 Content-Length: 0 Max-Forwards: 70 Os campos "SIP read from UDP:192.168.137.X:5060" e "Contact" variam aleatoriamente entre todos os aliases utilizados nas jails e os ip's LAN e WAN da máquina host. O campo CSeq é incrementado a cada interação que só para quando derrubo o ekiga. Ainda investigando Att, Clayton Em 25 de junho de 2014 09:03, Clayton Eduardo dos Santos < clayto...@bsd.com.br> escreveu: > Olá Rafael, > > Você se recorda da versão do Asterisk que utilizava na ocasião? Realizou > alguma modificação nos parâmetros allow.* da jail? > > Obrigado! > > Clayton > > > Em 25 de junho de 2014 07:23, Rafael Aquino escreveu: > > >> - Mensagem original - >> > De: "Clayton Eduardo dos Santos" >> > Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" < >> freebsd@fug.com.br> >> > Enviadas: Quarta-feira, 25 de junho de 2014 0:46:32 >> > Assunto: [FUG-BR] Asterisk rodando em FreeBSD Jail >> > >> > Caros, boa noite! >> > >> > Instalei um asterisk 1.8.28.2 via ports em um jail rodando em um >> FreeBSD 10 >> > - amd64. >> > >> > O asterisk sobe normalmente, no entanto, ao instalar o ekiga em meu >> desktop >> > recebo a mensagem de que não foi possível registrar o ramal, pois a >> máquina >> > "remota" está offline. >> > >> > O estranho é que o ip associado ao jail responde aos pings e se forço o >> > asterisk a utilizar tcp, inclusive conecto na porta via telnet a partir >> da >> > máquina "host". >> > >> > Tenho outros jails funcionando perfeitamente na mesma máquina, com ssh, >> > nginx, entre outros serviços. >> > >> > Alguém tem alguma experiência com a combinação asterisk/jails e poderia >> dar >> > uma dica? >> > >> > Estou utilizando aliases e não vimage, seria esse o problema? >> > >> > Grato, >> > >> > Clayton >> > - >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > >> >> Oi, Clayton >> >> Tive a alguns anos experiência com Asterisk em Jail usando alias. >> Minha pequena ajuda nesta resposta é te passar que tudo funcionou >> exatamente como a máquina >> anterior, que não era jail. >> >> Só parei de usar em jail pois tinha uma placa pci com uma porta FXO para >> a entrada de ligações, >> e só consegui fazer o driver funcionar na máquina HOST. Dentro do jail >> não ia de jeito algum. >> >> Boa sorte! >> >> >> --- >> Rafael Mentz Aquino >> LK6 Soluções em TI >> Rua Domingos de Almeida, 135 sala 1102 >> Centro - Novo Hamburgo - RS >> (51) 3035-6997 - -7030 >> www.lk6.com.br >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > - His
Re: [FUG-BR] balanceamento entre os cores
-- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" On 25/06/2014, at 12:16, Marcelo Gondim wrote: > Em 25/06/2014 09:30, Renato Botelho escreveu: >> On Jun 25, 2014, at 9:23, Felipe N. Oliva wrote: >>> Olá, >>> >>> Experimente executar make -j buildworld, ele vai criar >>> mais jobs e assim ocupar mais os cores. >> O indicado é -jN, onde N é o dobro do número de cores, desde que N seja <= >> 16. Com mais de 16 jobs a eficiência é afetada. >> >> > Opa Pessoal, > > Tentei com -j16 porque aqui são 12 cores e piorou a situação rsrsrsrrs > Ficaram vários cores com quase 100% só se o clang tá chupando à rodo na > compilação rsrsrsrsrs > > Bem vou fazer outros testes aqui pessoal. :D Mas é isso que você fez. O -jN paraleliza a compilação em N jobs de objetos pra depois que estiverem prontos juntar tudo e linkar no objeto final. Não, diferente do que você acha, não é ruim um ou N core ficarem 100% em uso enquanto os outros ficam IDLE. Se existem poucas threads ou o job é monothread o máximo de CPU que ele pode consumir é uma mesmo (por thread). Nesse caso as outras ficam IDLE e a função do escalonador do kernel é por qualquer outra coisa pra processar nos que estiverem IDLE mantendo a CPU ocupada essencialmente pra aquela função. Processos que eventualmente ja estavam naquela CPU que agora está no talo, se mantém nela enquanto estão em estados de execussão diferente de RUN. Mas assim que saem de espera e vão pra RUN vão ser mudados de CPU pra uma mais IDLE. Essa mudança é a famosa troca de contexto e ela é pesada, perde-se vários ciclos de processamento só fazendo a troca de contexto. Envolve gravar registrar, restaurar, mudar estado do processo na run queue e monitorar isso tudo. Ou seja se acontecesse o que você quer, ficar alternando entre as CPUs o processamento, não teria vantagem e ainda teria toda a perda de tempo e esforço pra fazer a troca de contexto. O que acontece e as vezes achamos que troca de CPU são processos multithread que ocupam CPU1 depois CPU3 depois CPU4 mas nesses casos as threads finalizaram e são iniciadas em outras CPU, dando a impressão que o mesmo “processo” esta mudando de CPU, mas são threads independentes. Em outros casos como Apache com Worker ou qmail ou qualquer server que instância múltiplas cópias de si mesmo voce vai reparar que são PIDs distintos nas CPUs, ou seja outro processo, não há também a troca de CPU à esmo. Ou seja deixa como ta que ta certo hehehe ;-) E se quiser tirar melhor proveito de TODAS as CPUs ai sim usa -jNCPU ou -jN onde N pode ser menos CPU do que voce tem, -j8 vai por objetos paralelos em 8 CPUs deixando as outras 8 livres pro que for necessário na demanda autênca do seu server. Eu pessoalmente nunca vi ganho realmente justificável em usar acima de -j4 no buildkernel e buildworld. Mas claro que usando apenas a lógica -j8 vai ser mais rápido que -j4 hehehe mas pra mim nunca foi, talvez porque nunca medi com outra forma que não seja time -h hehehe, mas o ganho é irrelevante, ao menos com HDD. Já com SSD acho que você tem menos gargalos no processo todo. :-) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento entre os cores
Em 25/06/2014 09:30, Renato Botelho escreveu: > On Jun 25, 2014, at 9:23, Felipe N. Oliva wrote: >> Olá, >> >> Experimente executar make -j buildworld, ele vai criar >> mais jobs e assim ocupar mais os cores. > O indicado é -jN, onde N é o dobro do número de cores, desde que N seja <= > 16. Com mais de 16 jobs a eficiência é afetada. > > Opa Pessoal, Tentei com -j16 porque aqui são 12 cores e piorou a situação rsrsrsrrs Ficaram vários cores com quase 100% só se o clang tá chupando à rodo na compilação rsrsrsrsrs Bem vou fazer outros testes aqui pessoal. :D - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento entre os cores
Em 25/06/2014 09:14, Marcelo Gondim escreveu: > Pessoal, > > Está acontecendo uma coisa aqui estranha e já é a segunda máquina dual > processada que está fazendo isso e por isso acredito ser algum tunning > que esteja faltando. Primeiro testamos em uma máquina Dual Quad em uma > motherboard Intel S1200BTS com 2 processadores de 3.0Ghz. Agora estamos > testando em uma motherboard Intel S2600COE com 2 processadores Hexa Xeon > de 2.60Ghz. Ambas com HT desabilitado. > > Quando compilo o sistema tipo um make buildworld, eu reparo que alguns > cores ficam com 100% de uso enquanto que outros ficam totalmente > liberados. Eu acredito que o ideal seria haver um balanceamento nos > cores para que isso não ocorre-se. Quando o equipamento possui 1 > processador fica normal, aí pego o HD e coloco nessas 2 máquinas e o que > reparo é isso acontecendo pelo top. Existe algum tunning para melhorar > isso? Estou usando freebsd 10-stable com kernel sendo cópia do GENERIC e > apenas removendo alguns drivers que não estão sendo usados como floppy, > scsi, algumas interfaces de rede, essas coisas. > > []´s > Gondim > > Marcelo, li em algum canto em algum momento da minha vida algo que dizia o seguinte: -Se o processo ficar mudando de núcleo muitas entradas da cache serão invalidadas. Tipo, se o processo ficar migrando de núcleo todo o trabalho que a cache teve para armazenar as entradas mais utilizadas será perdido. Não sei se isto é sempre válido mas talvez seja o caso. []'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] Asterisk rodando em FreeBSD Jail
Olá Rafael, Você se recorda da versão do Asterisk que utilizava na ocasião? Realizou alguma modificação nos parâmetros allow.* da jail? Obrigado! Clayton Em 25 de junho de 2014 07:23, Rafael Aquino escreveu: > > - Mensagem original - > > De: "Clayton Eduardo dos Santos" > > Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" < > freebsd@fug.com.br> > > Enviadas: Quarta-feira, 25 de junho de 2014 0:46:32 > > Assunto: [FUG-BR] Asterisk rodando em FreeBSD Jail > > > > Caros, boa noite! > > > > Instalei um asterisk 1.8.28.2 via ports em um jail rodando em um FreeBSD > 10 > > - amd64. > > > > O asterisk sobe normalmente, no entanto, ao instalar o ekiga em meu > desktop > > recebo a mensagem de que não foi possível registrar o ramal, pois a > máquina > > "remota" está offline. > > > > O estranho é que o ip associado ao jail responde aos pings e se forço o > > asterisk a utilizar tcp, inclusive conecto na porta via telnet a partir > da > > máquina "host". > > > > Tenho outros jails funcionando perfeitamente na mesma máquina, com ssh, > > nginx, entre outros serviços. > > > > Alguém tem alguma experiência com a combinação asterisk/jails e poderia > dar > > uma dica? > > > > Estou utilizando aliases e não vimage, seria esse o problema? > > > > Grato, > > > > Clayton > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > Oi, Clayton > > Tive a alguns anos experiência com Asterisk em Jail usando alias. > Minha pequena ajuda nesta resposta é te passar que tudo funcionou > exatamente como a máquina > anterior, que não era jail. > > Só parei de usar em jail pois tinha uma placa pci com uma porta FXO para a > entrada de ligações, > e só consegui fazer o driver funcionar na máquina HOST. Dentro do jail não > ia de jeito algum. > > Boa sorte! > > > --- > Rafael Mentz Aquino > LK6 Soluções em TI > Rua Domingos de Almeida, 135 sala 1102 > Centro - Novo Hamburgo - RS > (51) 3035-6997 - -7030 > www.lk6.com.br > > - > 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] balanceamento entre os cores
On Jun 25, 2014, at 9:23, Felipe N. Oliva wrote: > > Olá, > > Experimente executar make -j buildworld, ele vai criar > mais jobs e assim ocupar mais os cores. O indicado é -jN, onde N é o dobro do número de cores, desde que N seja <= 16. Com mais de 16 jobs a eficiência é afetada. -- 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] balanceamento entre os cores
Em 25/06/2014 09:23, Felipe N. Oliva escreveu: > Olá, > > Experimente executar make -j buildworld, ele vai > criar mais jobs e assim ocupar mais os cores. > > Att, > Felipe N. Oliva > > Em 25/06/2014 09:14, Marcelo Gondim escreveu: >> Pessoal, >> >> Está acontecendo uma coisa aqui estranha e já é a segunda máquina dual >> processada que está fazendo isso e por isso acredito ser algum tunning >> que esteja faltando. Primeiro testamos em uma máquina Dual Quad em uma >> motherboard Intel S1200BTS com 2 processadores de 3.0Ghz. Agora estamos >> testando em uma motherboard Intel S2600COE com 2 processadores Hexa Xeon >> de 2.60Ghz. Ambas com HT desabilitado. >> >> Quando compilo o sistema tipo um make buildworld, eu reparo que alguns >> cores ficam com 100% de uso enquanto que outros ficam totalmente >> liberados. Eu acredito que o ideal seria haver um balanceamento nos >> cores para que isso não ocorre-se. Quando o equipamento possui 1 >> processador fica normal, aí pego o HD e coloco nessas 2 máquinas e o que >> reparo é isso acontecendo pelo top. Existe algum tunning para melhorar >> isso? Estou usando freebsd 10-stable com kernel sendo cópia do GENERIC e >> apenas removendo alguns drivers que não estão sendo usados como floppy, >> scsi, algumas interfaces de rede, essas coisas. >> >> []´s >> Gondim >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Top posting, sorry! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento entre os cores
Olá, Experimente executar make -j buildworld, ele vai criar mais jobs e assim ocupar mais os cores. Att, Felipe N. Oliva Em 25/06/2014 09:14, Marcelo Gondim escreveu: > Pessoal, > > Está acontecendo uma coisa aqui estranha e já é a segunda máquina dual > processada que está fazendo isso e por isso acredito ser algum tunning > que esteja faltando. Primeiro testamos em uma máquina Dual Quad em uma > motherboard Intel S1200BTS com 2 processadores de 3.0Ghz. Agora estamos > testando em uma motherboard Intel S2600COE com 2 processadores Hexa Xeon > de 2.60Ghz. Ambas com HT desabilitado. > > Quando compilo o sistema tipo um make buildworld, eu reparo que alguns > cores ficam com 100% de uso enquanto que outros ficam totalmente > liberados. Eu acredito que o ideal seria haver um balanceamento nos > cores para que isso não ocorre-se. Quando o equipamento possui 1 > processador fica normal, aí pego o HD e coloco nessas 2 máquinas e o que > reparo é isso acontecendo pelo top. Existe algum tunning para melhorar > isso? Estou usando freebsd 10-stable com kernel sendo cópia do GENERIC e > apenas removendo alguns drivers que não estão sendo usados como floppy, > scsi, algumas interfaces de rede, essas coisas. > > []´s > Gondim > > - > 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] balanceamento entre os cores
Pessoal, Está acontecendo uma coisa aqui estranha e já é a segunda máquina dual processada que está fazendo isso e por isso acredito ser algum tunning que esteja faltando. Primeiro testamos em uma máquina Dual Quad em uma motherboard Intel S1200BTS com 2 processadores de 3.0Ghz. Agora estamos testando em uma motherboard Intel S2600COE com 2 processadores Hexa Xeon de 2.60Ghz. Ambas com HT desabilitado. Quando compilo o sistema tipo um make buildworld, eu reparo que alguns cores ficam com 100% de uso enquanto que outros ficam totalmente liberados. Eu acredito que o ideal seria haver um balanceamento nos cores para que isso não ocorre-se. Quando o equipamento possui 1 processador fica normal, aí pego o HD e coloco nessas 2 máquinas e o que reparo é isso acontecendo pelo top. Existe algum tunning para melhorar isso? Estou usando freebsd 10-stable com kernel sendo cópia do GENERIC e apenas removendo alguns drivers que não estão sendo usados como floppy, scsi, algumas interfaces de rede, essas coisas. []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] flash player no freebsd 10 com guest no virtualbox
Em 24/06/2014 20:56, Paulo Cavalcanti escreveu: > Em 24 de junho de 2014 09:47, Otacílio escreveu: > >> Caros, instalei o freebsd 10 AMD64 como guest no virtualbox. Compilei >> localmente o chromium e depois instalei o flash plugin. O problema que >> está acontecendo é que a vozes saem fininhas, como se estivesse passando >> em um filtro passa-alta. Onde pude/percebi ativei o suporte ao >> pulseaudio. Alguém teve uma experiência semelhante, ou sabe alguma dica >> a respeito? >> >> []'s >> >> > Nunca tive experiência semelhante, mas eu uso o Firefox. Veja se o problema > ocorre em outros navegadores também. > - > O problema estava acontecendo em todos os aplicativos que utilizam audio. Dei uma olhada no /dev/sndstat e ele estava mostrando um driver para um tal Sigmatech, sendo que a máquina está configurada com o chipset ICH97. Achei estranho porque tenho uma outra máquina virtualizada também com FreeBSD 10 só que i386. Nesta ele carrega o driver correto da intel. [ota@xareu /usr/home/ota]$ cat /dev/sndstat Installed devices: pcm0: (play/rec) default Na máquina AMD64 eu precisei colocar no /boot/loader.conf explicitamente esta linha: snd_hda_load="YES" Está funcionando bem agora :) [ota@spock /usr/home/ota]$ cat /dev/sndstat Installed devices: pcm0: (play/rec) default []'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] Asterisk rodando em FreeBSD Jail
- Mensagem original - > De: "Clayton Eduardo dos Santos" > Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" > > Enviadas: Quarta-feira, 25 de junho de 2014 0:46:32 > Assunto: [FUG-BR] Asterisk rodando em FreeBSD Jail > > Caros, boa noite! > > Instalei um asterisk 1.8.28.2 via ports em um jail rodando em um FreeBSD 10 > - amd64. > > O asterisk sobe normalmente, no entanto, ao instalar o ekiga em meu desktop > recebo a mensagem de que não foi possível registrar o ramal, pois a máquina > "remota" está offline. > > O estranho é que o ip associado ao jail responde aos pings e se forço o > asterisk a utilizar tcp, inclusive conecto na porta via telnet a partir da > máquina "host". > > Tenho outros jails funcionando perfeitamente na mesma máquina, com ssh, > nginx, entre outros serviços. > > Alguém tem alguma experiência com a combinação asterisk/jails e poderia dar > uma dica? > > Estou utilizando aliases e não vimage, seria esse o problema? > > Grato, > > Clayton > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Oi, Clayton Tive a alguns anos experiência com Asterisk em Jail usando alias. Minha pequena ajuda nesta resposta é te passar que tudo funcionou exatamente como a máquina anterior, que não era jail. Só parei de usar em jail pois tinha uma placa pci com uma porta FXO para a entrada de ligações, e só consegui fazer o driver funcionar na máquina HOST. Dentro do jail não ia de jeito algum. Boa sorte! --- Rafael Mentz Aquino LK6 Soluções em TI Rua Domingos de Almeida, 135 sala 1102 Centro - Novo Hamburgo - RS (51) 3035-6997 - -7030 www.lk6.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] Utilizando GCC para compilar um port
On Jun 24, 2014, at 20:36, Otacílio wrote:
>
> Caros
>
> Estou tentando dar manutenção no port p5-Verilog-Perl e estou
> enfrentando o seguinte problema. O port não compila no clang. No
> Makefile setei o
>
> USE_GCC=any
>
> O port utiliza um arquivo Makefile.PL que é processado pelo PERL para
> gerar o Makefile. Dentro deste arquivo existe uma linha onde ele invoca
> o g++ diretamente. Substitui estas linhas por isso:
>
> $CPP = $ENV{CPP};
>
> E mais embaixo
>
> system("$CPP --version"); if ($?) { $fail=1; warn "\n%Error: 'gcc/g++'
> must be installed to build\n"; }
>
> Quando eu rodo o make o comportamento do script apresenta um erro como
> se não existisse a variável de ambiente CPP. Quando eu executo a linha
> abaixo no prompt
>
> setenv CPP g++46
>
> e rodo o make a coisa funciona.
>
> Alguém pode me dizer como diabos eu faço para descobrir qual o valor da
> variável CPP quando executando o make?
Bom dia Otacílio,
Para ver o valor da variável, use -V:
# make -V CPP
Observe também se ela faz parte do (CONFIGURE|MAKE)_(ARGS|ENV):
# make -V MAKE_ENV
# make -V MAKE_ARGS
# make -V CONFIGURE_ENV
# make -V CONFIGURE_ARGS
Para saber se ela está sendo passada para o Makefile interno na hora do build.
Agora, o ideal mesmo seria entender qual o erro do port com clang e corrigir,
se você não souber como corrigir, pode reportar o problema para o mantenedor do
software e também no bugtracker do clang.
Além disso, também pode obter ajuda no canal #bsdports, na rede de IRC EFNet.
[]s
--
Renato Botelho
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
