☰

64ビットMemtest86 + BadRAMモードでGRUBがハングしますか？

tag-icon • tag-icon linux-kernel grub2 uefi kernel-parameters badram
64ビットMemtest86 + BadRAMモードでGRUBがハングしますか？

「追加するとバードラムモデル64ビットメモリテスト86+v6.10/v6.20が私に与えた、グラップ2起動時に完全に停止します。

尋ねる：

  • Badramモードアドレスが表示された「無効なアドレス」（0x0ac...vs 0x62c...）と異なるのはなぜですか？これらの明らかな変化の理由は何ですか？
  • badram64ビットモードを通過するとGRUBがクラッシュするのはなぜですか？

これは私のGRUBです...

# grub-mkimage --version
grub-mkimage (GRUB) 2.06-3~deb11u5

会社で寝ています...

超過する」GRUBへようこそ！「メッセージ、なし。再起動もなく、キーストロークへの応答もなく、回復シェルもありません。システムが
完了しました。」レンガ- 回復するには、回復USB UEFIブートスティックを作成する必要がありました。

それでも。私はシステムメモリについてよく知らず、Memtestの16進数で多くを知りません。
しかし、前のゼロを切り取り、この32ビット数をGRUBに渡すことはできないようです。それともそうできますか？ ...レジットの誰かそれがそのようなことだと思います。しかし、私のように、この数が実際に期待どおりに機能し、正しいメモリ領域をマスクすることを確認する方法はありません。

GRUBがこの問題を台無しにした理由は何ですか？マスキングが容易ではないメモリ領域ですか？エリアが小さすぎますか？特定のサイズ（4Kページサイズなど）である必要がありますか、それとも整列する必要がありますか？

GRUBが故障したばかりですかbadram？それともハードウェアですか？ （そうではないようですが、これらのACPIテーブルについてはまったくわかりませんか？）

とにかく、私は他の人がGRUB + 64ビットアドレスで同じ問題を報告した多くのケースを見つけました（明らかに私のGRUBだけが怠惰な労働者ではありません）。

このコマンドを実行した後（grub.cfgを介してまたはコマンドラインから対話的に）、システムがハングして応答しなくなります。 badram 0x000000008c4e0800,0xffffffffffffcfe0

（GRUB開発者から何の応答も受け取れませんでした。)

GRUB_BADRAM="0x00000000b3a9feec,0xfffffffffffffffc"

上記のように変更した後は、Grubスプラッシュ画面も表示されません。表示する必要があると、コンピュータが停止し、黒い画面が表示されます。

（彼らも修正できませんでした。)

これらすべてを行いましたが、GRUB_BADRAM =行を追加した後、コンピュータは完全に正常であり、エラーなしで起動が拒否されました。開始されず、メニューもまったく提供されません。

（badram2つの異なるシステムでGRUBパラメータが失敗します。...)

...これらのモード間に問題を引き起こす関係があるのか​​、GRUBがbadram64ビットアドレスで機能していないのかはわかりません。なぜなら見つからないからです。ポジティブ「私に効果的」と報告します。 （これらはすべてLinux形式またはLinuxカーネルパラメータを
使用している人に当てはまります。）memmap=memtest=

ついに私はbadram成功しそうな別の男を見つけました...32ビットアドレス表現を使用する（64ビットシステムで）？

それで、次に一度試してみようと思います。

ベストアンサー1

特に答えが見つかりませんでしたが、なぜ、GRUBのソースコードを理解できなかったので、badramGRUB 2のコマンドは次のようになると確信しています。ただ壊れた64ビットアドレス空間の場合。

したがって、この情報は、このウサギの洞窟に陥った他の人のためのものです。
（tl;dr：badram使用できません！Linuxmemmap=カーネルモードを使用してください。）

grubコマンドラインを適用した後、badram 0xac4d96c0,0xfffffff8Linuxのe820メモリマップで見ることができるのは、次のような断片化です（申し訳ありませんが、SEには色差の強調表示はありません）。

--- a/e820
+++ b/e820
@@ -1,5 +1,7 @@
 [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000bd6f5fff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000ac4d8fff] usable
+[    0.000000] BIOS-e820: [mem 0x00000000ac4d9000-0x00000000ac4d9fff] unusable
+[    0.000000] BIOS-e820: [mem 0x00000000ac4da000-0x00000000bd6f5fff] usable
 [    0.000000] BIOS-e820: [mem 0x00000000bd6f6000-0x00000000bd749fff] ACPI NVS
 [    0.000000] BIOS-e820: [mem 0x00000000bd74a000-0x00000000bd751fff] ACPI data
 [    0.000000] BIOS-e820: [mem 0x00000000bd752000-0x00000000bd752fff] ACPI NVS
