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版のリリースノートを転記します。
firmware: arm_loader: Respect all required frequencies when throttling
firmware: Fixup vcgencmd display_power return values
firmware: Reduce voltage as part of DVFS
firmware: arm-loader: Inherit 2711 mac-address from the bootloader
See: http://git/vc4/vc4/merge_requests/6872019-11-19版のリリースノートで気になったのはこれです。
firmware: arm_loader: Respect all required frequencies when throttling
2019-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箇所です。
vcgencmdで情報を取得する代わりに、以下から値を読み取る方式にしてみたいと思います。
温度取得
/sys/class/thermal/thermal_zone0/temp
アラート取得
/sys/devices/platform/soc/soc:firmware/get_throttled
ARMクロック取得(実装中)
/sys/devices/platform/soc/soc:firmware/arm_freq
COREクロック取得(実装中)
/sys/devices/platform/soc/soc:firmware/core_freq
vcgencmdを使用しないバージョンを用意してみました。
下記の手順でカーネル・シェルを入れ替えてください。
wget https://www.symphonic-mpd.com/release/kernel_20200711_v106.tar.gz
tar xf kernel_20200711_v106.tar.gz
cd kernel_20200711_v106
./kernel_install.sh
reboot
GPUブートローダはv1.0.5のデフォルトのファイルに戻してください。
この方式なら音質を損なうことがありませんので、これで問題を回避できれば一番いいのですが。
さて、どうでしょうか。