人気ブログランキング |

体重と今日食べたもの

k1segawa.exblog.jp

ダイエット

ブログトップ

[無限ループ・クラッシュの原因特定] Windows10 ARM 64bit Raspberry Pi 3B+ インストール&起動 [WoA2.1.1] (3/6)

前記事のGo Window ARM on Raspiはリリース直後のため、アクセスが結構あった。

新しいWoA2.1.1が出ていたので、Windowsインストール環境を劣悪にして、題記の件、何が問題か切り分けする。
原因・結論は末尾に。

SDカードを少し良くない物(KINGMAX class 10)に変更し、モニタをFHD(1920x1080 1080pこれでも中解像度だろう)のHDMI接続で、BIOSはデフォルトのDisplay=すべて[X] (チェックONの意味)。CPU=MAX(もちろんuSD Routing=Arasan SDHCI。でもSDがU1でない)。キーボードマウスを有線タイプに。AC電源は中華5V 2A microUSBコネクタ直結。HDMIモニタなのでもしかするとHDMIサウンド出力のため余計な電力を食っている可能性。そして熱対策はする。小さいヒートシンクはついてるがFANレスなので開放型ケースに入れる。Time Out=5を15にするのも地味に忘れない事。

つまり普通の方の環境に近くする。安い密閉型はダメ。

本当ならおすすめはSDカードもAC電源も高品位で、マウスキーボードはワイヤレス、接続モニタはHDMIではなく旧タイプのDVI接続で解像度1280x1024(HDMIでもいいけど1K程度でね)・MIN設定native resolutionで出来るだけ安全側に倒しておく。キーボードマウスは電力食うやつは食うからなー

WoA2.1.1は40MB程度。ISOは前に作ったやつそのままなので時短。1809/JP/Home。書き込み中に少し前処理(GPTとかあと何か)が入って3時間かかった。

あ、前のWoA2.1.0で作ったイメージはBluetoothアダプタ認識した。ペアリングも出来た。
それとスマホのUSBデザリングで通信出来た。通信の出来るUSBケーブルで繋ぐとRemote NIC なんたらかんたらとデバイスマネージャに出る。

検証内容はSDカードの中品質とHDMIモニタ接続、MAXでAC電源劣悪とUSB供給多めでのインストールかな。MAXとAC電源USB供給多めは成功例もあるので、疑っているのはHDMIモニタ接続。ラズパイにとっては高い解像度(OSインストール時という比較的複雑な処理中に限る)が問題なのだ。

それだけに条件絞ってもいいが、この手間なのでSDカードを16GBにしてページングファイルのテストとWoA2.1.1のテストも兼ねて。今のFirefox Nightly と Go と VS Code、1809累積更新プログラム適用して12GBなので。GACKT PUBG MOBILE 無線有線コンバータの通信速度の方がLAN直接より速いのはなぜ。引っかかりが少なくなった。h264ifyもあるだろうけど。
about:config
app.update.auto.migrated : true > false (Toggle Push)
browser.search.update : true > false (Toggle Push)
で軽くしてるのもあるか。
a0034780_16042482.png
ほとんど変わってない。細かいバグだけらしい。

a0034780_16042960.png

USB Image Toolでバックアップ。これでWindowsインストール時にSDが壊れても戻ってこれる。
ラズパイに刺して起動。
上記の設定どおりにする。
Windowsインストールが始まって最初デバイスやサービスの準備で固まったかと思うほど画面が変わらなかったが放っておいてもちゃんと進んだ。
USBキーボードマウス・LANすべて接続して開始している。
1時間ほどでお待ちください...青画面がnative resolutionで表示される。
1時間半ほどでリブート。窓マークの黒画面でくるくる。
1時間40分ほどでこんにちは画面。マウスもキーボードも効く。
a0034780_18344478.png
次へを押すと「PCを再起動したのはなぜですか?」の質問が。続けて次へを押す。
いつのまにかリブートしてラズベリー絵になって、ずいぶん待ってこんにちは画面に戻る。ループか?
さらに、3回目のこんにちは。ループしたわ。このまま無限ループか。

やはりHDMIでFHDだと重いんじゃないかな。
ここで、こんにちは画面で止まってるので、強制電源OFF/ON・ESCでDisplay=virtual 800 x 600 だけにしてみるか。
そしてResetを選んでね。Continueは値を反映してない状態のまま続行だから違うよ~

800x600のこんにちは画面でマウスを見失った。表示されるまで少し時間が掛かるのか。マウスが左上原点にいるから少し内側にしないとキー入力もされないみたい。
「PCを再起動したのはなぜですか?」画面が表示され、さらに進めよう。
再度ラズベリー絵になってこんにちは画面。ループか。もう一回だけ試そう。そのまま次へを押す。

