P7K500問題検証 2

本スレで報告していた者ですが話が混乱しているようなので過去の情報等をちょっと纏めてみました。

1.原因(ICHのみで発生するかは情報不足)
28bitアクセスモードでセクタアドレス0xFFFFFFF(268435456番)が指定された時に
実際には0x0(1番)または(不明な位置)を指してしまう。
この場所は28bitで表現可能ですがLBA28実機では別項目(総セクタ数)の上限を1超える為に
存在できない場所になっています。このためLBA48規格の位置になっています。
(しかしながら同社含む他機種では同じ方法で該当位置を指せます)

2｡影響を受けないシステム
Windows標準ドライバ(LBA48対応品)やUSB変換チップ等のドライバは固定切替え式(可能なら
常に48bitアクセス)らしいので問題ないようです。

3｡影響を受けるシステム
28/48bitを動的に切替えるHDDドライバを使用するFreeBSD(?)/Linux(libata)/Windows(intel
AHCI RAIDドライバ)
問題のセクタはクラスタサイズと位置/偶然のファイル配置/ディスクキャッシュ/先読み/遅延
書き込み等の影響で他のセクタと纏めて48bitアクセスが使われる場合があり判別を難しくしています。

4｡簡易判別方法(安全)非RAID
WindowsNT系ではサポートツール"Disk Probe"、Unix系では"dd"コマンドで
セクタ0x0と0xFFFFFFFの内容を比較して一致したらNG確定です。
0xFFFFFFF読み込み時にエラー発生ならNG確定です。
(OKの確定はできません)

5.対処
intel RAIDはHGSTかintelにしか対処できません。該当品を持っている人はメーカーに
リクエストしてみてください。それ以外は、問題のセクタを含むシリンダ16710番を区画領域に
割り当てないのが簡単確実です。1シリンダ約7.5MB程度です。シリンダ単位の区画設定は、
"MBM(DOS/自己起動FD)"や"fdisk(Linux等)"で行いフォーマットをOS標準のもので行えば良いです。
その他ちょっと手間ですが、
FreeBSDには対応パッチがあり、Linuxではata.hのLBA28判定マクロの終端判定位置をセクタ1個前に
進めカーネルをリビルドします。