アカウント名:
パスワード:
ざっとコードを見ましたが、memtest86 は割と緩いテストなのでそれにも関わらず異常が検出されるならアウトでしょう。
仮想記憶をサポートする OS のユーザプロセスでは難しいかもしれませんが、本来なら目的のアドレス線が機能しているか／隣り合ったアドレス線に影響していないか位は見ないと駄目じゃないかな（0x0020xxxx に書いたときに、0x0000xxxx、0x0010xxxx、0x0030xxxx、0x0040xxxx、0x0060xxxx 辺りに影響出ていないことの確認とか）。
# 新しいハードウェアの開発とかやってるとママあるんだよね…
論理的に隣り合ったアドレスでも、回路的には隣ではない場合も多々あります。なのでビット干渉を調べるなら回路の物理的な配置を知らないと無意味です。
はい、なので隣り合ったアドレス線と書きました。インタリーブのことも考えて割と上位のアドレスを例として出したつもりです。
ビット線とワード線の故障を調べるなんてエンドユーザでは不可能ですね。
たとえば、ビット線の誤りは書いたデータと読み出したデータとの不整合で見つけられるのでは？（そして、memtest86 が主に実施しているのはこちらでは？）
# もちろんアドレス線が入れ替わっていたりすると見つけることは不可能ですが、これはこれで故障ではないとするスタンスもあるでしょう。
> もちろんアドレス線が入れ替わっていたりすると見つけることは不可能
仮に故障でアドレスが入れ替わっていたら最近の同期式ＤＲＡＭではモードレジスタの設定が正しくできないので、まともに動かない（memtestでは検査できないどころか立ち上がらない）と思いますよ。
仮に故障でアドレスが入れ替わっていたら最近の同期式ＤＲＡＭではモードレジスタの設定が正しくできない
メモリコントローラへの I/O とメモリそれ自体への I/O をごっちゃにしていませんか？（回路図見たことありますか？）
DRAMのアドレス線を使って指定するのはメモリのロウ・カラムだけでありません。DRAM内にあるモードレジスタを指定するのにも使います。メモリアクセスと区別するための信号線もあります。
で、それがまともに動作しない環境下でテストプログラムに何を求めるのですか?
スレッドのツリーを冷静に読み直して相手の意図を類推して理解する訓練つけてよ
*sigh*
割と緩い
Extended testでもそうなの？
ユーザプロセスでは難しいかもしれませんが、（CDなどから起動して行うテストなんだから）目的のアドレス線が機能しているか／隣り合ったアドレス線に影響していないか位は見ないと駄目じゃないかな
てことでは？
>ユーザプロセスでは難しいかもしれませんが
いやいや、ブートローダを自前でもった、独自アプリです。ページング処理も自前で行っています。
>一体何のコードを見たのですか?
ソースコードも配られていると思いますが．
まぁ、無知は罪ではありませんが、無知ゆえに無恥にも攻撃的なレス付けてるのは感心しませんねー。memtest86のソースなんてそこいらに転がっているので、あまり恥ずかしいことは言わない方がいいですよー。
# まぁ、無知な低級職業プログラマの私は、見ても何やってんだかさっぱり理解できないのですけど。# もう職歴書から「C言語」ってのは消した方がいいような気がしてきました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
メモリテストの難しさ (スコア:4, 興味深い)
ざっとコードを見ましたが、memtest86 は割と緩いテストなのでそれにも関わらず異常が検出されるならアウトでしょう。
仮想記憶をサポートする OS のユーザプロセスでは難しいかもしれませんが、本来なら目的のアドレス線が機能しているか／隣り合ったアドレス線に影響していないか位は見ないと駄目じゃないかな（0x0020xxxx に書いたときに、0x0000xxxx、0x0010xxxx、0x0030xxxx、0x0040xxxx、0x0060xxxx 辺りに影響出ていないことの確認とか）。
# 新しいハードウェアの開発とかやってるとママあるんだよね…
Re: (スコア:0)
なのでビット干渉を調べるなら回路の物理的な配置を知らないと無意味です。
ビット線とワード線の故障を調べるなんてエンドユーザでは不可能ですね。
Re:メモリテストの難しさ (スコア:3, 参考になる)
はい、なので隣り合ったアドレス線と書きました。インタリーブのことも考えて割と上位のアドレスを例として出したつもりです。
たとえば、ビット線の誤りは書いたデータと読み出したデータとの不整合で見つけられるのでは？（そして、memtest86 が主に実施しているのはこちらでは？）
# もちろんアドレス線が入れ替わっていたりすると見つけることは不可能ですが、これはこれで故障ではないとするスタンスもあるでしょう。
Re: (スコア:0)
> もちろんアドレス線が入れ替わっていたりすると見つけることは不可能
仮に故障でアドレスが入れ替わっていたら最近の同期式ＤＲＡＭではモードレジスタ
の設定が正しくできないので、まともに動かない（memtestでは検査できない
どころか立ち上がらない）と思いますよ。
Re:メモリテストの難しさ (スコア:2)
メモリコントローラへの I/O とメモリそれ自体への I/O をごっちゃにしていませんか？（回路図見たことありますか？）
Re: (スコア:0)
DRAMのアドレス線を使って指定するのはメモリのロウ・カラムだけでありません。
DRAM内にあるモードレジスタを指定するのにも使います。メモリアクセスと区別するための信号線もあります。
Re:メモリテストの難しさ (スコア:2)
で、それがまともに動作しない環境下でテストプログラムに何を求めるのですか?
Re: (スコア:0)
Re:メモリテストの難しさ (スコア:2)
*sigh*
Re: (スコア:0)
Extended testでもそうなの？
Re:メモリテストの難しさ (スコア:2)
ユーザプロセスでは難しいかもしれませんが、（CDなどから起動して行うテストなんだから）目的のアドレス線が機能しているか／隣り合ったアドレス線に影響していないか位は見ないと駄目じゃないかな
てことでは？
Re: (スコア:0)
>ユーザプロセスでは難しいかもしれませんが
いやいや、ブートローダを自前でもった、独自アプリです。
ページング処理も自前で行っています。
Re:メモリテストの難しさ (スコア:1)
>一体何のコードを見たのですか?
ソースコードも配られていると思いますが．
Re: (スコア:0)
まぁ、無知は罪ではありませんが、無知ゆえに無恥にも攻撃的なレス付けてるのは感心しませんねー。
memtest86のソースなんてそこいらに転がっているので、あまり恥ずかしいことは言わない方がいいですよー。
# まぁ、無知な低級職業プログラマの私は、見ても何やってんだかさっぱり理解できないのですけど。
# もう職歴書から「C言語」ってのは消した方がいいような気がしてきました。