技術的考察・追記 – ひねもす庵

　技術的考察を一度終了した後、突如出てきた記事。
　ドライブロックが起こる原因を少し解釈してみる。

今回、品質検査完了後に管理予約領域の初期化をするのを忘れたロットが発生した。
管理予約領域の次の領域には、内部動作状況を記録する数字が書き込まれることになっている。
そのため、内部動作状況の数字がある組み合わせになった時、管理予約領域＋それに続く数字の一連のデータパターンが、製造工程の品質管理用に使用される特定のパラメータのパターンと合致してしまった。
ファームはこのパターンを読み込み、品質管理に使用されるオペレーションを発動。
今回はそれがドライブロックダウンだった。

　個人的には、この記事もそれなりに信憑性があると判断している。
　その理由は、既出の「ドライブロックの解除方法」の作業内容と、この記事の内容が論理的に合致することである。

　更に、この話は既出のmaxtormanの投稿内容とも矛盾しない。
　maxtormanの指摘する「1/320のロシアンルーレット」とは、エラーログ領域セクタの320番目というカウンタの数字という意味である。

　この場合、320という数字が不幸にも「特定のパラメータのパターン」の構成要素となってしまっており、それがドライブロックが発動する理由になる、と解釈することが出来るのである。

　やはり、ドライブロックの原因はファームのバグ、ということで。
　逆に言うと、ファームが直ればこの問題だけは解消するということですな。

　・・・エラー多発の品質問題はまた別に存在し続けるのだけど。