今手元にあるPCのうち、2つが、poweroff コマンドやKDEのメニューからpoweroffを 選択してもpoweroff できません。いったん電源は切れるのですが、そのあとしばらく すると、再度起動してしまいます。
BIOSではACPIをONにしています。
何か思いつくことはあるでしょうか。
ちなみにDebian でも同じ現象が出ます。
ribbon
On Sun, Jan 12, 2020 at 05:54:29PM +0900, User Ribbon wrote:
今手元にあるPCのうち、2つが、poweroff コマンドやKDEのメニューからpoweroffを 選択してもpoweroff できません。いったん電源は切れるのですが、そのあとしばらく すると、再度起動してしまいます。
BIOSではACPIをONにしています。
何か思いつくことはあるでしょうか。
ちなみにDebian でも同じ現象が出ます。
Dragon fly BSD の ISOファイルを使って試してみたら、 こちらは poweroff でちゃんと電源断となりました。
となると、poweroff (実体はsystemd?)の動作が変?
ribbon
On Sun, Jan 12, 2020 at 08:33:54PM +0900, User Ribbon wrote:
On Sun, Jan 12, 2020 at 05:54:29PM +0900, User Ribbon wrote:
今手元にあるPCのうち、2つが、poweroff コマンドやKDEのメニューからpoweroffを 選択してもpoweroff できません。いったん電源は切れるのですが、そのあとしばらく すると、再度起動してしまいます。
BIOSではACPIをONにしています。
何か思いつくことはあるでしょうか。
ちなみにDebian でも同じ現象が出ます。
Dragon fly BSD の ISOファイルを使って試してみたら、 こちらは poweroff でちゃんと電源断となりました。
となると、poweroff (実体はsystemd?)の動作が変?
現象が少し見えてきました。
dragonfly BSD で poweroff -> OK
debian で起動、poweroff -> OK debian で起動、systemctl poweroff -> OK debian で起動、reboot -> OK (リブートする) debian で起動、poweroff -> NG (リブートする) debian で起動、systemctl poweroff -> NG (リブートする) opensuse で起動(rescue)、poweroff -> NG (リブートする)
一度リブートすると、それ以降はpoweroff してもreboot 動作になります。
BIOS側が変な状態になっちゃうのかな。
ribbon
koga です。
私も同じような症状に遭遇したことがあります。もう手元にはないの ですが、そのとき使っていた PC は、以下の dynabook です。 http://dynabook.com/pc/catalog/dyna_b/140708r634/index_j.htm
今調べてみると、以下の記事が事象として類似しています。 https://unix.stackexchange.com/questions/296653/rebooting-instead-of-shutdow...
稀に正常にシャットダウンできることもあるのですが、ほとんどの場合 数秒後に電源が入ってしまう状況だったので、当時は諦めて reboot し たあとに grub の画面からコンソールに落ち、halt コマンドを打って 電源断することができたので、それで回避していました。
This is the reply to ... "Re: [opensuse-ja] openSUSE で poweroff できない" User Ribbon opensuse@ns.ribbon.or.jp wrote on 2020-01-12 21:18:23(+0900): --------------------------------------------------------------------- Message-ID: 20200112121823.GB45849@ns.ribbon.or.jp
On Sun, Jan 12, 2020 at 08:33:54PM +0900, User Ribbon wrote:
On Sun, Jan 12, 2020 at 05:54:29PM +0900, User Ribbon wrote:
今手元にあるPCのうち、2つが、poweroff コマンドやKDEのメニューからpoweroffを 選択してもpoweroff できません。いったん電源は切れるのですが、そのあとしばらく すると、再度起動してしまいます。
BIOSではACPIをONにしています。
何か思いつくことはあるでしょうか。
ちなみにDebian でも同じ現象が出ます。
Dragon fly BSD の ISOファイルを使って試してみたら、 こちらは poweroff でちゃんと電源断となりました。
となると、poweroff (実体はsystemd?)の動作が変?
現象が少し見えてきました。
dragonfly BSD で poweroff -> OK
debian で起動、poweroff -> OK debian で起動、systemctl poweroff -> OK debian で起動、reboot -> OK (リブートする) debian で起動、poweroff -> NG (リブートする) debian で起動、systemctl poweroff -> NG (リブートする) opensuse で起動(rescue)、poweroff -> NG (リブートする)
一度リブートすると、それ以降はpoweroff してもreboot 動作になります。
BIOS側が変な状態になっちゃうのかな。
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が。
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 tiwai@suse.de
On Wed, Jan 15, 2020 at 12:27:33PM +0100, Takashi Iwai wrote:
で、どうするかというと、まずは余計な起動となる元を特定する必要がありま す。/proc/acpi/wakeup を覗いてみて下さい。いくつかの項目でenabledになっ ていると思いますが、それらを全てdisabledにしてください。 例えばXHCIがenabledになっているのであれば # echo -n XHCI > /proc/acpi/wakeup とprocファイルに書き込めば変更されるはずです。
やってみました。変化無し。
これ以外の場合は、例えばethtoolでWoLの設定を調べて下さい。
ONになっていましたので、ethtoolでOffにしてpoweroff してみましたが、変化無し。
あとはBIOSの設定項目とかでしょうか。
こちらも、電源が入るようなパターンを全部OFFにしてみましたが、変化無し。
ということで、うーん、手詰まりと言うところです。
ribbon
On Fri, 17 Jan 2020 05:53:55 +0100, User Ribbon wrote:
On Wed, Jan 15, 2020 at 12:27:33PM +0100, Takashi Iwai wrote:
で、どうするかというと、まずは余計な起動となる元を特定する必要がありま す。/proc/acpi/wakeup を覗いてみて下さい。いくつかの項目でenabledになっ ていると思いますが、それらを全てdisabledにしてください。 例えばXHCIがenabledになっているのであれば # echo -n XHCI > /proc/acpi/wakeup とprocファイルに書き込めば変更されるはずです。
やってみました。変化無し。
これ以外の場合は、例えばethtoolでWoLの設定を調べて下さい。
ONになっていましたので、ethtoolでOffにしてpoweroff してみましたが、変化無し。
あとはBIOSの設定項目とかでしょうか。
こちらも、電源が入るようなパターンを全部OFFにしてみましたが、変化無し。
ということで、うーん、手詰まりと言うところです。
後は古いカーネルをテストして、現象が再現できるか、ですね。 少なくともLeap 42.xのカーネルであればLeap 15.xシステムにインストール、 ブートはできると思います。 フルスペックで動くかどうかは別問題ですが、シャットダウンのテストくらい なら行けるかもしれません。
あと、私のOBSのレポジトリにいくつか古いカーネルをストックしてあるので、 そこからバージョンを特定することもできればある程度のヒントになると思い ます。 例えば4.2.yカーネルであればhome:tiwai:kernel:4.2にありますので、 そこからダウンロードしてインストール＆テストしてみて下さい。 https://download.opensuse.org/repositories/home:/tiwai:/kernel:/4.2/standard...
-- Takashi Iwai tiwai@suse.de
Iwai 様
On Fri, Jan 17, 2020 at 10:45:05AM +0100, Takashi Iwai wrote:
後は古いカーネルをテストして、現象が再現できるか、ですね。 少なくともLeap 42.xのカーネルであればLeap 15.xシステムにインストール、 ブートはできると思います。 フルスペックで動くかどうかは別問題ですが、シャットダウンのテストくらい なら行けるかもしれません。
それがですね、HDDにインストールしてあるのはDebianで、openSUSEは Live DVDでしか試していなかったのです。 というわけで、openSUSEでテストするのはちょっと大変なのでした。
問題が発生しているマシンはテスト用なので、テストが終われば手で電源 きればよいので、この現象については対応諦めることにします。 次マシン交換したとき(いつになるかなあ)、うまく動かなければ、また 試そうと思います。
ribbon
On Fri, 17 Jan 2020 11:01:42 +0100, User Ribbon wrote:
Iwai 様
On Fri, Jan 17, 2020 at 10:45:05AM +0100, Takashi Iwai wrote:
後は古いカーネルをテストして、現象が再現できるか、ですね。 少なくともLeap 42.xのカーネルであればLeap 15.xシステムにインストール、 ブートはできると思います。 フルスペックで動くかどうかは別問題ですが、シャットダウンのテストくらい なら行けるかもしれません。
それがですね、HDDにインストールしてあるのはDebianで、openSUSEは Live DVDでしか試していなかったのです。 というわけで、openSUSEでテストするのはちょっと大変なのでした。
なるほど、それだと面倒ですね。
問題が発生しているマシンはテスト用なので、テストが終われば手で電源 きればよいので、この現象については対応諦めることにします。 次マシン交換したとき(いつになるかなあ)、うまく動かなければ、また 試そうと思います。
何か原因もしくはリグレッションの範囲が特定できれば是非レポートお願いし ます。
-- Takashi Iwai tiwai@suse.de
On Fri, 17 Jan 2020 05:53:55 +0100, User Ribbon wrote:
On Wed, Jan 15, 2020 at 12:27:33PM +0100, Takashi Iwai wrote:
で、どうするかというと、まずは余計な起動となる元を特定する必要がありま す。/proc/acpi/wakeup を覗いてみて下さい。いくつかの項目でenabledになっ ていると思いますが、それらを全てdisabledにしてください。 例えばXHCIがenabledになっているのであれば # echo -n XHCI > /proc/acpi/wakeup とprocファイルに書き込めば変更されるはずです。
やってみました。変化無し。
これ以外の場合は、例えばethtoolでWoLの設定を調べて下さい。
ONになっていましたので、ethtoolでOffにしてpoweroff してみましたが、変化無し。
あとはBIOSの設定項目とかでしょうか。
こちらも、電源が入るようなパターンを全部OFFにしてみましたが、変化無し。
ということで、うーん、手詰まりと言うところです。
丁度今日他のバグ関連で、古いHaswellのラップトップをテストしている最中 に思い出したのですが、以前USB3でこの手のバグが出てた気がします。 以下のブートオプションを試してみて下さい。 xhci_hcd.quirks=0x42000
-- Takashi Iwai tiwai@suse.de
On Thu, Jan 23, 2020 at 02:16:20PM +0100, Takashi Iwai wrote:
丁度今日他のバグ関連で、古いHaswellのラップトップをテストしている最中 に思い出したのですが、以前USB3でこの手のバグが出てた気がします。 以下のブートオプションを試してみて下さい。 xhci_hcd.quirks=0x42000
できました!
これが正解だったようです。
ありがとうございました。
ribbon
On Thu, 23 Jan 2020 14:42:44 +0100, User Ribbon wrote:
On Thu, Jan 23, 2020 at 02:16:20PM +0100, Takashi Iwai wrote:
丁度今日他のバグ関連で、古いHaswellのラップトップをテストしている最中 に思い出したのですが、以前USB3でこの手のバグが出てた気がします。 以下のブートオプションを試してみて下さい。 xhci_hcd.quirks=0x42000
できました!
これが正解だったようです。
ありがとうございました。
おお、それは良かった。 それでは 0x40000 か 0x2000 で試して頂けますか？ どちらか片方でも行けると思うのですが（おそらく後者）。
-- Takashi Iwai tiwai@suse.de
On Thu, Jan 23, 2020 at 02:51:37PM +0100, Takashi Iwai wrote:
おお、それは良かった。 それでは 0x40000 か 0x2000 で試して頂けますか？ どちらか片方でも行けると思うのですが（おそらく後者）。
はい、0x2000 でうまくいきました。 0x40000 ではだめでした。
なお、ちゃんとpoweroff したあと、wakeonlan もちゃんと動きました。
ribbon
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%... ここの「サスペンドからすぐに復帰する」に書かれている事象と全く 同じで、以下のようなワークアラウンドを入れています。(相変わら ず 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@suse.de wrote on 2020-01-15 20:27:33(+0900): --------------------------------------------------------------------- Message-ID: s5h4kwxariy.wl-tiwai@suse.de
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の設定項目とかでしょうか。
もし、カーネルのバージョンによって挙動が異なるのあれば、どのバージョン からバグが始まったかを見つけて頂ければありがたいです。
On Sat, Jan 18, 2020 at 02:48:47PM +0900, ikoga@opensuse.org wrote:
事象は少し異なるのですが、こちらのリプライで、今使っている PC も ACPI 周りで問題を抱えていることを思い出しました。サスペンド 中に、USB ケーブルを差し抜きすると電源が入ってしまうのです。
https://wiki.archlinux.jp/index.php/%E3%82%B5%E3%82%B9%E3%83%9A%E3%83%B3%E3%... ここの「サスペンドからすぐに復帰する」に書かれている事象と全く 同じで、以下のようなワークアラウンドを入れています。
このページに書いてあった、Intel Haswell アーキテクチャで問題が出る、 ということで調べてみたら、対象PCのCPUは i3-4000M でまさに Haswellでした。
あと、disable-USB-wakeup.serviceは、手元でやったことと同じでしたので、 やはりうまくいきませんでした。
やはり、CPUを取り替える(=マシンを取り替える)のがbetter かなあ。 でも、まだまだ現役で全然不自由してないので、捨てるのもったいないしなあ。
ribbon
-
ikoga＠opensuse.org -
Takashi Iwai -
User Ribbon