Mailinglist Archive: opensuse-ja (20 mails)

< Previous Next >
Re: [opensuse-ja] openSUSE で poweroff できない
koga です。

おそらく、カーネルのACPI周りかUSBもしくはWiFiチップのドライバの変更な
どだと思われます。
この手の問題はしょっちゅう出てきていて、カーネルのコードはワークアラウ
ンドだらけなのですが、大抵、特定の機種やモデルでしか再現できないので処
置が難しいのです。そもそも、ほとんどがBIOSのバグのせいですしね。

で、どうするかというと、まずは余計な起動となる元を特定する必要がありま
す。/proc/acpi/wakeup を覗いてみて下さい。いくつかの項目でenabledになっ
ていると思いますが、それらを全てdisabledにしてください。
例えばXHCIがenabledになっているのであれば
# echo -n XHCI > /proc/acpi/wakeup
とprocファイルに書き込めば変更されるはずです。

もし、これでリブートが再現しないのであれば、変更したデバイスが元凶です。
(そこからまた色々調べる必要があるのですが、それは後の話。)

事象は少し異なるのですが、こちらのリプライで、今使っている PC
も ACPI 周りで問題を抱えていることを思い出しました。サスペンド
中に、USB ケーブルを差し抜きすると電源が入ってしまうのです。

https://wiki.archlinux.jp/index.php/%E3%82%B5%E3%82%B9%E3%83%9A%E3%83%B3%E3%83%89%E3%81%A8%E3%83%8F%E3%82%A4%E3%83%90%E3%83%8D%E3%83%BC%E3%83%88
ここの「サスペンドからすぐに復帰する」に書かれている事象と全く
同じで、以下のようなワークアラウンドを入れています。(相変わら
ず Arch Linux はドキュメントが充実してて羨ましい...)


$ cat /etc/systemd/system/disable-USB-wakeup.service
[Unit]
Description=Disable USB wakeup triggers in /proc/acpi/wakeup

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo EHC1 > /proc/acpi/wakeup; echo EHC2 >
/proc/acpi/wakeup; echo XHC > /proc/acpi/wakeup"
ExecStop=/bin/sh -c "echo EHC1 > /proc/acpi/wakeup; echo EHC2 >
/proc/acpi/wakeup; echo XHC > /proc/acpi/wakeup"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

$ ls -l /etc/systemd/system/disable-USB-wakeup.service
-rw-r--r-- 1 root root 377 11月 10 2017
/etc/systemd/system/disable-USB-wakeup.service

いつからだったか忘れましたが、マザーボードが壊れて入れ替えた時
か、openSUSE をアップグレードして、USB 3.0 デバイスに対応した
タイミングのどちらかだったと思います。

カーネルのメンテナンス、なかなか骨の折れる仕事ですね。。。
いつもありがとうございます。


This is the reply to ...
"Re: [opensuse-ja] openSUSE で poweroff できない"
Takashi Iwai <tiwai@xxxxxxx> wrote on 2020-01-15 20:27:33(+0900):
---------------------------------------------------------------------
Message-ID: <s5h4kwxariy.wl-tiwai@xxxxxxx>

On Mon, 13 Jan 2020 00:22:04 +0100,
User Ribbon wrote:

On Mon, Jan 13, 2020 at 01:09:47AM +0900, ikoga@xxxxxxxxxxxx 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-shutdown-on-linux-mint

稀に正常にシャットダウンできることもあるのですが、ほとんどの場合
数秒後に電源が入ってしまう状況だったので、当時は諦めて 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の設定項目とかでしょうか。

もし、カーネルのバージョンによって挙動が異なるのあれば、どのバージョン
からバグが始まったかを見つけて頂ければありがたいです。

--
koga <ikoga@xxxxxxxxxxxx>
< Previous Next >
Follow Ups