Como os drivers oficiais NVIDIA 391.xx não suportam Linux 6.x, sou forçado a usar o noveau, mas o desempenho é muito ruim. Existe uma versão não oficial desses drivers para kernels Linux mais novos? Agradeço antecipadamente por sua resposta.
Li que não se deve usar uma chamada de sistema de bloqueio em um manipulador de interrupção.
Para sistemas de processador único, isso faz sentido, mas, para sistemas multiprocessadores, tal operação de bloqueio realmente bloqueará o sistema inteiro? Ou apenas o processador em que ele roda?
Então, atualmente estou aprendendo a escrever módulos de kernel/drivers de dispositivo e estava analisando a implementação de unregister_chrdev_region:
https://elixir.bootlin.com/linux/v6.12/source/fs/char_dev.c#L311
/**
* unregister_chrdev_region() - unregister a range of device numbers
* @from: the first in the range of numbers to unregister
* @count: the number of device numbers to unregister
*
* This function will unregister a range of @count device numbers,
* starting with @from. The caller should normally be the one who
* allocated those numbers in the first place...
*/
void unregister_chrdev_region(dev_t from, unsigned count)
{
dev_t to = from + count;
dev_t n, next;
for (n = from; n < to; n = next) {
next = MKDEV(MAJOR(n)+1, 0);
if (next > to)
next = to;
kfree(__unregister_chrdev_region(MAJOR(n), MINOR(n), next - n));
}
}
O que não entendo é a verificação nesta linha:
https://elixir.bootlin.com/linux/v6.12/source/fs/char_dev.c#L318
if (next > to) next = to;
O loop, como eu vejo, já quebra quando a variável do loop é igual ao limite superior to = from + count. Quando teríamos o caso de encontrarmos o condicional if (next > to)? Qual é o motivo dessa verificação condicional?
Meu laptop Linux (openSUSE Tumbleweed) deveria hibernar, mas não hiberna e não entendo o porquê. Já tive sistemas semelhantes (Arch Linux) hibernando nas mesmas circunstâncias (LVM no LUKS). Aqui está minha configuração:
- Inicialização EFI-GRUB
- LVM no LUKS; LVM tem partições raiz, home e swap
- Swap habilitado e montado por UUID em
/etc/fstab,swapon -smostra que ele está ativo. Ele tem 32 GB de tamanho com 16 GB de RAM instalados. - O GRUB tem instruções resume na configuração padrão e
/boot/grub2/grub.cfg(veja abaixo).
Aqui estão alguns comandos para verificar os recursos de hibernação do kernel e do sistema:
# zgrep HIBERN /proc/config.gz
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_HIBERNATION_SNAPSHOT_DEV=y
CONFIG_HIBERNATION_COMP_LZO=y
# CONFIG_HIBERNATION_COMP_LZ4 is not set
CONFIG_HIBERNATION_DEF_COMP="lzo"
Então o kernel está configurado para suportar hibernação.
Esta bota (da GRUB) tem:
# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.11.6-2-default root=/dev/mapper/cryptolvm-opensuse splash=silent resume=/dev/mapper/cryptolvm-swap mem_sleep_default=deep security=selinux selinux=1 enforcing=1 mitigations=auto
Tentei variar resume=o uso UUID=....com o UUID do swap, mas não tive efeito.
# cat /sys/power/state
freeze mem
Aqui diskestá faltando, mas não sei por quê.
Claro que isso não vai funcionar agora:
# systemctl hibernate
Call to Hibernate failed: Sleep verb 'hibernate' is not configured or configuration is not supported by kernel
Exit 1
O kernel depende do BIOS para habilitar a hibernação? (Não que eu saiba.) Nesse caso, posso verificar algo lá?
Minha tarefa é a seguinte: é necessário ler todos os dados do firmware UEFI do chip BIOS e calcular a checksumquantidade desses dados.
Como isso pode ser feito (qual é a área de memória do firmware UEFI e é possível ler o firmware UEFI do kernel Linux)?
Eu sei que o comando dmesg imprime a mensagem armazenada em um buffer de anel. Mas, a partir do código-fonte do Linux, qual é o nome do buffer? Quero olhar para o buffer depois que o Linux for encerrado sem nenhuma mensagem. Suspeito que não seja por uma armadilha de software (portanto, nenhuma mensagem de pânico), mas posso examinar a memória (com algum System.map e conversão de endereço virtual para físico).
Estou planejando usar a habilidade de criptografia de arquivos Ext4. Tudo funciona bem, mas ainda há um problema. Depois de remover a SENHA via keyctl, ainda consigo ver o conteúdo do diretório criptografado. Tentei deletar a chave, sincronizar e esvaziar o cache de páginas, desmontar o sistema de arquivos, reiniciar o gerenciador de arquivos caja e montar o fs novamente. Mas não funciona. Embora eu não consiga mais escrever no diretório, ainda consigo ver nomes claros.
Como esvazio o cache do KeyRing do Kernel? (sem reinicializar ou reiniciar minha sessão X)
Fontes:
Estou observando um comportamento muito estranho.
/proc/1154/cmdlineexiste, e kill -0 1154tem sucesso, mas ps -ef | grep 1154não ls /proc | grep 1154mostra nada.
1154 era um processo postgres no meio do desligamento (ou os logs dizem, mas talvez eles não tenham sido liberados) quando a VM foi reiniciada.
Como isso é possível?
Eu compilei e instalei um driver Linux, mas agora não tenho certeza de como realmente usá-lo no meu código.
O driver é para o amplificador de termopar mcp9600, ele não está no meu kernel por padrão (kernel versão 6.6), mas o código-fonte está disponível aqui: https://github.com/torvalds/linux/blob/master/drivers/iio/temperature/mcp9600.c
Compilei e instalei o driver com sucesso (presumo), pois consigo encontrar arquivos em /sys:
>ls /sys/module/mcp9600
coresize holders initstate refcnt taint
drivers initsize notes sections uevent
>ls /sys/bus/i2c/drivers/mcp9600
bind module uevent unbind
No entanto, não há nada em /dev
O que preciso fazer para ler dados de temperatura deste chip a partir de código C ou script de shell?
Isso está no Debian em um dispositivo embarcado arm64.
De acordo com a documentação dos parâmetros do kernel kexec_load_disabled ,
Este valor padrão é 0 (falso: kexec_load habilitado), mas pode ser definido como 1 (verdadeiro: kexec_load desabilitado). Uma vez verdadeiro, kexec não pode mais ser usado, e o toggle não pode ser definido de volta para falso.
O que esta documentação diz é que se este parâmetro for definido como true, ou seja, 1, então, uma vez que o kernel é carregado, ele não pode ser descarregado em tempo de execução e um novo kernel carregado em seu lugar. Então, se o kernel 6.10.13 for instalado na máquina com o parâmetro kernel kexec_load_disableddefinido como 1, isso impactará a atualização do kernel para a versão 6.11.2? Isso impedirá isso mesmo após uma reinicialização?
Além disso, se esse parâmetro for definido como true, não impede que entradas sejam manipuladas no carregador de boot como o GRUB. Então, no GRUB, uma entrada pode ser feita para carregar alguma outra versão do kernel. Meu entendimento está correto?