備忘録。Memtest86+ をHDDに入れてGrubから実行すると、

Error 28: Selected item cannot fit into memory

というエラーが出て、メニューに戻されてしまう場合の対処。

1. 開発環境のインストールされたLinuxを用意
2. Memtest86+ のソースコードを入手、任意のディレクトリに展開
3. ソースコードディレクトリ内memtest.ldsファイルをエディタで開き、.=の左辺を0x100000に変更

OUTPUT_FORMAT("elf32-i386");
OUTPUT_ARCH(i386);

ENTRY(_start); 
SECTIONS {
        . = 0x100000;  // Change to 0x100000
        _start = . ;
        .data : {
                *(.data)
        }
}

4. make (configure不要)
5. 出来上がったmemtest (拡張子無し)を目的のPCの/bootにコピー
6. /boot/grub/menu.lst (もしくは/boot/grub/grub.conf)に以下のエントリを追加もしくは変更。rootの行は自分の環境に合わせて変更。要点はkernel行に--type=netbsdオプションをつけること。

title Memtest86+
       root (hd0,0)
       kernel --type=netbsd /boot/memtest

自分用に作ったMemtest86+ 4.10のファイルを添付しておきます(ファイル名をmemtestに変更してください)。

[ エラーの原因 ]

1. Memtest86は古いタイプの起動方法を採っており、通常BIOSが使わない090000-09A000hの領域は空いているものとし、そこに実行プログラムを読み込む。
2. しかし比較的新しい(今回Pentium 4のPCサーバでエラーとなったので、今のマシンは全部新しい)BIOSはこの領域を予約域として確保している。
3. Grubはこの領域が予約されているのが分かるので、そこにMemtest86を読み込むことはエラーとして実行しない。

[ エラーの回避方法 ]

• ELF形式のバイナリファイルを使う(拡張子無しのmemtestを使う)
• GrubにELFファイルでブートする設定をする (--type=netbsdの指定)
• GrubはELFファイルを1MB以下のアドレスにはロードしないので、1MB以上の場所を開始アドレスとする(memtest.ldsの編集)

この問題をバグだという人もいる(多い)しバグではないという人もいるみたいで判断が難しいですが、私的にはバグと言い切るのは安直かなぁと。

[参考(というかそのまんま)]

• grub - Error 28: Selected item cannot fit into memory (A simple matter of…)
• Debian Bug report logs - #319837

---

Windows7 x64上でVisual C# 2010 Expressを使ってとあるプログラムを開発。開発マシン上では何の問題もなかったのに、実行ファイルをXP x86に持って行くと、ウィンドウを表示することもなくエラーで落ちる。理由は不正なアドレス(0x4)へのアクセス。また対象フレームワークの問題 かと思ったのですが、今回はフレームワークを変更しても解決しない。

こまめにログを出力させて突き止めたエラー発生箇所はForm1.InitializeComponent…Visual C#が自動コード生成した場所じゃないか。さらにInitializeComponentの内部を探ると、落ちた箇所は最後の方にあるthis.panel1.ResumeLayout(false);という行。デバッガで追ってもResumeLayoutを記述しているコードはなく、.NET Frameworkの中っぽい。

何がおかしいのか見当もつかないので、以下の手順で変更、その都度XP上で落ちるかどうかを確認。

• Form1.panel1上に配置していたコントロールを別の場所に退避、panel1を削除 → 落ちない
• panel1をつくり直すが、元にあったコントロールはpanel1上に配置しない → 落ちない
• 新panel1上に退避していたコントロールを配置 → 落ちない
• pane1のプロパティでSizeChangedイベントに自前のハンドラを設定 → 落ちた
• 自前のイベントハンドラを何もしない関数に変更 → 落ちない

この自前ハンドラはpanel1のサイズに合わせて中のコントロールサイズを複雑に変えるものでして、panel1とpanel1上のコントロールのサイズを参照するため、コントロールの初期化が終わる前(=InitializeComponentが完了する前)に呼び出されたなら確かにまずい。しかしWindows7 x64のデバッガ上ではハンドラは呼び出されないんだけどなぁ。

解決策としては、

• panel1のプロパティでのSizeChangedイベントハンドラの指定をしない
• Form1_Loadでイベントハンドラを指定する

という方法で、XPでも落ちなくなりました。

[2010/11/6 追記] どうもWindows7とXPでコントロールの表示サイズが異なることが原因みたいです。今回のプログラムはWindows7で開発していたので、

• XPで実行: panel1にアンカー(メインウィンドウのサイズに合わせて自身のサイズを変更する)が設定されており、panel1.ResumeLayoutでリサイズが発生、ハンドラが呼び出され落ちる
• 7で実行: 開発時のサイズで表示できるのでリサイズが発生しない

ということは、XPで開発するとVista/7では落ちることになるのかな…

---

TGS の反省もなく、また行ってまいりました幕張。3Dテレビでお腹いっぱい。東芝、シャープ、パナソニックを視聴してきましたが、

