Ou seja, o seguinte comando falha às vezes:
$ sudo reboot
A última mensagem no terminal, após o que a máquina fica presa, exigindo um ciclo de energia:
Restarting system.
Eu tentei os seguintes parâmetros de inicialização reboot= ( source ) sem sucesso:
Como informado nessa página, verifiquei executando o seguinte comando para garantir que as alterações entrassem em vigor:
$ cat /proc/cmdline
Caso seja útil, aqui está uma lista de módulos do kernel:
$ lsmod
Module Size Used by
ppp_generic 16680 0
slhc 4055 1 ppp_generic
ath9k_htc 50685 0
mac80211 231186 1 ath9k_htc
ath9k_common 1720 1 ath9k_htc
ath9k_hw 338115 2 ath9k_htc,ath9k_common
ath 13793 3 ath9k_htc,ath9k_common,ath9k_hw
cfg80211 158343 3 ath9k_htc,mac80211,ath
compat 29364 5 ath9k_htc,mac80211,ath9k_common,ath9k_hw,cfg80211
Isso está em um sistema ARM, executando um Linux 2.6.35 customizado. Além disso, não há servidor X instalado, portanto, não há Ambiente de Trabalho.
Na verdade, há uma correção milenar para esta questão em particular. Eu gostaria de ter (magicamente) conhecido sobre isso antes de desperdiçar gastando muito tempo nisso.
Como sidenote, o sistema é um VAB-800 , que usa um SoC Cortex-A8 Freescale i.MX537.
Existem algumas maneiras:
sudo reboot
sudo init 6
sudo /sbin/reboot
Você também pode gostar de experimentar
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger
Se você tiver um gerenciador de sessões compatível com o freedesktop, poderá usar o DBus para chamar a reinicialização de dentro da sessão X. O comando vai:
dbus-send --system --dest=org.freedesktop.Hal --type=method_call \
--print-reply /org/freedesktop/Hal/devices/computer \
org.freedesktop.Hal.Device.SystemPowerManagement.Reboot int32:0
(isso é provavelmente mais do que necessário; funciona para mim). Eu uso isso em um script de shell. Você não precisa executar isso de root , mas precisa executá-lo dentro de uma sessão X (por exemplo, em um terminal). Você pode encontrar mais sobre esse assunto no link
Se você ainda tiver o problema, mostre a saída do comando last reboot que mostrará um log de todas as reinicializações desde que o arquivo de log foi criado no Linux, digite:
# last reboot
Acho que o problema pode estar relacionado a esse bug e a bug . Tente atualizar seu kernel seguindo o método:
Use o comando apt-get . Primeiro encontre sua versão do kernel:
$ uname -r
Em seguida, encontre as imagens do kernel disponíveis:
$ apt-cache search linux-image
Agora instale o kernel especificando explicitamente o número da versão:
# apt-get install linux-image-x.x.x-xx
OR
$ sudo apt-get install linux-image-x.x.x-xx
Depois de fazer isso, você também pode tentar definir o sinalizador de inicialização do kernel reboot=pci .
Para tornar a alteração permanente, adicione o sinalizador rebooot=pci à linha GRUB_CMDLINE_LINUX de /etc/default/grub .
Para mais informações, confira este link e este
pode ser hora de considerar pegar o touro pelos chifres e aprender alguma depuração do kernel.
Primeiro, encontre uma sonda JTAG compatível com o gdb-remote. Você está usando um ARM, por isso deve ter muitas opções, por exemplo, consulte o link
Em segundo lugar, há trabalho ... "man up" no Kernel Debugging. O Google é seu amigo, mas este fornece uma excelente visão geral inicial e alguns termos de pesquisa: link
Você pode ter muitos novos conceitos para absorver. Este vídeo fornece uma boa visão de alto nível do processo: link
link tem ótimos conselhos sobre como resolver problemas difíceis. GL!
Aqui está algo para explorar / verificar. Eu encontrei este bit em um log de commit para o log commit do ARM Tegra para a versão do kernel 2.6.39 :
Simon Glass (1):
ARM: tegra: Fix hang on reboot
Eu acho que esse é o patch que o Simon comete, intitulado: [PATCH 7/7] ARM: tegra : corrigir pendurar na reinicialização , está se referindo a:
From: Simon Glass <sjg@...>
We cannot use writel() here since the resulting wmb() calls l2x0_cache_sync()
which uses a spinlock and L1 cache may be off at this point.
Signed-off-by: Simon Glass <sjg@...>
Signed-off-by: Olof Johansson <olof@...>
---
arch/arm/mach-tegra/common.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 34559d1..b1ecf60 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
<at> <at> -41,7 +41,7 <at> <at> void tegra_assert_system_reset(char mode, const char *cmd)
reg = readl(reset);
reg |= 0x04;
- writel(reg, reset);
+ writel_relaxed(reg, reset);
}
static __initdata struct tegra_clk_init_table common_clk_init_table[] = {
--
Acho que você precisará retroceder esta mudança para 2.6.35 ou mover para o kernel mais novo.
Consulte a nota de aplicação do Freescale "Usando ferramentas de depuração de código-fonte aberto para Linux em processadores i.MX" link
Especialmente no Capítulo 8 - "Primeiras Etapas para Usar o KGDB para Depuração do Kernel do Linux"
Existe um patch para o kernel Linux Freescale que permite a depuração do kernel da porta serial - link .
Alguns hackers do kernel juram que podem descobrir qualquer coisa com o printk. Consulte o link
Experimente init 6 em vez de reboot .
Este pode ser um problema BIOS .
Você pode tentar
noapic , vga=0x0f00 , pci=nobios ou mais ... Para encontrar o que está errado , o log de navegação é útil, mas não apenas os logs em que o sistema trava, mas também a leitura de registros em que tudo estava perfeito:
Um caminho pode ser executar um tipo de loop, onde você
echo >>kernlogpos.lst $(wc -l </var/log/kern.log) Ok|Bad
Depois de algum loop com e sem bug você pode obter um arquivo de rastreamento que se parece com:
19845 first
20451 Ok
21057 Ok
21676 Bad
22282 Ok
22888 Ok
Do que você poderia pesquisar por diferença (usando o bash):
diff <(
sed -ne </var/log/kern.log '21057,21676{s/^.\{15\}\s\S\+\skernel:\s\[\S\+\]\s//p;}'
) <(
sed -ne </var/log/kern.log '21676,22282{s/^.\{15\}\s\S\+\skernel:\s\[\S\+\]\s//p;}'
)
Boa sorte!