よしっ。やったー。やっぱりだ。次の画面に遷移した(たまたま3回目でうまくいった可能性や電源OFF/ONで直った可能性もあるが状況証拠的に解像度だと判断。最初から今の条件+800x600での検証も本来必要)。
【原因】
やはり高解像度モニタはラズパイのメモリに対して余りにも描画用メモリの容量が大きすぎるのだ(LinuxのPIXELはなぜ動いてるかって?あちらはGPU対応ドライバがあってこっちは無いから地道にCPUがVRAM作って描画しているから。Firefox NightlyでのYoutube再生がCPUとメモリが80~100%に張り付いててディスクアクセスが少ないのはそのせい。OSインストール時にGPU使ってるようには見えない)。
解像度を落として正解だ。リセットがかかってリブートするのは、メモリ領域を超えて書き込むいわゆる「バッファーオーバーフロー」が発生しているからだろう。場合によってはクラッシュする事もありえる。

「お住まいの地域はこちらでよろしいですか?」画面になった。
「キーボードのレイアウト」で2つ目のレイアウトを追加で「日本語」を再度選択。スキップで良かったな。
ネットワークタブで「重要なセットアップを実行します。」これはWindows Updateかかってるわけではなかった。
リブートせずに「お住まいの地域は~」が出た。これは成功時も繰り返し表示されたので大丈夫だな。
今度は「キーボードのレイアウト」でスキップを押す。
「重要なセットアップ」画面。
新しい「Windowsの新機能を確認してみましょう。」画面に遷移した。
「問題が発生しました OOBEEULA」画面。成功時も出てて、やり直すボタンしかないやつだ。
やり直す。この辺PCとは違ってこなれてないな。
「Windows 10 使用許諾契約」画面に進んだ。同意を押す。
「問題が発生しました OOBEIDPS」やり直すとスキップ。成功時も出てた画面。やり直すを2回行うと進んだような。
大丈夫だった。「このPCを使うのはだれですか?」画面。半角英数のみで入力し後々のトラブル回避。
パスワード画面。少し画面が上に見切れているが縦スクロールバーを動かせば見える。これも半角英数のみで。
「秘密の答え」3つ入れる画面。Alt+半角/全角で漢字入力。
「コルテナさん」拒否。
「アクティビティ」いいえ。
「プライバシー」そのまま同意。後でも変えられる。
青画面で「お待ちください...」
デスクトップ画面が表示された。

完了。

【結論】
Windows インストール時は BIOSの設定で Display=virtual 800 x 600 だけをチェックON [X] にする事。場合によっては640 x 480 だけ ONもありうる。それでもダメならそのモニタは高解像度過ぎるので、インストール時だけは低解像度のモニタに接続する事。

後はどんなSDカードだろうが、熱処理やACアダプタが劣悪だろうが、MAXだろうがなんとかなる(実際成功した)。

これから使っていく際にも、高い解像度にすればするほど、重くなり、クラッシュやリセットの憂き目にあう可能性が高いだろう。

高い解像度のモニタほど低いvitualにすべき。OSインストール時にそれは顕著で、運用時は少し高めでも可能かと。なぜより低いvirtualかの理由は、今までさんざん1280x1024 nativeで成功してるので今回の失敗したFHD native(なぜnativeかというとOSインストーラや通常運用時、全部ONならより高い解像度を使おうとするためnativeを使っていると思われる)とは、それほど転送すべき総ピクセル数(ズームされたあとのHDMIデータ転送量)は変わらないのに、失敗した。そして今回800x600で成功した。つまり解像度が上がったら成功する解像度(virtualもしくはnative)は下がったことになる。

例)
2Kモニタ : virtual 640 x 480 でOSインストール。運用時800x600か(自環境では検証不可)。
FHDモニタ : virtual 800 x 600 でOSインストール。運用時1024x768(検証中)。
1280x1024モニタ(DVI接続) : native でOSインストール。運用時 native(実績あり)。

解像度をvirtualで無理やり下げても、描画データの総ピクセル数(これがプログラムで領域確保する描画メモリ容量になる)は減るが、解像度高いとそれを本来の解像度にズームする処理が入って実描画データ(HDMIデータ転送量)は増える。
なので高い解像度モニタほど同じvirtualにしても転送データが重くなる、はず(ズームがモニタ側の機能ならそうはならないが。でも実際1280native-native/FHD-800の上記実例があるし)。
で、例のように逆転現象が起きる。

Windows ARMがデフォルトでGPUを使うなら、Raspi用描画ドライバがまだGPU対応していないということかな。
解像度を切り替える機能がOS側にあるのはデスクトップになってから。しかしWinラズパイでは変えられないんだなー。描画バッファを解像度に合わせて拡縮するには最大の解像度で持ってないとダメだからな。

by k1segawa | 2019-03-06 12:31 | Raspberry Pi | Comments(0)