É importante utilizar recursos de hardware de maneira eficiente. O gerenciamento de energia e recursos permite que o sistema operacional monitore os limites do sistema e, possivelmente, forneça um alerta se a temperatura do sistema aumentar inesperadamente. Uma especificação anterior para fornecer gerenciamento de energia foi o recurso Gerenciamento Avançado de Energia (Advanced Power Management - APM). O APM controla o uso de energia de um sistema com base em sua atividade. No entanto, era difícil e inflexível para os sistemas operacionais gerenciar o uso de energia e as propriedades térmicas de um sistema. O hardware era gerenciado pelo BIOS e o usuário tinha configuração e visibilidade limitadas nas configurações de gerenciamento de energia. O APM BIOS fornecido é específico da plataforma de hardware. Um driver APM no sistema operacional intermedia o acesso à interface do software APM, que permite o gerenciamento dos níveis de energia.
Existem quatro problemas principais no APM. Primeiro, o gerenciamento de energia é feito pelo BIOS específico do fornecedor, separado do sistema operacional. Por exemplo, o usuário pode definir valores de tempo ocioso para um disco rígido no APM BIOS para que, quando excedido, o BIOS diminua o disco rígido sem o consentimento do sistema operacional. Segundo, a lógica do APM é incorporada no BIOS e opera fora do escopo do sistema operacional. Isso significa que os usuários só podem corrigir problemas no APM BIOS, fazendo o flash de um novo ROM, que é um procedimento perigoso com potencial para deixar o sistema em um estado irrecuperável se falhar. Terceiro, o APM é uma tecnologia específica do fornecedor, o que significa que há muita duplicidade de esforços e que os erros encontrados no BIOS de um fornecedor podem não serem resolvidos em outros. Por fim, o APM BIOS não tinha espaço suficiente para implementar uma política de energia sofisticada ou que pudesse se adaptar bem ao propósito da máquina.
O BIOS plug and play (PNPBIOS) não era confiável em muitas situações. O PNPBIOS é uma tecnologia de 16 bits, portanto, o sistema operacional precisa usar a emulação de 16 bits para fazer interface com os métodos PNPBIOS. O FreeBSD fornece um driver APM, pois o APM ainda deve ser usado para sistemas fabricados antes do ano 2000. O driver está documentado em apm(4).
O sucessor do APM é a Interface Avançada de Configuração e Energia (Advanced Configuration and Power Interface - ACPI). O ACPI é um padrão escrito por uma aliança de fornecedores para fornecer uma interface para recursos de hardware e gerenciamento de energia. É um elemento-chave na configuração direcionada do sistema operacional e gerenciamento de energia, pois proporciona mais controle e flexibilidade ao sistema operacional.
Este capítulo demonstra como configurar o ACPI no FreeBSD. Em seguida, ele oferece algumas dicas sobre como depurar o ACPI e como enviar um relatório de problemas contendo informações de depuração para que os desenvolvedores possam diagnosticar e corrigir problemas no ACPI.
No FreeBSD, o driver acpi(4) é carregado por padrão na inicialização do sistema e não deve ser compilado no kernel. Este driver não pode ser descarregado após a inicialização porque o barramento do sistema o utiliza para várias interações de hardware. No entanto, se o sistema estiver com problemas, o ACPI pode ser desativado completamente ao reinicializar após a configurar hint.acpi.0.disabled="1"
no /boot/loader.conf
ou definindo esta variável no prompt do loader, como descrito em Seção 12.2.3, “Estágio três”.
O ACPI e o APM não podem coexistir e devem ser usados separadamente. O último a ser carregado terminará se o driver perceber que o outro já está sendo executado.
O ACPI pode ser usado para colocar o sistema em modo de suspensão com o acpiconf
, a opção -s
e um número de 1
a 5
. A maioria dos usuários só precisa de 1
(suspensão rápida para RAM) ou 3
(suspender para RAM). A opção 5
executa um soft-off que é o mesmo que executar halt -p
.
Outras opções estão disponíveis usando o sysctl
. Consulte acpi(4) e acpiconf(8) para maiores informações.
O ACPI está presente em todos os computadores modernos que estão em conformidade com as arquiteturas ia32 (x86) e amd64 (AMD). O padrão completo tem muitos recursos, incluindo gerenciamento de desempenho da CPU, controle de planos de energia, zonas térmicas, vários sistemas de bateria, controladores incorporados e enumeração de barramento. A maioria dos sistemas implementa menos que o padrão completo. Por exemplo, um sistema de desktop geralmente só implementa a enumeração de barramento, enquanto um laptop também pode ter suporte a refrigeração e gerenciamento de bateria. Os laptops também têm suspensão e retomada, com sua própria complexidade associada.
Um sistema compatível com ACPI possui vários componentes. Os fornecedores de BIOS e chipset fornecem várias tabelas fixas, como FADT, na memória que especificam coisas como o mapa APIC (usado para SMP), registros de configuração e valores simples de configuração. Além disso, uma tabela de bytecode, a Tabela de Descrição de Sistema Diferenciada DSDT, especifica um espaço de nome de dispositivos e métodos em forma de árvore.
O driver ACPI deve analisar as tabelas fixas, implementar um interpretador para o bytecode e modificar os drivers de dispositivos e o kernel para aceitar informações do subsistema ACPI. Para o FreeBSD, a Intel® forneceu um interpretador (ACPI-CA) que é compartilhado com o Linux® e o NetBSD. O caminho para o código-fonte ACPI-CA é src/sys/contrib/dev/acpica
. O código especifico que permite que o ACPI-CA funcione no FreeBSD está em src/sys/dev/acpica/Osd
. Finalmente, drivers que implementam vários dispositivos ACPI são encontrados em src/sys/dev/acpica
.
Para que o ACPI funcione corretamente, todas as partes devem funcionar corretamente. Aqui estão alguns problemas comuns, em ordem de freqüência em que ocorrem, e algumas possíveis soluções ou correções. Se uma correção não resolver o problema, consulte Seção 11.13.4, “Obtendo e enviando informações de depuração” para obter instruções sobre como enviar um relatório de bug.
Em alguns casos, retomar a partir de uma operação de suspensão fará com que o mouse falhe. Um work around conhecido é adicionar hint.psm.0.flags="0x3000"
ao /boot/loader.conf
.
O ACPI tem três estados de suspensão para RAM (STR), S1
-S3
, e um de suspensão de estado para disco (STD), chamado S4
. O STD pode ser implementado de duas maneiras separadas. O S4
BIOS é uma suspensão para disco auxiliada pelo BIOSe o S4
OS é implementado inteiramente pelo sistema operacional. O estado normal em que o sistema se encontra quando conectado, mas não ligado, é “soft off” (S5
).
Use o sysctl hw.acpi
para verificar os itens relacionados à suspensão. Estes resultados de exemplo são de um Thinkpad:
hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0
Use o acpiconf -s
para testar os estados S3
, S4
e S5
. Um s4bios
de um (1
) indica suporte ao S4
BIOS em vez do S4
suportado pelo sistema operacional.
Ao testar as ações de suspend/resume, inicie com o S1
, se suportado. É mais provável que esse estado funcione, pois não requer muito suporte ao driver. Ninguém implementou S2
, que é similar ao S1
. Em seguida, tente o S3
. Este é o estado mais profundo do STR e requer muito suporte ao driver para reinicializar corretamente o hardware.
Um problema comum com suspend/resume é que muitos drivers de dispositivo não salvam, restauram ou reinicializam seu firmware, registros ou memória do dispositivo adequadamente. Como primeira tentativa de depuração do problema, tente:
#
sysctl debug.bootverbose=1
#
sysctl debug.acpi.suspend_bounce=1
#
acpiconf -s 3
Esse teste emula o ciclo de suspend/resume de todos os drivers de dispositivo sem entrar realmente no estado S3
. Em alguns casos, problemas como perder o estado do firmware, tempo limite do watchdog do dispositivo e tentar novamente para sempre podem ser capturados com esse método. Note que o sistema não entrará realmente no estado S3
, o que significa que os dispositivos não perderão energia, e muitos funcionarão bem mesmo se os métodos suspend/resume estiverem totalmente ausentes, ao contrário do real estado S3
.
Casos mais difíceis requerem hardware adicional, como uma porta serial e um cabo para depuração através de um console serial, uma porta Firewire e um cabo para o uso do dcons(4) e habilidades de depuração do kernel.
Para ajudar a isolar o problema, descarregue o maior número possível de drivers. Se funcionar, diminua o driver que é o problema carregando os drivers até que ele falhe novamente. Normalmente, drivers binários como nvidia.ko
, drivers de exibição e USB terão mais problemas, enquanto as interfaces Ethernet normalmente funcionam bem. Se os drivers puderem ser carregados e descarregados adequadamente, automatize isso colocando os comandos apropriados em /etc/rc.suspend
e /etc/rc.resume
. Tente configurar o hw.acpi.reset_video
para 1
se a tela estiver desarrumada após a retomada. Tente definir valores mais longos ou mais curtos para hw.acpi.sleep_delay
para ver se isso ajuda.
Tente carregar uma distribuição recente do Linux® para ver se o suspend/resume funciona no mesmo hardware. Se funciona no Linux®, é provável que seja um problema no driver do FreeBSD. Descobrir qual driver causa o problema ajudará os desenvolvedores a corrigir o problema. Como os mantenedores do ACPI raramente mantêm outros drivers, como som ou ATA, qualquer problema de driver também deve ser postado na lista freebsd-current e enviada para o mantenedor do driver. Os usuários avançados podem incluir os printf(3)s de debug do driver problemático para rastrear onde, em sua função de reinício, ele é interrompido.
Por fim, tente desativar o ACPI e ativar o APM. Se o comando suspend/resume funcionar com APM, use o APM, especialmente em hardware mais antigo (anterior a 2000). Demorou algum tempo para que os fornecedores obtivessem suporte ACPI correto e os hardwares antigos são mais prováveis de terem problemas de BIOS com ACPI.
A maioria dos travamentos do sistema é resultado de interrupções perdidas ou de uma tempestade de interrupções. Chipsets podem ter problemas com base na inicialização, como o BIOS configura as interrupções antes da correção da tabela APIC (MADT) e o roteamento do sistema de controle de interrupções (SCI).
Tempestades de interrupção podem ser distinguidas de interrupções perdidas, verificando a saída do vmstat -i
e observando a linha que possui acpi0
. Se o contador está aumentando em mais de um par por segundo, há uma tempestade de interrupção. Se o sistema parece travado, tente acessar o DDB (CTRL+ALT+ESC no console) e digite show interrupts
.
Ao lidar com problemas de interrupção, tente desativar o suporte ao APIC com hint.apic.0.disabled="1"
no /boot/loader.conf
.
Os panics são relativamente raros para ACPI e são a prioridade máxima a ser corrigida. O primeiro passo é isolar as etapas para reproduzir o panic, se possível, e obter um backtrace. Siga as instruções para habilitar options DDB
e configurar um console serial em Seção 26.6.4, “Entrando no Depurador DDB da Linha Serial” ou configurar uma partição de despejo. Para obter um backtrace no DDB, use tr
. Ao escrever o backtrace, obtenha pelo menos as cinco últimas e as cinco principais linhas do rastro.
Em seguida, tente isolar o problema inicializando com ACPI desabilitado. Se isso funcionar, isole o subsistema ACPI usando vários valores de debug.acpi.disable
. Veja acpi(4) para alguns exemplos.
Primeiro, tente definir hw.acpi.disable_on_poweroff="0"
no /boot/loader.conf
. Isso impede que a ACPI desative vários eventos durante o processo de desligamento. Alguns sistemas precisam desse valor definido como 1
(o padrão) pelo mesmo motivo. Isso geralmente corrige o problema de um sistema ser ativado espontaneamente após uma suspensão ou desligamento.
Alguns fornecedores de BIOS fornecem bytecode incorreto ou com bugs. Isso geralmente é manifestado por mensagens do console do kernel como esta:
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND
Geralmente, esses problemas podem ser resolvidos com a atualização do BIOS para a revisão mais recente. A maioria das mensagens do console é inofensiva, mas se houver outros problemas, como o status da bateria não estar funcionando, essas mensagens são um bom lugar para começar a procurar por problemas.
O bytecode do BIOS, conhecido como ACPI Machine Language (AML), é compilado de uma linguagem de origem chamada ACPI Source Language (ASL). O AML é encontrado na tabela conhecida como Tabela de Descrição do Sistema Diferenciado (Differentiated System Description Table - DSDT).
O objetivo do FreeBSD é que todos trabalhem com ACPI sem qualquer intervenção do usuário. Soluções alternativas ainda estão sendo desenvolvidas para erros comuns feitos pelos fornecedores de BIOS. O interpretador Microsoft® (acpi.sys
e acpiec.sys
) não verifica rigorosamente a conformidade com o padrão e, portanto, muitos fornecedores de BIOS que testam apenas ACPI sob Windows® nunca corrigem seu ASL. Os desenvolvedores do FreeBSD continuam a identificar e documentar qual comportamento não padrão é permitido pelo interpretador da Microsoft® para replicá-lo para que o FreeBSD possa funcionar sem forçar os usuários a corrigir o ASL.
Para ajudar a identificar o comportamento de bugs e possivelmente corrigi-lo manualmente, uma cópia pode ser feita do ASL do sistema. Para copiar o ASL do sistema para um nome de arquivo especificado, use acpidump
com -t
, para mostrar o conteúdo das tabelas fixas e -d
, para desmontar o AML:
#
acpidump -td >
my.asl
Algumas versões de AML assumem que o usuário está executando o Windows®. Para sobrescrever isto, defina hw.acpi.osname=
no "Windows 2009"
/boot/loader.conf
, usando a mais recente versão do Windows® listada no ASL.
Outras soluções alternativas podem exigir que o my.asl
seja personalizado. Se este arquivo for editado, compile o novo ASL usando o seguinte comando. Os avisos geralmente podem ser ignorados, mas erros são bugs que geralmente impedem que o ACPI funcione corretamente.
#
iasl -f
my.asl
Incluir -f
força a criação do AML, mesmo que haja erros durante a compilação. Alguns erros, como a falta de declarações de retorno, são automaticamente contornados pelo interpretador do FreeBSD.
O nome do arquivo de saída padrão para iasl
é DSDT.aml
. Carregue este arquivo em vez da cópia com bugs do BIOS, que ainda está presente na memória flash, editando o /boot/loader.conf
como segue:
acpi_dsdt_load="YES" acpi_dsdt_name="/boot/DSDT.aml"
Certifique-se de copiar o DSDT.aml
para /boot
e, em seguida, reinicialize o sistema. Se isso resolver o problema, envie um diff(1) do antigo e novo ASL para a lista freebsd-acpi para que os desenvolvedores possam contornar o comportamento de bugs no acpica
.
O driver ACPI possui um recurso de depuração flexível. Um conjunto de subsistemas e o nível de detalhamento podem ser especificados. Os subsistemas a serem depurados são especificados como camadas e são divididos em componentes (ACPI_ALL_COMPONENTS
) e suporte de hardware ACPI (ACPI_ALL_DRIVERS
). O detalhamento da saída de depuração é especificado como o nível e varia de apenas erros de relatório (ACPI_LV_ERROR
) para tudo (ACPI_LV_VERBOSE
). O nível é uma máscara de bits, por isso, várias opções podem ser definidas de uma só vez, separadas por espaços. Na prática, um console serial deve ser usado para registrar a saída para que ela não seja perdida quando o buffer de mensagem do console for liberado. Uma lista completa das camadas e níveis individuais é encontrada em acpi(4).
A saída de depuração não está ativada por padrão. Para ativá-la, adicione as opções ACPI_DEBUG
ao arquivo de configuração do kernel personalizado se ACPI estiver compilado no kernel. Adicione ACPI_DEBUG=1
ao /etc/make.conf
para ativá-lo globalmente. Se um módulo for usado em vez de um kernel personalizado, recompile apenas o módulo acpi.ko
como segue:
#
cd /sys/modules/acpi/acpi && make clean && make ACPI_DEBUG=1
Copie o acpi.ko
compilado para /boot/kernel
e adicione o nível e camada desejados ao /boot/loader.conf
. As entradas neste exemplo permitem mensagens de depuração para todos os componentes e drivers de hardware ACPI e mensagens de erro de saída no nível menos detalhado:
debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ERROR"
Se as informações necessárias forem acionadas por um evento específico, como suspend e resume, não modifique o /boot/loader.conf
. Em vez disso, use o sysctl
para especificar o layer e o nível após inicializar e preparar o sistema para o evento específico. As variáveis que podem ser definidas usando sysctl
são nomeadas da mesma forma que os parâmetros no /boot/loader.conf
.
Depois que as informações de depuração forem coletadas, elas podem ser enviadas para a lista freebsd-acpi para que possam ser usadas pelos mantenedores do FreeBSD ACPI para identificar a causa raiz do problema e desenvolver uma solução.
Antes de enviar as informações de depuração para esta lista, certifique-se de que a versão mais recente do BIOS esteja instalada e, se disponível, a versão do firmware do controlador incorporado.
Ao enviar um relatório de problemas, inclua as seguintes informações:
Descrição do comportamento de bugs, incluindo tipo de sistema, modelo e qualquer coisa que faça com que o erro apareça. Explique com a maior precisão possível quando o bug começou a ocorrer se for novo.
A saída do dmesg
após executar boot -v
, incluindo quaisquer mensagens de erro geradas pelo bug.
A saída dmesg
do boot -v
com o ACPI desabilitado, se a desativação do ACPI ajudar a corrigir o problema.
Saída do sysctl hw.acpi
. Isso lista quais recursos o sistema oferece.
A URL para uma versão do ASL do sistema hospedada na web. Não envie o ASL diretamente para a lista, pois pode ser muito grande. Gere uma cópia do ASL executando este comando:
#
acpidump -dt >
name
-system
.asl
Substitua o nome de login para name
e fabricante/modelo para system
. Por exemplo, use njl-FooCo6000.asl
.
A maioria dos desenvolvedores do FreeBSD assina a lista de discussão FreeBSD-CURRENT, mas deve-se enviar os problemas para a lista freebsd-acpi para ter certeza de que ele será visto. Seja paciente ao esperar por uma resposta. Se o bug não for imediatamente aparente, envie um relatório de bug. Ao inserir um PR, inclua as mesmas informações solicitadas acima. Isso ajuda os desenvolvedores a rastrear o problema e resolvê-lo. Não envie um PR sem enviar primeiro um e-mail para a lista freebsd-acpi pois é provável que o problema já tenha sido relatado antes.
Mais informações sobre ACPI podem ser encontradas nos seguintes locais:
Arquivos da lista de e-mail do FreeBSD ACPI (https://lists.freebsd.org/pipermail/freebsd-acpi/
)
A especificação ACPI 2.0 (http://acpi.info/spec.htm
)
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.