BSD小僧の日記

ZBOX nano VD01の起動しない問題、続々編です。

さて、panicした部分はどこかを見てみると、pci_make_tag関数の413行目もしくは420行目ということになります。

398 pci_make_tag(pci_chipset_tag_t pc, int bus, int device, int function)
399 {
中略
410 	switch (pci_mode) {
411 	case 1:
412 		if (bus >= 256 || device >= 32 || function >= 8)
413 			panic("%s: bad request", __func__);
414 
415 		tag.mode1 = PCI_MODE1_ENABLE |
416 			    (bus << 16) | (device << 11) | (function << 8);
417 		return tag;
418 	case 2:
419 		if (bus >= 256 || device >= 16 || function >= 8)
420 			panic("%s: bad request", __func__);
421 
中略
429 }

どちらの文か区別できればよいので、何も考えずにpanicに与えるメッセージをかえてみたところ、420行目のpanicが呼ばれていることがわかりました。つまり419行目のチェックに引っかかっており、変数bus, device, functionのいずれかが異常な値だということになります。

じゃぁ、その異常値をよこしたのは誰だということになります。

前回のデバッガのtraceの結果から、このpci_make_tagを呼んでいるのはAcpiOsReadPciConfigurationですから、そちらを参照してみます。すると、pci_make_tagを呼ぶ前に210行目でpci_make_tagと同様のチェックをしていることがわかります。

202 AcpiOsReadPciConfiguration(ACPI_PCI_ID *PciId, UINT32 Register, UINT64 *Value,
203     UINT32 Width)
204 {
中略
210 	if (PciId->Bus >= 256 || PciId->Device >= 32 || PciId->Function >= 8)
211 		return AE_BAD_PARAMETER;
212 
213 	tag = pci_make_tag(acpi_softc->sc_pc, PciId->Bus, PciId->Device,
214 	    PciId->Function);
中略
235 }

このチェック内容を比較すると、bus, device, functionのうちdeviceだけがチェック項目に違いがあることがわかります。

親であるAcpiOsReadPciConfigurationでは32未満であることをチェックしていますが、pci_make_tagでは16未満であることをチェックしています。したがって、何らかの理由でdeviceが16から31の状態となり、AcpiOsReadPciConfigurationのチェックは通過するものの、pci_make_tagのチェックで引っかかり、panic処理へ進んでいると想定されます。

それでは、なぜdeviceがおかしな値になっているのか、という所を追求しなければなりません。

ということで、より上位の関数を追っかけてみたものの、私の実力では、その原因を見つけることはできませんでした。

さて、ZBOX nano VD01の起動しない問題、続きです。



によると、pci_make_tagでbad requestだから /src/sys/arch/x86/pci/pci_machdep.cあたりでpanicしているということまではわかります。

では、どういうルートで呼び出されているのか、といえば、デバッガのプロンプトにtraceと打ち込めばよいのですが、USBだからなのかキーボードが使えません。

そんなときには、kernelのconfigファイルに次のような設定をすることで、デバッガに落ちたときに自動的に指定したコマンドを実行することができます。

options DDB_COMMANDONENTER="trace"

で、設定してみました。が、関数呼び出しのネストが深すぎて、一番読みたいpanicする直前の呼び出し関係が流れていってしまいます。

そういうときには、デバッガのコマンドとして trace ,8 と与えると直前の８回分の呼び出しが表示されます。

よーし、というわけで、options DDB_COMMANDONENTER="trace ,8" と設定してkernelをコンパイルしたところ、sys/ddb/db_command.cのdb_cmd_on_enterの___STRING(x)マクロで引数が二つでダメですよ、っていうエラーで進めません。

セミコロンで区切った二つのコマンドは対応しているようなのですが、どうもカンマが入るとダメなようです。

では、”trace \,8"とか"trace \\,8" とかエスケープしたらいいのかと思ったのですが、いずれもうまくコンパイルが通りません。

しかたがないので、先の部分に直接書き込むことにしました。

char db_cmd_on_enter[DB_LINE_MAXLEN + 1] = "trace ,8";

あたりまえですがコンパイルが通り、さて実行です。



src/sys/dev/acpi/acpica/OsdHardware.cのAcpiOsReadPciConfigurationから呼び出しているpci_make_tagで起こっているみたいですね。

あれ？　おかしいな。traceはAcpiOsReadPciConfigurationからpci_decompose_tagを呼び出しているように見えます。うーん、pci_decompose_tagにはpanic時に出力しているようなメッセージを出す処理がありません。

デバッガのtraceを表示させてみて、わかったこともありましたが謎も深まりました。

ここまでで２日目。

VIAのデュアルコアでしかも小型のべアボーン、ということで出たときから気になっていたZBOX nano VD01を購入して、満足していたのですが、やっぱり動かしたいなと思い、一緒に買ったメモリと余っていたSATA HDDを装着しました。

さて、接続するかとよく見たら、こいつはDisplay PortとHDMIは持っているものの、DVIやVGAのインタフェースを持っていません。



さて困りました。そういうモダンなインタフェースを接続できるディスプレイを持っていません。ディスプレイの購入に走ろうかと思ったのですが、HDMIならばリビングの液晶テレビが使えるんじゃないか、と気づいたのです。

思い立ったが吉日、早速リビングへ移動。ところがHDMIケーブルが手元にありません。泣く泣く翌日以降となったのです。

翌日は、職場の近くのノジマ電気で一番安いHDMIケーブルを買い、深夜まで潜伏、潜伏しないとリビングは人がいますから。いよいよ、接続です。



2011-12-24のcurrentも5.1-Releaseも起動できません。USBキーボードしかないためデバッガへの入力もできません。シリアルも出せないので画面を撮影しました。よく見るとcurrentだとCPUをちゃんと認識していますね。

さすがVIAです。一筋縄ではいきません。

面白くなってまいりました、ってところで一日目は終了。

昨年の年末にアキバでRstream A1というSIMフリーのAndroid端末を7,980円で購入しました。スペックはそれほど高くない、一昔まえの端末なのですが、新品でSIMフリーで面倒な手続きなく入手できるよいオモチャかなと思っています。

購入時点だとAndroid2.1なのですが、OSAKANA TAROさんのWebを参考にCyanogenMod7.1に入れ替えて使っています。Android2.3ですね。



当初はボタンの動きがへんという話もあったのですが、徐々に解析が進み、実用上は大きな不満のない端末になったかなと思います。

端末はいい感じになりましたが、Wifiだけだと使える場所も限定されるということで、3G回線が欲しくなります。E-mobile回線のSIMは使えないので、コストを抑えてつかえるイオンSIMの980円コースを契約してみることにしました。

職場の近くのイオンに昼休みテクテクあるいて出かけて、ものの15分でSIMを入手。APNを設定して使えるようになりました。APN設定後、再起動しないと通信できなかったので、すこし焦りましたが。

イオンSIMは100kベストエフォートいうふれ込みどおり、決して速くはないのですが、なにしろ端末だけで一本立ちできるというのはかなり大きいかなと思います。

また、昨年末の新幹線で感じたE-mobileエリア外での活躍にも期待ができます。まぁ、N700系なら公衆無線LANを使えという話がありますけど。

あとは外国に行ったときの活躍ですかねー。これは少し先になると思うけど楽しみです。