• 板が奥行き方向に並んでいる感じで、立体絵本 のように見えてしょうがない。
• 鮮やかさに欠ける
• 原理上高速で左右交互に片目を目隠ししているようなものなので、眼に入る光量が半減。
• 液晶の場合、左右の画像を高速に切り替えるため残像が入りボケる。
• 個人的経験上、どうしても3D IMAXで感じた迫力と比較してしまい見劣りする(ただし私にとって3D IMAXの迫力は画面の大きさによるものが大きい)。

とういう感じで、どうも今ひとつのめり込めませんでした。

写真は3Dカメラのデモ。左端にあるカメラで撮影された女性がその上の画面で3D画像として表示されるもの。しかしそんな技術に感心するよりも、閉鎖された部屋の中でひたすら単調な動きを繰り返すしかない女性の仕事が大変だなと思ってしまうあたりは、我ながら友達に「夢のないやつ(*1)」と言われただけある。

(*1) 東京ディズニーランドのエレクトリックパレードで、ブランコに乗っている着ぐるみの豹に対して「しっぽが命綱になってる(ブランコと金具で接続されている)」と指摘した時にに言われた

シャープの4色液晶テレビクアトロン は従来の3色と並べられると確かに鮮やか。だけど普段3色でも不足は感じないだろうなぁ、と思いつつBlu-rayを見慣れるとDVD画質が荒っぽく見えるように、4色に慣れると3色がひどく色あせて見えるのかもしれない。

そんな最新技術よりも何気に気に入ってしまったのは、三菱の倍速クリアピクチャー技術 。私はパソコンで地デジやDVD/Blu-rayを見ているのですが、横や縦に流れる文字がブレて見えることが気になっていました。クリアピクチャーだと文字が綺麗に流れますです、ハイ。テレビでは既に高級機種で搭載されていたそうですが、それがパソコン用ディスプレイとして登場。ちょっと値段高めですけどね。

ああ、あとシャープで裸眼(メガネなし)3D 液晶を見ましたが、全然3Dに見えませんでした orz ワタシノ メガ ワルイノカ

こちらの写真は先日 も触れた地球シミュレータの後継機「京」を構成する1モジュール(富士通製)。「京」はこれの1万倍の計算能力だそうです(といって、これを1万台並べるわけではないはず)。

前回 以降、依頼主に回路を引渡して使ってもらい何度か(主に使い勝手の)修正、試験使用を待つ状態になったようです。

一段落ついたということで記録に残すという意味も兼ね、AVR側のプログラムと使い方を公開 することにしました。現時点PC側のプログラムを提供してませんので、お手軽には使えないと思いますが…使う目的によってプログラムは千差万別と思ってまして、簡単かつ汎用的な目的が思い浮かばない状態です。

---

Visual Studio 2010 Expressで

• メニュー→プロジェクト→hogeのプロパティ→設定ページ
• プロジェクトに設定ファイル(Settings1.settingsなど)を追加してsettingsファイルを開く

などをした後、設定に項目を追加、実行ファイルを走らせると即刻例外で終了してしまいました。デバッガから起動するとSystem.BadImageFormatException が発生しているらしい。

この例外を検索すると多くはx64のコードからx86のDLLなどをロードしようとした(または逆)時に発生するようですが、今回そんなDLLを使った覚えはなく。

問題なく動いていたコードに書き戻してどのファイルが問題を発生させるのか調べたところ、原因はどうやらcsprojファイルに

<None Include="app.config" />

という行が追加されるかららしい。試しにこの行をテキストエディタで削除してプロジェクトを再読み込みすると、問題なく起動します。

しかしこれはapp.configをプロジェクトから外すという事。設定項目はsettingsとapp.configファイル両方に記録されるのですが、ビルド後の設定変更で使われるのは後者であり外すのはまずい。また設定項目を編集すると問題の行が復活するのでいちいち消さないといけないので、面倒。

Visual Studioのどこかに設定するところがあるのだろうか、それともバグ？

環境は以下のとおり

• Visual Studio 2010 Express Edition Version 10.0.30319.1 RTMRel
• .NET Framework Version 4.0.30319 RTMRel
• Windows7 Home Premium x64 Version 6.1.7600
• Intel Core i7 920 6GB RAM

[2010/8/29 追記] 32bit OSだと問題なし。ということはやっぱり64bitと32bit混在が原因なのか、むむむ…

[2010/8/29 追記] Visual Studioの設定をいじっているうちに発生しなくなってしまいました。やったことは以下の内容。

• ツール|設定|上級者設定を選択
• ツール|オプション→プロジェクトおよびソリューション|全般を開き、ビルド構成の詳細を表示にチェック
• ビルド|構成マネージャを開き、x64とAny CPUプラットフォームを追加(後でソリューションファイルを元に戻してなかったことに)
• プロジェクト|hogeのプロパティ→アプリケーションを開き、対象フレームワークを.NET Framework 4 Client Profileから.NET Framework 4に変更

エラーが出なくなったのは最後の項目をやった後。それまではエラーが出続けたので、対象フレームワークを変更するだけで良いかもしれません。以後、対象フレームワークを元に戻してもファイルをバックアップに書き戻してもエラーが出なくなってしまったので、追検証不可能となってしまいました。