@パパリウス さん
20191118はNGです。
皆さまにおかれては、20191119以降を検証いただけますようお願いいたします。
ヤハリというか、短時間の検証では不具合が発生しません。
（発生する時にはバンバン発生するんですけどね）
短時間で検証する個体と放置する個体の二台で平行して検証を行っており、放置していた方でやっとNGが出るのに約二時間かかっています。
-
-
@ジャイアン さん
大変な検証にお付き合いくださりありがとうございます。
検証結果を以下のテーブルにまとめたいと思います。
（モデレータの皆様は直接編集していただいて結構です。）GPUブートローダ 合否 firm_20191118_16ce612146 NG firm_20191119_a73aff718f OK @ジャイアン firm_20191122_77dcda76ee OK @ジャイアン firm_20191129_b9ecbe8d0e firm_20191205_9300ca948e firm_20191205_fcf277b30e firm_20191211_57d3b3ac6e firm_20200106_06cb898855 firm_20200106_b2b5f9eeb5 firm_20200110_8bb38ef026 @パパリウス テスト中 firm_20200114_f0fdb006ab firm_20200116_e8da15f1ba firm_20200122_993f47507f firm_20200130_15261920fa firm_20200206_0dfefdceed NG @ジャイアン起動不良 firm_20200207_2c615323f7 NG @ジャイアン温度上昇, Under Voltage firm_20200210_397abb3c39 △（温度上昇大、ゴンザエモン） firm_20200212_23acc388b4 OK @ジャイアン firm_20200220_fd8347b54d OK @ジャイアン firm_20200228_e5d33208b7 firm_20200306_9dbd67c91d firm_20200310_b524f5e7ac OK（ゴンザエモン） firm_20200326_0ef99a4e61 firm_20200401_837c2456a7 OK（ゴンザエモン） firm_20200407_bc987d9297 firm_20200415_10f878d679 firm_20200416_b6e327eae0 firm_20200417_3cd8e820a3 firm_20200417_87fea11838 firm_20200419_62b50c3780 firm_20200420_16484e83df OK （ゴンザエモン） firm_20200427_e1050e9482 firm_20200501_8d64ec7016 firm_20200501_f0236cc587 firm_20200512_4e0af7eb74 OK -
なお、このGPUブートローダですが、カーネルなどとの連携の要はあるのでしょうか？ 全くないのであれば、逆に今まで動いていたもの（V1.0.3ベース?）を継続することで良いようにも思えるのですが。
@ゴンザエモン さん
nzatoさんのご報告によるとv1.0.0正式版で既に発生していた現象のようです。
環境によって発生頻度が異なるだけで、問題は初めから内在していたということになります。皆さんにご協力いただいた検証結果から、新しいGPUブートローダを採用することで問題が解消することは確実です。
ただ、新しいブートローダには音質低下という別の問題があります。RPi内部の電圧を各コンポーネントごとに細かく切り詰める方向で調整されていることが原因だと思いますが、、、、この音質の変化を聞いてしまうと、新ブートローダの採用にはどうしても躊躇してしまうものがあります。
ここ数日、新ブートローダを採用した状態でパラメータチューニングを試みています。
性能面だけで言えば、従来のセッティングと同等以上のチューニングができそうだという感触はあります。
ですが、出てくる音の質が違うんですよね。。。新ブートローダを採用すると、軽くて薄っぺらな方向の音になり、満足感は大幅に低下します。
美味しい設定を偶然発見するまで、時間をかけてチューニングを続ける必要があります。従来のブートローダを継続できるならそうしたいな、、、という思いが湧いてきます。
そこで、どのバージョンで問題が解消するのか特定して、リリースノートからヒントを探し、その問題だけをピンポイントで対策できないかなと期待を抱いているところです。 -
-
RPi4版 v1.0系 不具合報告スレッドで@ジャイアンが発言 :
@パパリウス さん
うけたまわりでぇ〜す。
ですが、いまのところ現象再発していません（頭から順番に検証しています）。この現象、CPU温度が関係している可能性はないでしょうか？
私の環境では、クーリングがうまくいっている個体（41℃ふきん）では発生率が低く、比較的CPU温度が高い個体（50℃後半）では高くなっています。@ジャイアン さん
仰る通り、温度も関係しているかもしれませんね。
拙宅では、RPi4開発機にバスパワーのSSDを繋ぐと発生しやすくなります。
SSD使用中はRPi本体の温度も上がりやすくなりますし、電源への負荷も大きくなります。その辺りが関係しているのかな〜と思います、、、、ちなみに、ジャイアンさんのところと同じく、現象を再現したいと思っているときには1日たっても2日たっても発生しません。:kissing:
-
パパリウスさん
為念、再確認させてください。以下のバージョンでもGPUブートローダは同じ日付のものなのでしょうか？
V1.0.3
V1..0.5 （2019年8月版とのこと）
そこそこ発生頻度のある当方環境ですが、少なくともこの二つのバージョンでは差異があると現状認識しています。もし同じブートローダだとすると、負荷あるいはCPU温度など？の条件によって大きく発生状況が異なる可能性があるため、検証自体をある程度合わせる様な確認方法を取らないといけないのかも、と思量しております。
ジャイアンさん：
当方は日付の真ん中辺りの20200210版から確認スタートしてみます。そこから順次4月、3月、2月、5月と行きつ戻りつ後ろ半分の中で範囲を絞ろうと思いますので適宜情報交換よろしくお願いいたします。（追記）
なお、ベータ版ドライバーNo３ですが、20200512版のGPUブートローダとの組み合わせでは「プチノイズ再発」いたします。
こちらの確認はV1.0.5オリジナル版のGPUブートローダとセットで行うべきものでしょうか？ -
@ゴンザエモン さん
v1.0.3とv1.0.5のGPUブートローダは全く同じバージョンです。
先日検証していただいた2020/07/02版では問題発生の報告は1例もありません。
様々な環境の違いがあるにも関わらず、ピタッと現象が解消しているということです。
どのバージョンのブートローダから「ピタッと解消」するようになったのかが分かれば、ゴンザエモンさんの環境でv1.0.3とv1.0.5で発生頻度に違いが生じる理由も明らかにすることができるかもしれません。
いったんは発生頻度の問題には目を瞑り「ピタッと解消バージョン」を探し当てることを優先したいと思います。
β3ドライバーですが、GPUブートローダとの組み合わせはあまり気になさらなくて結構です。
拙宅では、完全にゼロではないものの「ほぼゼロ」と言える程度にはプチ音がしなくなりました。
原因箇所にあたりがついたので、引き続き対策を進めてみます -
パパリウスさん、ジャイアンさん
取り急ぎ20200210版ですが、温度が上がり続け非常に危険なので検証を中断しました。（当方は外付けFanによる空冷を行っているにも関わらず、、、です）
なお、vcgencmdのレスポンスはちゃんと返っています。version : smpd pi4 edition v1.0.5
model : Raspberry Pi 4 Model B Rev 1.2
kernel : Linux 4.19.86-v8 #105 SMP PREEMPT Fri Jun 26 15:21:25 JST 2020
temp : 55.2'C
root [ ~ ]# vcgencmd measure_temp
temp=67.0'C
root [ ~ ]# vcgencmd measure_temp
temp=68.0'C
root [ ~ ]# vcgencmd measure_temp
temp=70.0'C
root [ ~ ]# vcgencmd measure_temp
temp=72.0'C
頻繁に更新されているのは、この辺りが原因かもしれませんね。
-
検証にご協力いただきありがとうございます。
2019-11-19版が「ピタッと解消バージョン」のようですね。
こちらでも追試を開始したいと思います。解消前後のバージョンである2019-11-18版と2019-11-19版のリリースノートを転記します。
2019-11-19版
firmware: arm_loader: Respect all required frequencies when throttling firmware: Fixup vcgencmd display_power return values2019-11-18版
firmware: Reduce voltage as part of DVFS firmware: arm-loader: Inherit 2711 mac-address from the bootloader See: http://git/vc4/vc4/merge_requests/687 -
-
2019-11-19版のリリースノートで気になったのはこれです。
firmware: arm_loader: Respect all required frequencies when throttling2019-11-19版よりも古いバージョンでは、温度超過のスロットリングが発生したときに、何か良からぬ動作をしてしまっているのかもしれません。
smpdのデフォルト設定では、
temp_limit=70と設定しています。この設定では65℃からスロットリングが開始されarm_freqが強制的に引き下げられます。
そして70℃に達するとarm_freqとcore_freqの両方が引き下げられます。
RPi4で放熱が甘いと、瞬間的とは言え65℃に達することは珍しくないと思います。
特にDSDのPCM変換再生のようにCPUに負荷がかかるケースでは、たとえ十分な放熱対策があったとしても65℃を超えることは十分にありえます。
もう1パターン、検証にご協力ください。
温度超過時のスロットリングが引き金になっているのかどうかを確かめたいと思います。
v1.0.5のデフォルトのGPUブートローダに戻して、config.txtのtemp_limitをコメントアウトした状態で動作検証をお願いします。
これでRPi4のデフォルト設定である
temp_limit=85で動作するようになり、80℃に達するまで温度超過によるスロットリングが発生しなくなります。
RPi4だと瞬間的に65℃を超えることはあるかもしれませんが、80℃超えはまずないでしょうから。もしこれで現象が発生しなくなれば、すべて丸く収まります。:ok_hand:
-
-
-
-
-
RPi4版 v1.0系 不具合報告スレッドで@nzatoが発言 :
@パパリウス さん
nzatoです
症状が出やすいSabreBerry32とSMPDv1.05の組み合わせに、2020-11-19版を入れて確認をしています。30分がたちましたが、ダッシュボードのLatencyが問題なく表示されます。
気になったのが、ARM1188、CORE198で、COREの値はこれで良いのでしょうか?
@nzato さん
ご報告ありがとうございます。
2019-11-19版から解消している可能性は高いですね。COREの値は2019-11-18版以降の正しい動きです。PLLやCOREの算出方法が大きく変わっため、従来とは異なる周波数が設定されます。
これはsmpdとしては大問題なので、なんとか回避しようともがいているところです。
@flyingace さん
情報ありがとうございます。
β3でどの程度解消されているか気になっているところでした。
皆さんの環境でも発生頻度が低減されたのであれば、β3で見直した箇所がビンゴ:dart: ということがはっきりしました。
場所が分かれば気が楽なものです。あとは性能を落とさずにどこまで対処するかですね。 -
-
-
-
@ジャイアン さん
ご報告ありがとうございます。
temp_limitをデフォルト(85℃)に戻すのは確実な方法ではないようですね。
（多少、発生頻度が良化しているようにも見えますが）
次は、「vcgencmdを利用しない」という対策を試してみたいと思います。
smpdでvcgencmdを利用しているのは3箇所です。
- .bashrc (sshログイン時の温度表示)
- /usr/local/bin/pipe_event.sh (extreme設定時、アラート無しなら監視系のモジュールを停止)
- /usr/local/bin/util-dashboard.sh (ダッシュボード表示時にarmクロック、coreクロック、温度、アラートを取得)
vcgencmdで情報を取得する代わりに、以下から値を読み取る方式にしてみたいと思います。
温度取得
/sys/class/thermal/thermal_zone0/tempアラート取得
/sys/devices/platform/soc/soc:firmware/get_throttledARMクロック取得(実装中)
/sys/devices/platform/soc/soc:firmware/arm_freqCOREクロック取得(実装中)
/sys/devices/platform/soc/soc:firmware/core_freq
