On Mon, 13 Jan 2020 00:22:04 +0100, User Ribbon wrote:
On Mon, Jan 13, 2020 at 01:09:47AM +0900, ikoga@opensuse.org wrote:
koga です。
私も同じような症状に遭遇したことがあります。もう手元にはないの ですが、そのとき使っていた PC は、以下の dynabook です。 http://dynabook.com/pc/catalog/dyna_b/140708r634/index_j.htm
2014年くらいのものですか。今現象が出ているPCもその時代のものです。
今調べてみると、以下の記事が事象として類似しています。 https://unix.stackexchange.com/questions/296653/rebooting-instead-of-shutdow...
稀に正常にシャットダウンできることもあるのですが、ほとんどの場合 数秒後に電源が入ってしまう状況だったので、当時は諦めて reboot し たあとに grub の画面からコンソールに落ち、halt コマンドを打って 電源断することができたので、それで回避していました。
早速やってみました。
grub ->halt OK(シャットダウンする) debian 起動、poweroff -> OK debian 起動、reboot ->OK debian 起動 poweroff -> NG(再起動する)
となりました。 一度正常にpoweroff できれば、そのあとは正常にpoweroff できるようです。 ただ、一度reboot してしまうと、あとは駄目みたいです。
2014年前後のPCで現象が出ているとなると、そのあたりのCPUとかチップセット にうまく対応していないのかもしれませんね。Linuxが。
おそらく、カーネルのACPI周りかUSBもしくはWiFiチップのドライバの変更な
どだと思われます。
この手の問題はしょっちゅう出てきていて、カーネルのコードはワークアラウ
ンドだらけなのですが、大抵、特定の機種やモデルでしか再現できないので処
置が難しいのです。そもそも、ほとんどがBIOSのバグのせいですしね。
で、どうするかというと、まずは余計な起動となる元を特定する必要がありま
す。/proc/acpi/wakeup を覗いてみて下さい。いくつかの項目でenabledになっ
ていると思いますが、それらを全てdisabledにしてください。
例えばXHCIがenabledになっているのであれば
# echo -n XHCI > /proc/acpi/wakeup
とprocファイルに書き込めば変更されるはずです。
もし、これでリブートが再現しないのであれば、変更したデバイスが元凶です。
(そこからまた色々調べる必要があるのですが、それは後の話。)
これ以外の場合は、例えばethtoolでWoLの設定を調べて下さい。
あとはBIOSの設定項目とかでしょうか。
もし、カーネルのバージョンによって挙動が異なるのあれば、どのバージョン
からバグが始まったかを見つけて頂ければありがたいです。
--
Takashi Iwai