11.13. Gerenciamento de energia e recursos
Anterior | Capítulo 11. Configuração e Ajuste | Próxima

## 11.13. Gerenciamento de energia e recursos

Escrito por Hiten Pandya e Tom Rhodes .

É 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.

### 11.13.1. Configurando o 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”.

### Nota:

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.

### 11.13.2. Problemas comuns

O ACPI está presente em todos os computadores modernos que estão em conformidade com as arquiteturas ia32 (x86), ia64 (Itanium) 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.

#### 11.13.2.1. Problemas do mouse

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`.

#### 11.13.2.2. Suspend/Resume

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.

#### 11.13.2.3. Travamentos do sistema

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` .

#### 11.13.2.4. Panics

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.

#### 11.13.2.5. O sistema é ativado após a sua suspensão ou desligamento

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.

#### 11.13.2.6. BIOS contém Bytecode com bugs

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.

### 11.13.3. Substituindo o padrão AML

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=`"Windows 2009"`` no `/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`.

### 11.13.4. Obtendo e enviando informações de depuração

Escrito por Nate Lawson .
com contribuições de Pedro Schultz e Tom Rhodes .

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.

### Nota:

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.

### 11.13.5. Referências

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`)

- acpi(4), acpi_thermal(4), acpidump(8), iasl(8), e acpidb(8)

Anterior | Acima | Próxima
11.12. Adicionando Espaço de Swap | Principal | Capítulo 12. O processo de inicialização do FreeBSD

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>.