mieki256's diary

Ubuntu Linux 20.04 LTS と一緒にインストールされる memtest86+ 5.01 を動かすと、最初のテストの62%のあたりで動作が止まってしまう…。

UBCD に入ってる memtest86 v4.3.7 なら、処理が続いてくれたし、1パスは通った。

おかしいな…。AMD A8-3850 は Llano世代で、AMD Fusion と呼ばれてたAPU。memtest86+ は v4.20 の時点で AMD Fusion に対応という話があるわけで…。なのに、どうして止まるのか…。

_メモリ診断 Memtest86+の使い方 【桜PC情報】

日記を検索してみて気が付いた。このCPUとM/Bは、以前、親父さん用PCとして使ってた時期に動作が安定しなくて、各種クロックを落として様子見しつつ使っていたらしい。

_mieki256's diary - 親父さん用PCの調子がまだおかしい

• CPU AMD A8-3850 : 2.9GHz → 2.5GHz (ベースクロックは 100MHz、CPUクロックは x25。)
• メモリクロック : 1600 → 1333 (666MHz, CAS 9-9-9-24)
• 内蔵GPUクロック : 600MHz → 500MHz

もしかして、BIOS設定で Load Optimized Defaults を読み込んでしまったことで、また不安定な動作状態に戻してしまった、ということだろうか…。

試しに、各クロックを前回と同様に落としてみた。UBCD版 memtest86+ 5.01 の処理が続くようになった。そういうオチか…。

しかし、本来のスペックで動作しないのは、なんとも残念。弟が持ってきてくれた直後は、どうやら本来の速度で動いてたっぽいのだけどな…。

_mieki256's diary - A8-3850機の動作確認を開始

さておき。クロックを落としてみても、ACPIエラーは改善しなかった…。

Ubuntu 20.04 と一緒にインストールされる memtest86+ 5.01 で動作確認すると、最初のテストで必ず止まってしまって…。数時間ほど、BIOS設定を弄って試したものの、状況が改善しなくて悩んでしまった。

そこでふと、なんとなく、UBCD同梱の memtest86+ 5.01 で動作確認してみたら、するすると先に処理が進んでしまって…。コレってどういうことなの…。

memtest86+ は、表示されてるバージョンは同じでも、中身が違うということだろうか。それとも、DOS系から起動するのか、*NIX系から起動するのかで、動作に違いが出てくるということなのだろうか。

何にせよ、memtest86+ が止まる時は、別の memtest86+ を動かして確認してみたほうが良い、ということなのかな…。

ちなみに、内蔵GPUが使うメモリの量変更しながら試したら、Ubuntu版 memtest86+ の止まる位置がそれぞれ変わった。ということは、memtest86+ がチェックしてる位置が、表示用に使うメモリ領域に切り替わるタイミングで、動作が止まってしまうということだろうか…。

更に、UBCD版 memtest86+ 5.01 なら、クロックを本来の値に戻しても、1パスしてしまった。まあ、memtest86+ が通るからと言って、各OSが安定動作するとは限らないのだけど。最低限のチェックを ―― CPUとメモリの動作確認しかしてないので、他の部分が不安定な可能性は残ってしまうわけで。

ACPIエラーについてググってたら、気になる話が。

_198167 - ACPI Exception: Could not find/resolve named package element - Gigabyte GA-890GPA-UD3H, AMD Phenom II X6 1055T
_ACPI Exception Issue - Linux Mint Forums
_Bug #1876593 “Ethernet not working/Realtek RTL8169 fails to load...” : Bugs : linux-signed package : Ubuntu
_Re: Buster: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20180313/dspkginit-414)
_ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20180531/dspkginit-414) - Technical Issues and Assistance / Kernel - Manjaro Linux Forum

英語はよく分からんのだけど、どうやら、「GIGABYTE製のM/Bは必ずと言っていいほどこの手のエラーを出しやがるので、エラーが出ても無視してしまえ」みたいな話が出ているような…？ 違うのかな？ 一応そう読めるけど。

M/BのBIOSには、ACPI関係の情報が入っているテーブルがあるらしいのだけど、GIGABYTE製M/Bは、何故かそのテーブルをちゃんと入れてくれてない(場合が多い)そうで…。Linux側は、律儀に、「このテーブルの値、おかしいよ」とエラーを出してしまうのだとか。

GIGABYTEに連絡しても、「Windowsはコレで動いてるんだからいいだろ。Linux？ そんなの知るかボケ」てな反応しか返ってこない、てな話も…出ているように見える…ような…。英語はよく分からんから自信無いけど。

となると、自分が今回対峙している、このACPIエラーも、そのへんが原因だろうか…。

つまり、将来的に Windows以外のOSを ―― 例えば Linux 等を入れて遊ぶ予定がぼんやりとあるなら、GIGABYTE製M/B は避けるべし、ということかもしれんなと…。

ちなみに、GIGABYTE製M/B はリビジョン商法が ―― 型番は同じでもリビジョンが違ったら搭載チップまで変えてくるあたりが嫌われていて、日本の自作PCユーザの間では、特別な理由でもない限り基本的には避けるべきM/Bメーカ、として扱われてたりもして…。でもまあ、値段が安かったり、欲しいスペックを満たしてるのがその製品しかない、等々の理由で、やっぱりココは GIGABYTEを選ぶしか、てな場面も結構あるのでアレなのですが。

それはさておき、どうしたものか。特定のエラー種類だけ無視するオプションとか無いのかな。特定のディストリなどは、この手のエラーへの対処を諦めちゃって、エラーを表示しない設定にしちゃってる、てな話も出てるようだけど…。Debian や Ubuntu はそうではない、ということだよな…。