KVM / QEMU 等で、ちょっと古めの OS を入れて遊んでいたら、次のようなメッセージが出るが、 何事もなく動く場合がある。
kernel: hda: C/H/S=780/0/63 from BIOS ignored
多分、CHS変換が上手くいっていないがLBAモードでアクセスするので問題が起きていないんだろうが、 正直言うと気持ちが悪い。
Googleの検索だと6件くらい引っかかる
くよくよ調べてみた。
- 起動時にホスト側のエミュレータでディスクのCHS値から変換方法は自動的に最適な変換アルゴリズムが選択される。(「bochs: The Open Source IA-32 Emulation Project (New Bochs Documentation)」にあるnone, large, rechs, lbaの4種類)
- 仮想マシン上で実行されるBIOSの初期化処理で、論理CHSの最大値が計算される。
- エミュレータで指定された変換アルゴリズムで計算した値が EBDA(Extended BIOS Data Area)に保存されている。
- 上とは無関係な方法で計算した値がFDPT (Fixed Disk Parameter Table)に保存される。
(「Enhanced Disk Drive Specification Ver 1.1」に基づいた方法。。。1995年に作成って) - EBDAとFDPT上の論理CHSの最大値が一致しない場合がある。
- FDPTの計算に使われる方法は、Head値が256の可能性があり、古いシステムでは誤認識する場合もある。(おおよそディスクサイズが 4Gの以上の時かなぁ?)
変なメッセージが出るのが嫌なのでパッチを作ってみた。ただし、FDPTはどう扱うべきかイマイチ分からないので、正しい対処法かどうかは分からない。
--- kvm-62+dfsg/bios/rombios.c 2008-02-25 18:30:14.000000000 +0900 +++ ../rombios.c 2008-07-23 15:39:17.000000000 +0900 @@ -2450,6 +2450,15 @@ write_word(ebda_seg,&EbdaData->ata.devices[device].lchs.cylinders, cylinders); write_word(ebda_seg,&EbdaData->ata.devices[device].lchs.spt, spt); + if (device == 0 || device == 1) { + Bit8u *fdpt = (device==0) ? EbdaData->fdpt0 : EbdaData->fdpt1; + + write_word(ebda_seg, fdpt, cylinders); + write_byte(ebda_seg, fdpt+0x02, heads); + } + // fill hdidmap write_byte(ebda_seg,&EbdaData->ata.hdidmap[hdcount], device); hdcount++;
パッチ書いた後、Googleって見たら、Virtual Box では同様のパッチ Changeset 6294 - VirtualBox が当たってるようである。(Sunの古いシステムで不具合とかあったのかなぁ。。。)
まとめ
FDPTの値に不整合があるが、相当古いシステムしか影響を受けないので、気にする必要は無いらしい。 そのうちKVM/QEMU等のrombios.cにも変更が下りて来るのかもしれない。。。
0 件のコメント:
コメントを投稿