Eu tenho um Alienware Aurora R7, rodando o Arch Linux. No desligamento, o kernel entra em pânico, com algo assim na mensagem de pânico (omitindo timestamps):
BUG: Unable to handle kernel NULL pointer dereference at (null)
IP: i2c_dw_isr+0x3ef/0x6d0
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
De várias fontes ( 1 , 2 ), isso parece estar relacionado ao i2c-designware-core
módulo e a solução alternativa é colocá-lo na lista negra. No entanto, com kernels recentes (parece ser 4.10 e superior), isso não parece ser construído como um módulo:
# uname -srv
Linux 4.15.2-2-ARCH #1 SMP PREEMPT Thu Feb 8 18:54:52 UTC 2018
# zgrep DESIGNWARE /proc/config.gz
CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_DESIGNWARE_SLAVE=y
CONFIG_I2C_DESIGNWARE_PCI=m
CONFIG_I2C_DESIGNWARE_BAYTRAIL=y
CONFIG_SPI_DESIGNWARE=m
CONFIG_SND_DESIGNWARE_I2S=m
CONFIG_SND_DESIGNWARE_PCM=y
Então, recorri a fazer a reinicialização do kernel em pânico:
# cat /proc/cmdline
root=UUID=e5018f7e-5838-4a47-b146-fc1614673356 rw initrd=/intel-ucode.img initrd=/initramfs-linux.img panic=10 sysrq_always_enabled=1 printk.devkmsg=on
(Os caminhos estranhos no /proc/cmdline
são porque eu inicializo diretamente do UEFI, com entradas criadas usando efibootmgr
. Os caminhos são enraizados em /boot
, onde meu ESP está montado.)
Isso parece ser algo para touchpads, mas não tenho um touchpad e não vou conseguir um. O que posso fazer para desativar essa coisa? Eu tenho que construir um kernel personalizado ?
Como linux-lts
também é mais recente que 4.10 (4.14, atualmente), também não parece haver uma maneira fácil de instalar um kernel mais antigo, onde a lista negra provavelmente funcionaria.
Usar nolapic
como parâmetro do kernel resolve o problema de pânico de desligamento, mas faz com que o sistema congele alguns minutos após a inicialização, então não posso usá-lo.
Depois de ler as fontes do kernel, encontrei uma função que precisamos colocar na lista negra!
Obrigado a Stephen Kitt pela dica sobre
initcall_blacklist
.Adicione
initcall_blacklist=dw_i2c_init_driver
à linha de comando do kernel. Isso funciona para mim no kernel 4.15.0.Para qualquer outra pessoa que encontrará esta resposta. Você pode fazer isso editando
/etc/default/grub
:sudo -H gedit /etc/default/grub
.GRUB_CMDLINE_LINUX_DEFAULT
:GRUB_CMDLINE_LINUX_DEFAULT="… initcall_blacklist=dw_i2c_init_driver"
.sudo update-grub
.Adicionar
initcall_blacklist=i2c_dw_init_master
à linha de comando do kernel deve impedir a inicialização do driver Designware durante a inicialização e evitar o problema completamente.Consulte os parâmetros do kernel para obter uma breve descrição de
initcall_blacklist
, e o tópico sobre o patch para obter informações básicas mais úteis.Experimentando várias maneiras de desligar, parece que inicializar o Linux no
poweroff
destino usandosystemd.unit=poweroff.target
como um parâmetro do kernel desliga bem.Portanto, enquanto espero por uma solução melhor, adicionei uma entrada de inicialização que simplesmente desliga. Isso é fácil com o GRUB (e presumivelmente com outros gerenciadores de inicialização), mas não consegui descobrir uma maneira de desligar o próprio UEFI. E parece que a implementação UEFI do Alienware não suporta várias entradas para o mesmo arquivo, então acabei copiando
vmlinuz-linux
e adicionando uma entrada para a cópia:Aqui as opções de disco e partição são específicas para o meu sistema. A entrada de inicialização criada aqui foi numerada
0001
, então umoff
script para dar um desligamento limpo:Provavelmente existe uma maneira mais simples de ter um destino de desligamento UEFI.