@@ -28,4 +30,18 @@
 [    0.000000] BIOS-e820: [mem 0x00000000fed61000-0x00000000fed70fff] reserved
 [    0.000000] BIOS-e820: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved
 [    0.000000] BIOS-e820: [mem 0x00000000fef00000-0x00000000ffffffff] reserved
-[    0.000000] BIOS-e820: [mem 0x0000000100001000-0x000000083effffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000100001000-0x00000001ac4d8fff] usable
+[    0.000000] BIOS-e820: [mem 0x00000001ac4d9000-0x00000001ac4d9fff] unusable
+[    0.000000] BIOS-e820: [mem 0x00000001ac4da000-0x00000002ac4d8fff] usable
+[    0.000000] BIOS-e820: [mem 0x00000002ac4d9000-0x00000002ac4d9fff] unusable
+[    0.000000] BIOS-e820: [mem 0x00000002ac4da000-0x00000003ac4d8fff] usable
+[    0.000000] BIOS-e820: [mem 0x00000003ac4d9000-0x00000003ac4d9fff] unusable
+[    0.000000] BIOS-e820: [mem 0x00000003ac4da000-0x00000004ac4d8fff] usable
+[    0.000000] BIOS-e820: [mem 0x00000004ac4d9000-0x00000004ac4d9fff] unusable
+[    0.000000] BIOS-e820: [mem 0x00000004ac4da000-0x00000005ac4d8fff] usable
+[    0.000000] BIOS-e820: [mem 0x00000005ac4d9000-0x00000005ac4d9fff] unusable
+[    0.000000] BIOS-e820: [mem 0x00000005ac4da000-0x00000006ac4d8fff] usable
+[    0.000000] BIOS-e820: [mem 0x00000006ac4d9000-0x00000006ac4d9fff] unusable
+[    0.000000] BIOS-e820: [mem 0x00000006ac4da000-0x00000007ac4d8fff] usable
+[    0.000000] BIOS-e820: [mem 0x00000007ac4d9000-0x00000007ac4d9fff] unusable
+[    0.000000] BIOS-e820: [mem 0x00000007ac4da000-0x000000083effffff] usable

利用可能なメモリの大きな塊は、いくつかの小さな領域に分割されています。これは0xfffffff8、GRUBに渡すアドレスマスクが論理的に0x00000000fffffff864ビットスペースにあることを意味します。

その後、カーネルはこれらのすべての「使用できない」バグをシステムRAMからRAMバッファにマッピングして書き込むので、パターンがより明確になります。

[    0.615775] e820: reserve RAM buffer [mem 0xac4d9000-0xafffffff]
[    0.615779] e820: reserve RAM buffer [mem 0x1ac4d9000-0x1afffffff]
[    0.615780] e820: reserve RAM buffer [mem 0x2ac4d9000-0x2afffffff]
[    0.615781] e820: reserve RAM buffer [mem 0x3ac4d9000-0x3afffffff]
[    0.615782] e820: reserve RAM buffer [mem 0x4ac4d9000-0x4afffffff]
[    0.615783] e820: reserve RAM buffer [mem 0x5ac4d9000-0x5afffffff]
[    0.615784] e820: reserve RAM buffer [mem 0x6ac4d9000-0x6afffffff]
[    0.615785] e820: reserve RAM buffer [mem 0x7ac4d9000-0x7afffffff]

0xac4d9000 だから私たちは実際にbadramアドレスであるから0xac4d9fff...までスペースを予約し、それを下の境界に揃えてから、小さなビットエラーの周りにクールな4KBカーネルページサイズの穴を開けます。 （誰かが大砲の卵で穴を開けて壁のクモを取り除いたと想像してみてください。実際にその方法で問題が解決したようです。）
0xac4d96c0

...その後、システムメモリが不足するまで穴を開けて0x1ac4d9000、、...に0x2ac4d9000同じサイズのスペースを確保します。 （今0x3ac4d9000
それいくつかのスプレーが追加された大砲のランチャーのように見えます！ )

しかし、これらはすべて小さな穴であり、壁は大きいので、実際にはすべてが大丈夫でしょう。しかし、パターンが実際にこの例よりはるかに大きい場合はbadramどうなりますか？それとも、Memtesterは私たちに避けるべき多くの場所を提供しますか？もしそうなら、この問題は私たちのメモリマッピングをふるいに変えます！

したがって、badram実行している作業がわからない場合は、64ビットシステムでGRUBを使用しないでください。

代わりに、Linuxの完全な代替案は、memmap=コマンドライン引数を使用することです。これにより、GRUBで作成された4KBブロックよりも小さい穴を開けることができ、EFIStubなどの他のブートローダで使用することもできます。 （もう一つのオプションは何とか自分の修正されたカーネルを渡すことです。e820メモリマップ- しかし、方法を知っているなら、おそらくこの記事を読んでいないでしょう。 )

おすすめ記事