[FUG-BR] [OT] IPv6 Accounting no freeradius2 (concentrador pppoe)
Salve PessoALL, bom dia! Desculpem o off-topic, mas como aqui na lista tem várias pessoas que trabalham em provedor de acesso e devem usar o freeradius para autenticação, como vocês estão fazendo o accounting (logs) dos registros de acesso para IPv6? Eu achei uma maneira [1], mas aqui não esta salvando, estou dando uma verificada nos códigos fontes para ver se acho algum detalhe. Alguem já conseguiu? [1] http://lists.freeradius.org/pipermail/freeradius-users/2011-May/053895.html -- Abraços, IndioX. -- Claudio P Costa BSDA Certified - http://bsdcertification.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] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
2016-01-27 16:21 GMT-03:00, Marcelo Gondim : > Em 26/01/2016 19:57, Vinícius Zavam escreveu: >> 2016-01-24 11:18 GMT-03:00, Marcelo Gondim : >>> Em 14/10/2015 12:19, Marcelo Gondim escreveu: On 14-10-2015 06:07, Sergio Lopes wrote: > Estou usando o FreeBSD 10.1 com 2 interfaces de 1GB e estou com o > mesmo problema usando LACP > > > igb2: Interface stopped DISTRIBUTING, possible flapping > igb4: Interface stopped DISTRIBUTING, possible flapping > > > Cada vez que o problema ocorre o tráfego da interface de um sentido > comuta para outra interface, fazendo com que o usuário perceba uma > queda de 5 segundos. > > Quando mudo para roundrobin e removo o lacp do FreeBSD e do Switch ai > fica normal. > Repara também no load como que sobe. Tenta usar o 10.1-stable que to usando e vê se resolve seu problema: 10.1-STABLE r281235 > > > > > Vinícius Zavam escreveu: >> 2015-10-04 9:59 GMT-03:00 Marcelo Gondim: >> >> [recorte] >> >> ... >> >> [/recorte] >> >> gondim, >> >> isso daí é algo que, assim como você, eu também teria de sentar com >> tempo e >> calma pra escovar com ajuda de ferramentas de stress, benchmark e >> algumas >> RFC; 2544, por exemplo (se não me engano). >> >> "adota essa criança" e ajuda o projeto a identificar o que está ruim >> pra >> quem utiliza stable/10. quanto mais detalhes e informações forem >> coletadas >> e reportadas, melhor. certamente uma sugestão de correção com patches >> também ajuda. infelizmente eu não chego nem perto de ter como >> reproduzir o >> cenário (não tenho máquinas, nem infraestrutura, que estejam >> disponíveis >> pra isso). >>> E ae pessoal, >>> >>> Retornando com essa thread pois descobri coisas novas à respeito do >>> problema. O problema não está no LACP porque nós retiramos o LACP e >>> colocamos tudo em interface de 10GbE X520-SR2. >>> O que parece é que algo mudou em relação ao cpu affinity entre a versão >>> 10.1-STABLE que estou usando e as versões atuais. >>> >>> Na versão 10.1-STABLE estou com o cpu affinity assim: >>> >>> /usr/bin/cpuset -l 11 -x 300 >>> /usr/bin/cpuset -l 10 -x 301 >>> /usr/bin/cpuset -l 9 -x 302 >>> /usr/bin/cpuset -l 8 -x 303 >>> /usr/bin/cpuset -l 7 -x 304 >>> /usr/bin/cpuset -l 6 -x 305 >>> /usr/bin/cpuset -l 0 -x 306 >>> /usr/bin/cpuset -l 1 -x 307 >>> /usr/bin/cpuset -l 9 -x 308 >>> >>> /usr/bin/cpuset -l 5 -x 355 >>> /usr/bin/cpuset -l 4 -x 356 >>> /usr/bin/cpuset -l 3 -x 357 >>> /usr/bin/cpuset -l 2 -x 358 >>> /usr/bin/cpuset -l 1 -x 359 >>> /usr/bin/cpuset -l 0 -x 360 >>> /usr/bin/cpuset -l 5 -x 361 >>> /usr/bin/cpuset -l 4 -x 362 >>> /usr/bin/cpuset -l 3 -x 363 >>> >>> /usr/bin/cpuset -l 5 -x 364 >>> /usr/bin/cpuset -l 4 -x 365 >>> /usr/bin/cpuset -l 3 -x 366 >>> /usr/bin/cpuset -l 2 -x 367 >>> /usr/bin/cpuset -l 1 -x 368 >>> /usr/bin/cpuset -l 0 -x 369 >>> /usr/bin/cpuset -l 5 -x 370 >>> /usr/bin/cpuset -l 4 -x 371 >>> /usr/bin/cpuset -l 3 -x 372 >>> >>> Dessa forma está funcionando no 10.1-STABLE sem problemas e os idle dos >>> cores meio que balanceados. A máquina é um Dual Hexa Xeon e por isso tem >>> 12 cores. Aí fiz uns testes e percebi o seguinte: >>> >>> Problema 1: quando atualizo do 10.1-STABLE para o 10.2 ou 11 e jogo os >>> meus links para o router (+5Gbps de tráfego), os cores ficam totalmente >>> desbalanceados ou seja, uns ficam normais com 30% à 40% idle e outros >>> ficam com 5% à 8% idle. Isso sem mudar nada em nenhum arquivo, somente >>> atualizando o sistema e mantendo todas as configurações. Egypcio sabe se >>> houve alguma mudança que poderia ter mudado esse comportamento no cpu >>> affinity? >>> >>> Problema 2: no sistema atual 10.1-STABLE descobri o seguinte: fui tentar >>> melhorar o balanceamento nos cores com o cpu affinity (cpuset) e quando >>> faço isso passo à ter perdas de pacotes nos links de dados. O que me >>> obriga à ter que reiniciar o sistema pra normalizar tudo. Ou seja mexeu >>> no cpu affinity, então reinicie porque senão pode dar zica e feia. >>> >>> Doideira isso. Ou seja o problema não estava no link aggregation. >>> >>> []´s >>> Gondim >> gondim, >> eahi. suavidade? >> >> catei aqui no histórico que tu estavas a relatar o uso da r281235 como >> 10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no >> "svnweb" do freebsd em https://svnweb.freebsd.org >> (base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE. >> independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão >> específica. // também pode sair escovando via CLI, se quiser... >> >> em "stable/10", segundo o svnweb, não são feitas alterações nesse >> cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que >> já houve alterações mais recentes (15 meses). finalmente, em >> "releng/10.2", tu podes ver que o código foi alterado cerca de 6 meses >> atrás. >> >> para qual desses branches essa tua máqu
Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
Em 29/01/2016 13:00, Vinícius Zavam escreveu: 2016-01-27 16:21 GMT-03:00, Marcelo Gondim : Em 26/01/2016 19:57, Vinícius Zavam escreveu: 2016-01-24 11:18 GMT-03:00, Marcelo Gondim : Em 14/10/2015 12:19, Marcelo Gondim escreveu: On 14-10-2015 06:07, Sergio Lopes wrote: Estou usando o FreeBSD 10.1 com 2 interfaces de 1GB e estou com o mesmo problema usando LACP igb2: Interface stopped DISTRIBUTING, possible flapping igb4: Interface stopped DISTRIBUTING, possible flapping Cada vez que o problema ocorre o tráfego da interface de um sentido comuta para outra interface, fazendo com que o usuário perceba uma queda de 5 segundos. Quando mudo para roundrobin e removo o lacp do FreeBSD e do Switch ai fica normal. Repara também no load como que sobe. Tenta usar o 10.1-stable que to usando e vê se resolve seu problema: 10.1-STABLE r281235 Vinícius Zavam escreveu: 2015-10-04 9:59 GMT-03:00 Marcelo Gondim: [recorte] ... [/recorte] gondim, isso daí é algo que, assim como você, eu também teria de sentar com tempo e calma pra escovar com ajuda de ferramentas de stress, benchmark e algumas RFC; 2544, por exemplo (se não me engano). "adota essa criança" e ajuda o projeto a identificar o que está ruim pra quem utiliza stable/10. quanto mais detalhes e informações forem coletadas e reportadas, melhor. certamente uma sugestão de correção com patches também ajuda. infelizmente eu não chego nem perto de ter como reproduzir o cenário (não tenho máquinas, nem infraestrutura, que estejam disponíveis pra isso). E ae pessoal, Retornando com essa thread pois descobri coisas novas à respeito do problema. O problema não está no LACP porque nós retiramos o LACP e colocamos tudo em interface de 10GbE X520-SR2. O que parece é que algo mudou em relação ao cpu affinity entre a versão 10.1-STABLE que estou usando e as versões atuais. Na versão 10.1-STABLE estou com o cpu affinity assim: /usr/bin/cpuset -l 11 -x 300 /usr/bin/cpuset -l 10 -x 301 /usr/bin/cpuset -l 9 -x 302 /usr/bin/cpuset -l 8 -x 303 /usr/bin/cpuset -l 7 -x 304 /usr/bin/cpuset -l 6 -x 305 /usr/bin/cpuset -l 0 -x 306 /usr/bin/cpuset -l 1 -x 307 /usr/bin/cpuset -l 9 -x 308 /usr/bin/cpuset -l 5 -x 355 /usr/bin/cpuset -l 4 -x 356 /usr/bin/cpuset -l 3 -x 357 /usr/bin/cpuset -l 2 -x 358 /usr/bin/cpuset -l 1 -x 359 /usr/bin/cpuset -l 0 -x 360 /usr/bin/cpuset -l 5 -x 361 /usr/bin/cpuset -l 4 -x 362 /usr/bin/cpuset -l 3 -x 363 /usr/bin/cpuset -l 5 -x 364 /usr/bin/cpuset -l 4 -x 365 /usr/bin/cpuset -l 3 -x 366 /usr/bin/cpuset -l 2 -x 367 /usr/bin/cpuset -l 1 -x 368 /usr/bin/cpuset -l 0 -x 369 /usr/bin/cpuset -l 5 -x 370 /usr/bin/cpuset -l 4 -x 371 /usr/bin/cpuset -l 3 -x 372 Dessa forma está funcionando no 10.1-STABLE sem problemas e os idle dos cores meio que balanceados. A máquina é um Dual Hexa Xeon e por isso tem 12 cores. Aí fiz uns testes e percebi o seguinte: Problema 1: quando atualizo do 10.1-STABLE para o 10.2 ou 11 e jogo os meus links para o router (+5Gbps de tráfego), os cores ficam totalmente desbalanceados ou seja, uns ficam normais com 30% à 40% idle e outros ficam com 5% à 8% idle. Isso sem mudar nada em nenhum arquivo, somente atualizando o sistema e mantendo todas as configurações. Egypcio sabe se houve alguma mudança que poderia ter mudado esse comportamento no cpu affinity? Problema 2: no sistema atual 10.1-STABLE descobri o seguinte: fui tentar melhorar o balanceamento nos cores com o cpu affinity (cpuset) e quando faço isso passo à ter perdas de pacotes nos links de dados. O que me obriga à ter que reiniciar o sistema pra normalizar tudo. Ou seja mexeu no cpu affinity, então reinicie porque senão pode dar zica e feia. Doideira isso. Ou seja o problema não estava no link aggregation. []´s Gondim gondim, eahi. suavidade? catei aqui no histórico que tu estavas a relatar o uso da r281235 como 10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no "svnweb" do freebsd em https://svnweb.freebsd.org (base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE. independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão específica. // também pode sair escovando via CLI, se quiser... em "stable/10", segundo o svnweb, não são feitas alterações nesse cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que já houve alterações mais recentes (15 meses). finalmente, em "releng/10.2", tu podes ver que o código foi alterado cerca de 6 meses atrás. para qual desses branches essa tua máquina estavas/está a apontar? chegou a escovar (testar) o comportamento apenas num dos branches? fazia checkout de rHEAD ou r281235 apenas em "stable/10"? caso tu tenhas disponibilidade, experimenta utilizar rHEAD entregue pelo "releng/10.2" (se a curiosidade for ainda maior, cata os códigos da CURRENT e escova; remove DEBUG/WITNESS/INVARIANT/..., altera MALLOC_PRODUCTION, usa WITH_FAST_DEPEND, ...). vai ser divertido :3 valeu por reviver essa thread! [ ] HhAhAh não codo em C não. Até rodo os make da vida rsrsrsrsrsr
Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
2016-01-29 13:58 GMT-03:00, Marcelo Gondim : > Em 29/01/2016 13:00, Vinícius Zavam escreveu: >> 2016-01-27 16:21 GMT-03:00, Marcelo Gondim : >>> Em 26/01/2016 19:57, Vinícius Zavam escreveu: 2016-01-24 11:18 GMT-03:00, Marcelo Gondim : > Em 14/10/2015 12:19, Marcelo Gondim escreveu: >> On 14-10-2015 06:07, Sergio Lopes wrote: >>> Estou usando o FreeBSD 10.1 com 2 interfaces de 1GB e estou com o >>> mesmo problema usando LACP >>> >>> >>> igb2: Interface stopped DISTRIBUTING, possible flapping >>> igb4: Interface stopped DISTRIBUTING, possible flapping >>> >>> >>> Cada vez que o problema ocorre o tráfego da interface de um sentido >>> comuta para outra interface, fazendo com que o usuário perceba uma >>> queda de 5 segundos. >>> >>> Quando mudo para roundrobin e removo o lacp do FreeBSD e do Switch >>> ai >>> fica normal. >>> >> Repara também no load como que sobe. Tenta usar o 10.1-stable que to >> usando e vê se resolve seu problema: >> >> 10.1-STABLE r281235 >> >>> >>> >>> >>> Vinícius Zavam escreveu: 2015-10-04 9:59 GMT-03:00 Marcelo Gondim: [recorte] ... [/recorte] gondim, isso daí é algo que, assim como você, eu também teria de sentar com tempo e calma pra escovar com ajuda de ferramentas de stress, benchmark e algumas RFC; 2544, por exemplo (se não me engano). "adota essa criança" e ajuda o projeto a identificar o que está ruim pra quem utiliza stable/10. quanto mais detalhes e informações forem coletadas e reportadas, melhor. certamente uma sugestão de correção com patches também ajuda. infelizmente eu não chego nem perto de ter como reproduzir o cenário (não tenho máquinas, nem infraestrutura, que estejam disponíveis pra isso). > E ae pessoal, > > Retornando com essa thread pois descobri coisas novas à respeito do > problema. O problema não está no LACP porque nós retiramos o LACP e > colocamos tudo em interface de 10GbE X520-SR2. > O que parece é que algo mudou em relação ao cpu affinity entre a > versão > 10.1-STABLE que estou usando e as versões atuais. > > Na versão 10.1-STABLE estou com o cpu affinity assim: > > /usr/bin/cpuset -l 11 -x 300 > /usr/bin/cpuset -l 10 -x 301 > /usr/bin/cpuset -l 9 -x 302 > /usr/bin/cpuset -l 8 -x 303 > /usr/bin/cpuset -l 7 -x 304 > /usr/bin/cpuset -l 6 -x 305 > /usr/bin/cpuset -l 0 -x 306 > /usr/bin/cpuset -l 1 -x 307 > /usr/bin/cpuset -l 9 -x 308 > > /usr/bin/cpuset -l 5 -x 355 > /usr/bin/cpuset -l 4 -x 356 > /usr/bin/cpuset -l 3 -x 357 > /usr/bin/cpuset -l 2 -x 358 > /usr/bin/cpuset -l 1 -x 359 > /usr/bin/cpuset -l 0 -x 360 > /usr/bin/cpuset -l 5 -x 361 > /usr/bin/cpuset -l 4 -x 362 > /usr/bin/cpuset -l 3 -x 363 > > /usr/bin/cpuset -l 5 -x 364 > /usr/bin/cpuset -l 4 -x 365 > /usr/bin/cpuset -l 3 -x 366 > /usr/bin/cpuset -l 2 -x 367 > /usr/bin/cpuset -l 1 -x 368 > /usr/bin/cpuset -l 0 -x 369 > /usr/bin/cpuset -l 5 -x 370 > /usr/bin/cpuset -l 4 -x 371 > /usr/bin/cpuset -l 3 -x 372 > > Dessa forma está funcionando no 10.1-STABLE sem problemas e os idle > dos > cores meio que balanceados. A máquina é um Dual Hexa Xeon e por isso > tem > 12 cores. Aí fiz uns testes e percebi o seguinte: > > Problema 1: quando atualizo do 10.1-STABLE para o 10.2 ou 11 e jogo os > meus links para o router (+5Gbps de tráfego), os cores ficam > totalmente > desbalanceados ou seja, uns ficam normais com 30% à 40% idle e outros > ficam com 5% à 8% idle. Isso sem mudar nada em nenhum arquivo, somente > atualizando o sistema e mantendo todas as configurações. Egypcio sabe > se > houve alguma mudança que poderia ter mudado esse comportamento no cpu > affinity? > > Problema 2: no sistema atual 10.1-STABLE descobri o seguinte: fui > tentar > melhorar o balanceamento nos cores com o cpu affinity (cpuset) e > quando > faço isso passo à ter perdas de pacotes nos links de dados. O que me > obriga à ter que reiniciar o sistema pra normalizar tudo. Ou seja > mexeu > no cpu affinity, então reinicie porque senão pode dar zica e feia. > > Doideira isso. Ou seja o problema não estava no link aggregation. > > []´s > Gondim gondim, eahi. suavidade? catei aqui no histórico que tu estavas a relatar o uso da r281235 como 10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no "svnweb" do freebsd em https://svnweb.freebsd.org (base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE. independente de ser 10.1, 10.2, ...); aí tu podes consultar a
[FUG-BR] Vaga Administrador de Sistemas.
Descrição da vaga Pré-requisitos: * Residir em Londrina - PR Descrição das atividades * Apoiar no suporte e manutenção da solução de Telecomunicações. * Administração de Servidores (Linux e Freebsd) Competências e experiências desejadas: * Conhecimento em FreeBSD. * Conhecimento avançado em Linux. * Conhecimento em Voip. * Conhecimento em PHP. * Conhecimento em desenvolvimento de scripts (Bash, Perl e expressões regulares). * Postura ética e profissional com foco em resultados. * Habilidade para resolução rápida de problemas. * Habilidade para análise de causa-raiz. * Capacidade para trabalhar sob pressão. Descrição da empresa: * Empresa especializada em TIC, com soluções próprias de CRM e discador. Informações adicionais * Função: Administrador de Sistemas * Horário de trabalho: De segunda a sexta-feira das 8 as 18hrs * Remuneração: Á combinar Interessados enviar CV para math...@mxsolucoes.com.br com o assunto "Administrador de Sistemas" Obrigado. -- --- Matheus Cucoloto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
Em 29/01/2016 15:16, Vinícius Zavam escreveu: 2016-01-29 13:58 GMT-03:00, Marcelo Gondim : Em 29/01/2016 13:00, Vinícius Zavam escreveu: 2016-01-27 16:21 GMT-03:00, Marcelo Gondim : Em 26/01/2016 19:57, Vinícius Zavam escreveu: 2016-01-24 11:18 GMT-03:00, Marcelo Gondim : Em 14/10/2015 12:19, Marcelo Gondim escreveu: On 14-10-2015 06:07, Sergio Lopes wrote: Estou usando o FreeBSD 10.1 com 2 interfaces de 1GB e estou com o mesmo problema usando LACP igb2: Interface stopped DISTRIBUTING, possible flapping igb4: Interface stopped DISTRIBUTING, possible flapping Cada vez que o problema ocorre o tráfego da interface de um sentido comuta para outra interface, fazendo com que o usuário perceba uma queda de 5 segundos. Quando mudo para roundrobin e removo o lacp do FreeBSD e do Switch ai fica normal. Repara também no load como que sobe. Tenta usar o 10.1-stable que to usando e vê se resolve seu problema: 10.1-STABLE r281235 Vinícius Zavam escreveu: 2015-10-04 9:59 GMT-03:00 Marcelo Gondim: [recorte] ... [/recorte] gondim, isso daí é algo que, assim como você, eu também teria de sentar com tempo e calma pra escovar com ajuda de ferramentas de stress, benchmark e algumas RFC; 2544, por exemplo (se não me engano). "adota essa criança" e ajuda o projeto a identificar o que está ruim pra quem utiliza stable/10. quanto mais detalhes e informações forem coletadas e reportadas, melhor. certamente uma sugestão de correção com patches também ajuda. infelizmente eu não chego nem perto de ter como reproduzir o cenário (não tenho máquinas, nem infraestrutura, que estejam disponíveis pra isso). E ae pessoal, Retornando com essa thread pois descobri coisas novas à respeito do problema. O problema não está no LACP porque nós retiramos o LACP e colocamos tudo em interface de 10GbE X520-SR2. O que parece é que algo mudou em relação ao cpu affinity entre a versão 10.1-STABLE que estou usando e as versões atuais. Na versão 10.1-STABLE estou com o cpu affinity assim: /usr/bin/cpuset -l 11 -x 300 /usr/bin/cpuset -l 10 -x 301 /usr/bin/cpuset -l 9 -x 302 /usr/bin/cpuset -l 8 -x 303 /usr/bin/cpuset -l 7 -x 304 /usr/bin/cpuset -l 6 -x 305 /usr/bin/cpuset -l 0 -x 306 /usr/bin/cpuset -l 1 -x 307 /usr/bin/cpuset -l 9 -x 308 /usr/bin/cpuset -l 5 -x 355 /usr/bin/cpuset -l 4 -x 356 /usr/bin/cpuset -l 3 -x 357 /usr/bin/cpuset -l 2 -x 358 /usr/bin/cpuset -l 1 -x 359 /usr/bin/cpuset -l 0 -x 360 /usr/bin/cpuset -l 5 -x 361 /usr/bin/cpuset -l 4 -x 362 /usr/bin/cpuset -l 3 -x 363 /usr/bin/cpuset -l 5 -x 364 /usr/bin/cpuset -l 4 -x 365 /usr/bin/cpuset -l 3 -x 366 /usr/bin/cpuset -l 2 -x 367 /usr/bin/cpuset -l 1 -x 368 /usr/bin/cpuset -l 0 -x 369 /usr/bin/cpuset -l 5 -x 370 /usr/bin/cpuset -l 4 -x 371 /usr/bin/cpuset -l 3 -x 372 Dessa forma está funcionando no 10.1-STABLE sem problemas e os idle dos cores meio que balanceados. A máquina é um Dual Hexa Xeon e por isso tem 12 cores. Aí fiz uns testes e percebi o seguinte: Problema 1: quando atualizo do 10.1-STABLE para o 10.2 ou 11 e jogo os meus links para o router (+5Gbps de tráfego), os cores ficam totalmente desbalanceados ou seja, uns ficam normais com 30% à 40% idle e outros ficam com 5% à 8% idle. Isso sem mudar nada em nenhum arquivo, somente atualizando o sistema e mantendo todas as configurações. Egypcio sabe se houve alguma mudança que poderia ter mudado esse comportamento no cpu affinity? Problema 2: no sistema atual 10.1-STABLE descobri o seguinte: fui tentar melhorar o balanceamento nos cores com o cpu affinity (cpuset) e quando faço isso passo à ter perdas de pacotes nos links de dados. O que me obriga à ter que reiniciar o sistema pra normalizar tudo. Ou seja mexeu no cpu affinity, então reinicie porque senão pode dar zica e feia. Doideira isso. Ou seja o problema não estava no link aggregation. []´s Gondim gondim, eahi. suavidade? catei aqui no histórico que tu estavas a relatar o uso da r281235 como 10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no "svnweb" do freebsd em https://svnweb.freebsd.org (base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE. independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão específica. // também pode sair escovando via CLI, se quiser... em "stable/10", segundo o svnweb, não são feitas alterações nesse cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que já houve alterações mais recentes (15 meses). finalmente, em "releng/10.2", tu podes ver que o código foi alterado cerca de 6 meses atrás. para qual desses branches essa tua máquina estavas/está a apontar? chegou a escovar (testar) o comportamento apenas num dos branches? fazia checkout de rHEAD ou r281235 apenas em "stable/10"? caso tu tenhas disponibilidade, experimenta utilizar rHEAD entregue pelo "releng/10.2" (se a curiosidade for ainda maior, cata os códigos da CURRENT e escova; remove DEBUG/WITNESS/INVARIANT/..., altera MALLOC_PRODUCTION, usa WITH_FAST_DEPEND, ...). vai ser divertido :3 valeu po
