バグ・制限事項情報
(このページの最終更新日: 2006-11-17)
(このページの最終更新日: 2006-11-17)
目次:
- § 未解決・制限項目
- 時計がずれる
- ルートデバイス指定時にreboot/haltすると時計が狂う
- AVRのタイマ機能が使えない
- シリアルの割り込みを取りこぼすことがある
- カーネルのDIAGNOSTICオプションをはずすとブートしない
- CPUの型名が8245になっている
- カーネルロードアドレスが0x90000になっている
- シリアルに『ブレークの送信』を行うとデバッガに落ちる
- 玄箱でFFSフォーマットしたディスクがNetBSD/i386で認識しない
- pkg_addをすると、"pkg_add: NetBSD/powerpc 2.0 (pkg) vs. NetBSD/powerpc 2.0_STABLE (this host)"と表示される。
- ext2fsのアクセス過多?でパニック
- ext2ファイルシステムをルートにすると不安定
- nbloaderが、"insmod: QM_MODULES: Function not implemented"と表示されてブートしない。
- ブート時にwd0aをext2fsフォーマットと誤認してパニックする
- § 再現性に難が有る項目
- § 解決済項目
- fdisk/disklabel
- fictitiousラベルの間違い
- Linuxのルートパーティションがマウント出来ないことがある
- NFSルート時に、起動途中で固まることがある
- USB Hubを認識しない。USB Hubがugenに割り当てられる。
- 電源スイッチで電源が切れない
- NetBSD上のコマンドからAVRの制御がうまくいかない
- nbloader.oのカーネル起動オプションが無視される
- Linuxバイナリ互換性(COMPAT_LINUX)が有効で無い
- "usbdevs -v"コマンドが"usbdevs: no USB controllers found"と言って正常に動かない
- 一般ユーザでpstat,vmstat等のコマンドが使えない
- I2Cドライバが未完成
- ギガビット接続の際、reドライバがデバイスを見失うことがある
- HDDの拡張領域上のNetBSDを認識しない
§ 未解決・制限項目
時計がずれる
玄箱の伝統(?)として時計がずれます。
カーネル内部の補正値は私の持っている玄箱/HGに合わせて書いていますので、他装置ではよりいっそうずれる可能性が有ります。
$ROOT/usr/src/sys/arch/sandpoint/sandpoint/machdep.c:initppc()中で、130041000としているのが補正した値です。
(初代の補正値(97553800)はtyamaさんからお借りした初代玄箱で測定した値です。)
カーネル内部の補正値は私の持っている玄箱/HGに合わせて書いていますので、他装置ではよりいっそうずれる可能性が有ります。
$ROOT/usr/src/sys/arch/sandpoint/sandpoint/machdep.c:initppc()中で、130041000としているのが補正した値です。
(初代の補正値(97553800)はtyamaさんからお借りした初代玄箱で測定した値です。)
(2005-09-26追記: VCXOをプルアップされた方は、131072000(HG)、または98304000(初代)とされると良いでしょう。(要は誤差が小さくなった、ということです))
(2005-12-06追記: 統合版カーネルパッチでは、sys/arch/sandpoint/sandpoint/machdep.cの"KUROBOX_BASE_CLOCK"の値を修正して下さい。)
(2006-05-13追記: HD-HGLANやHS-DGLの新型基板の場合もKUROBOX_BASE_CLOCK=32768000としてカーネルを作り直して下さい。)
ルートデバイス指定時にreboot/haltすると時計が狂う
root device:
のプロンプトで rebootやhaltが選べますが、これらを選ぶとRTCに不正な値が書き込まれ、次のブート時の日付時刻表示がおかしくなることがあります。
AVRのタイマ機能が使えない
これも外部プログラムが必要と思いますが、まだ何もしていません。
現状ではONしても単にLinuxが起動するだけです。この対策とあわせて行うことになると思います。
これは『なんちゃってブートセレクタ』で対応しました。
シリアルの割り込みを取りこぼすことがある
ネットワーク(NFS?)が忙しいとシリアルの割り込みが無視されます。何か無害なキー(コントロールQ等)をたたくと復活するようです。
(2005-12-11追記: PCIデバイス割り込み(主にハードディスクとネットワーク)と重複することでシリアル側を取りこぼすようです。
ネットワークやハードディスク、USBデバイスとコンソール表示に同時に負荷ががかかるような処理(tar cvf等)はシリアルで無くTelnet側から行うようにして下さい。
この件鋭意調査中です。 _o_ )
(2005-12-11追記: PCIデバイス割り込み(主にハードディスクとネットワーク)と重複することでシリアル側を取りこぼすようです。
ネットワークやハードディスク、USBデバイスとコンソール表示に同時に負荷ががかかるような処理(tar cvf等)はシリアルで無くTelnet側から行うようにして下さい。
この件鋭意調査中です。 _o_ )
カーネルのDIAGNOSTICオプションをはずすとブートしない
DIAGNOSTICオプションをはずしたカーネルを作成し、ブートさせるとpanicが発生し、ブートしません。
(3.0カーネルで発生;currentも同じ構造なので発生すると思われる)
eumbと呼んでいるバス(オンチップペリフェラル用;comやrtcなど)の認識がうまくいかなくなるようです。
CPUキャッシュとの関連も疑われます。
本件調査中ですが、原因究明までしばらくの間はDIAGNOSTICをはずさないようにお願いします。
(3.0カーネルで発生;currentも同じ構造なので発生すると思われる)
eumbと呼んでいるバス(オンチップペリフェラル用;comやrtcなど)の認識がうまくいかなくなるようです。
CPUキャッシュとの関連も疑われます。
本件調査中ですが、原因究明までしばらくの間はDIAGNOSTICをはずさないようにお願いします。
CPUの型名が8245になっている
玄箱のCPUはMPC8241ですが、8245と表示されてしまいます。
これは、MPC8241とMPC8245のCPU IDが同一なためです。
これは、MPC8241とMPC8245のCPU IDが同一なためです。
カーネルロードアドレスが0x90000になっている
オリジナルが0x90000になっているのでそのまま使用しています。
このアドレスの理由はオリジナルのsandpointのメモリホール(ISA互換のため?)が0x80000-0x8ffffにあるから、と聞きました。
玄箱にはISAは有りませんし、768KBもメモリを無駄にするのもなんなのですが、アドレスを変える実験はまだしていません。
実験する際には sys/arch/sandpoint/conf/std.kuroboxとnbloaderのMakefileを変える必要があります。
あまり下のほうでは割り込みトラップアドレスとぶつかると思うので、0x10000くらいが良いと思います。
(2005-10-25追記) 2005-10-24版のnbloader_v2.oでロードアドレスを可変にしましたが、まだ不安定です。しばらくは0x90000のままお使いください。
このアドレスの理由はオリジナルのsandpointのメモリホール(ISA互換のため?)が0x80000-0x8ffffにあるから、と聞きました。
玄箱にはISAは有りませんし、768KBもメモリを無駄にするのもなんなのですが、アドレスを変える実験はまだしていません。
実験する際には sys/arch/sandpoint/conf/std.kuroboxとnbloaderのMakefileを変える必要があります。
あまり下のほうでは割り込みトラップアドレスとぶつかると思うので、0x10000くらいが良いと思います。
(2005-10-25追記) 2005-10-24版のnbloader_v2.oでロードアドレスを可変にしましたが、まだ不安定です。しばらくは0x90000のままお使いください。
シリアルに『ブレークの送信』を行うとデバッガに落ちる
配布カーネルではデバッガオプション(DDB)が有効になっているため、ブレークの送信を行うとデバッガに落ちてしまいます。
contが効きますが、再開するまでの間時計が止まっていますので時刻がずれてしまいます。
ブレークの送信を行わなくとも、シリアルケーブルを接続した状態でPCの電源を落としたり、サスペンドしただけでもブレーク信号(相当)が送られてデバッガに落ちてしまうことがあります。
実運用に使われる予定の方は、カーネルオプションを見直したほうが良いでしょう。
contが効きますが、再開するまでの間時計が止まっていますので時刻がずれてしまいます。
ブレークの送信を行わなくとも、シリアルケーブルを接続した状態でPCの電源を落としたり、サスペンドしただけでもブレーク信号(相当)が送られてデバッガに落ちてしまうことがあります。
実運用に使われる予定の方は、カーネルオプションを見直したほうが良いでしょう。
玄箱でFFSフォーマットしたディスクがNetBSD/i386で認識しない
玄箱はPPCですのでデフォルトはEB(ビッグエンディアン)です。一方i386はEL(リトルエンディアン)です。このため玄箱でdisklabelやnewfs等を行ったディスクはNetBSD/i386で認識しません。
逆のパターンで、NetBSD/i386でdisklabel,newfsを行った場合は玄箱で認識するようにしていますので、USBメモリ等を両者で共用する場合にはNetBSD/i386側でdisklabelやnewfsを行ったものを使ってください。
これはMS-DOSファイルシステムには関係有りません。MS-DOSファイルシステムはどちらも正常に読み書き出来ます。
逆のパターンで、NetBSD/i386でdisklabel,newfsを行った場合は玄箱で認識するようにしていますので、USBメモリ等を両者で共用する場合にはNetBSD/i386側でdisklabelやnewfsを行ったものを使ってください。
これはMS-DOSファイルシステムには関係有りません。MS-DOSファイルシステムはどちらも正常に読み書き出来ます。
pkg_addをすると、"pkg_add: NetBSD/powerpc 2.0 (pkg) vs. NetBSD/powerpc 2.0_STABLE (this host)"と表示される。
パッケージのバージョンが厳密には合っていないため、warningとして上の文字列が表示されます。
他のエラーが表示されていなければpkg_add自体は行われていますので、そのまま使ってみて下さい。
気になる方は、pkgsrc.tgzを取ってきて、ご自分でビルドするのも良いでしょう。
他のエラーが表示されていなければpkg_add自体は行われていますので、そのまま使ってみて下さい。
気になる方は、pkgsrc.tgzを取ってきて、ご自分でビルドするのも良いでしょう。
ext2fsのアクセス過多?でパニック
ext2fsの書き込みが激しいとpanicを起こします(した)。
NetBSDのext2fsサポート自体の問題かもしれません。
NetBSDのext2fsサポート自体の問題かもしれません。
ext2ファイルシステムをルートにすると不安定
ルートファイルシステムとしてext2(たぶんext3も)を選択した環境で、ブート途中で固まるなど不安定な動作が報告されています。
(2005-09-07追記: 藤原さんのblogによると、ASSERT()によるパニックが発生しているようです... orz
ルートファイルシステムで無くとも、NetBSDのext2fsサポートは不完全なのかもしれません。(引き続き情報収集中))
(2005-09-07追記: 藤原さんのblogによると、ASSERT()によるパニックが発生しているようです... orz
ルートファイルシステムで無くとも、NetBSDのext2fsサポートは不完全なのかもしれません。(引き続き情報収集中))
nbloaderが、"insmod: QM_MODULES: Function not implemented"と表示されてブートしない。
HD-LAN(v1/v2)等ではLinuxのカーネルがモジュールの読み込みをサポートしていないようです。この場合はnbloaderは使用できません。
insmod出来るカーネルに入れ替えるか、別のローダーをお使いください。(この辺りは詳しくないです orz)
insmod出来るカーネルに入れ替えるか、別のローダーをお使いください。(この辺りは詳しくないです orz)
ブート時にwd0aをext2fsフォーマットと誤認してパニックする
ext2fs/ext3fsで使用していたパーティションの先頭と、新たにwd0aとして割り当てた場所が同じオフセットの場合、ブートシーケンスのパーティションフォーマット判別が失敗し、ffsでは無くext2fsとしてマウントしようとしてしまうことがあります。
この場合、/sbin/initのロードに失敗してパニックしてしまいます。
ext2fsの残骸がwd0aの場所に残っているのが原因と思われます。とりあえずはwd0aの場所をクリア(dd if=/dev/zero of=/dev/rwd0aなど)してからnewfsをして下さい。
この場合、/sbin/initのロードに失敗してパニックしてしまいます。
ext2fsの残骸がwd0aの場所に残っているのが原因と思われます。とりあえずはwd0aの場所をクリア(dd if=/dev/zero of=/dev/rwd0aなど)してからnewfsをして下さい。
§ 再現性に難が有る項目
NFS不安定(クライアント)
まだまだ不安定です。サーバとの時間誤差?でよくパニックしていました。
NTP等で同期をしているとおとなしくしてくれるようです。
# 最近は安定しているようです。
NTP等で同期をしているとおとなしくしてくれるようです。
# 最近は安定しているようです。
(起動時の)fsckでパニック
起動時、前回正常にアンマウントしなかったファイルシステムをfsckしようとしますが、この際パニックが発生することがあります。
ext2fsではfsck開始時に、ffsではfsck終了時にパニックします。
ffsではもう一回システムを起動すれば復旧するのですが、かなり不便です。
(最近は現象が再現しない、という話も有ります。)
ext2fsではfsck開始時に、ffsではfsck終了時にパニックします。
ffsではもう一回システムを起動すれば復旧するのですが、かなり不便です。
(最近は現象が再現しない、という話も有ります。)
nbloader.oで起動しようとしてハングアップする
オリジナル同様、まれにブートしないことがあります。この場合はもう一度やり直すとほとんどの場合うまくいっているようです。
(最近はほぼ100%ブートに成功しています。ブートしない原因はわかりません。)
(最近はほぼ100%ブートに成功しています。ブートしない原因はわかりません。)
§ 解決済項目
fdisk/disklabel
ダウンロードで対応しました(2005-08-27)
オリジナルのsandpointでは、fdiskがバイナリ配布物に入っていません。また、disklabelはDOS MBR非対応です。
この移植ではFFSのエンディアン非依存サポート、DOS MBRサポート、DOS MBRエンディアン非依存サポートを
おこなっていますので、新たにfdiskコマンドと、-DUSE_MBRでコンパイルし直したdisklabelが必要です。
$TOP/usr/src/sbin/fdisk/Makefile,$TOP/usr/src/sbin/disklabel/Makefileを修正し、
${MACHINE} == "sandpoint" || \
をそれなりの場所に追加してから各々コンパイル、インストールしてください。
(2005-08-27追記: ダウンロードからコンパイル済みバイナリと、Makefileに対するパッチをダウンロードできるようにしました。)
fictitiousラベルの間違い
直りました(2005-08-20)
disklabelの際のfictitiousとして生成されたラベルのうち、Cパーティション(NetBSDパーティション全体)が 間違っている場合があります。これはNetBSDパーティションは有るけれどもdisklabelが書かれていない場合に 発生するようです。 E~H辺り(切り方によります)にもNetBSDパーティション全体が登録されていて、こちらは正しい値となっている と思いますので、Cにはこの値をコピーして下さい。 # これはたぶんエンディアン非依存対応時のバグです _o_
ここ を参考にしてください。
(まだアーカイブには反映していません)
カーネル差分(2005-08-25版)に反映しました。
(2005-08-27追記: newfsがエラーになる、という情報があります。直後にfsckを行うと使用できるようになるとのことです。enbugしたかも知れません orz)
(2005-08-27追記: newfsがエラーになる、という情報があります。直後にfsckを行うと使用できるようになるとのことです。enbugしたかも知れません orz)
Linuxのルートパーティションがマウント出来ないことがある
ブート手順の見直しで回避できました。(2005-09-02)
Linux側のルートパーティションは、nbloader.oを読み出すときにはrwマウントされていると思います。 nbloader.oでNetBSDカーネルが起動した時には、Linux側には"need_recovery"フラグが立った状態となっています。 このため、NetBSD側ではエラーとなりマウント出来ません。 Linuxルートパーティションは玄箱ではext3を使っていますが、この場合NetBSDのfsck_ext2fsは使えないようで、 結局マウント出来ません。 (Linuxのルートパーティションをext2にしたらどうなるかはやっていないのでわかりません。) ルート以外(/mnt等)は正常にアンマウントされていればマウント可能ですので、データの共有はこちらを使用し てください。 もし、/mnt等もマウント出来なければ、いったんLinux側でfsckを行うことでマウント可能になると思います。 ブートローダの説明中の『(比較的)安全な使い方』の手順を踏むことでルートもマウントできたとの報告もあります。
(2005-09-02追記: 『なんちゃってブートセレクタ』でこの問題は解決したと思います(要テスト)。)
NFSルート時に、起動途中で固まることがある
2005-09-
19
20版のカーネル差分&サンプルカーネルで対応しました(2005-09-20)
NFSルートの環境で、読み書き時に固まることがあります。環境によってはほぼ100%固まります。 これは、経験的には途中のハブ/スイッチや、自分側や相手側(NFS export側)のNICの影響を受けることが知られています。 カーネルオプションのNFS_BOOT_RWSIZEを設定することで回避できますので、カーネルコンフィグファイルに options NFS_BOOT_RWSIZE=1024 を追加してカーネルを再構築して下さい。 サンプルカーネルにはこのオプションを追加する予定です。
(2005-09-20追記: 2005-09-
19
20版で対応しました)
USB Hubを認識しない。USB Hubがugenに割り当てられる。
2005-09-
19
20版のカーネル差分&サンプルカーネルで対応しました(2005-09-20)
カーネルconfigファイル(KUROBOX, KUROBOX_HG)の編集ミスで、以下の行が消えてしまっていました。 uhub* at uhub? port ? configuration ? interface ? この行を追加してカーネルをコンパイルし直してください。 サンプルカーネルには次の配布タイミングで追加します。
(2005-09-20追記: 2005-09-
19
20版で対応しました)
電源スイッチで電源が切れない
AVR制御デーモンを作成して対応しました。(2005-10-09)
まだAVRの出力を監視するデーモンを作っていないので、電源スイッチでは電源が切れません。 shutdown -h では切れますので、こちらをお使いください。
NetBSD上のコマンドからAVRの制御がうまくいかない
AVR制御デーモンを作成して対応しました。(2005-10-09)
AVR(/dev/tty01または/dev/dty01)をE81にしようとしてsttyコマンドで変えようとしても、エラーが出ず一見正常なのですが 設定が変わらないようです。 /dev/tty01,/dev/dty01をオープンしているプロセスが一つも無いので、sttyコマンドで触った瞬間だけ設定が変わり、 クローズした所で元に戻っているのだと思います。 回避策を調査中です。 (2005-09-20追記) - /etc/remoteに次のエントリを追加し、tipコマンドを実行しておきます(tip AVR)。(/dev/dty01をオープンできればな んでも良いと思います) AVR:dv=/dev/dty01:br#9600:pa=even:dc: -ここで、~^Z(チルダ,コントロールZ)と押して、tipコマンドを中断します。 - シェルプロンプトから、stty -f /dev/dty01 parenb cs8 -cstopb speed 9600を実行します。 - echo -n "WWWW" > /dev/dty01 でDISK FULLのLEDがつきます。 - echo -n "VVVV" > /dev/dty01 でDISK FULLのLEDが消えます。 やはり何かしら/dev/dty01をオープンしているプロセスが必要そうです。 (AVR制御デーモンを早く作れ、ということでしょうか...)
nbloader.oのカーネル起動オプションが無視される
2005-10-24版のカーネル&nbloader_v2で対応しました。
nbloader.oの引数は"kernel="以外は現在意味がありません。 nbloader.oでは "kernel=" と "cmdline="を受けるようにしてあります。 "kernel="はカーネル(.bin)のパス名で、"cmdline="は起動オプションを渡すものです。 しかしながら、現在"cmdline="の設定は無効です。代わりにカーネル内部で用意したオプションがそのまま使用されます。 配布カーネルではオプションは 0x0 (オプション無し)です。ですのでシングルユーザモードへ切替える、というのは現在の nbloader.oでは出来ません。 (shutdown nowでのシングルモードへの移行は出来ます。) これを直すには、nbloaderとlocore.Sの改造が必要になります。(改造してくれる方募集中 :-)
Linuxバイナリ互換性(COMPAT_LINUX)が有効で無い
2005-10-24版のカーネルで対応しました
配布カーネルはCOMPAT_LINUXを有効にしていません。これはただ単に有効にしていないだけですが、有効にしたらどうなる かも含めてチェックしていません。
"usbdevs -v"コマンドが"usbdevs: no USB controllers found"と言って正常に動かない
2005-10-24版カーネルで対応しました
デバイス(/dev/usb*)が無いからですが、/devで"sh MAKEDEV usbs"を実行してもエラーになります。(これもバグです) カーネル側の対応とそれに合わせたMAKEDEVファイルが必要になります。 次リリースに合わせてこの対応を行う予定です。
(2005-10-25追記)ダウンロードにあるMAKEDEVファイルを使用して、/dev/以下を更新してください(sh MAKEDEV usbs)。
一般ユーザでpstat,vmstat等のコマンドが使えない
デバイスノードのグループを変更しました。
以下のデバイスノードのグループがkmemになっているためです。 - /dev/drum - /dev/kmem - /dev/lkm - /dev/mem sandpointの配布バイナリでは、例えばpstatではbinグループにsetgidされていますので、上記デバイスノードはbinに 属するのが正しいと思います。 /dev/MAKEDEVファイルの > g_kmem="2" を > g_kmem="7" に修正し、前記デバイスノードを一旦削除の上で作り直すことで正常に動作するようになります。 > # cd /dev > # vi MAKEDEV (修正) > # rm drum kmem lkm mem > # sh MAKEDEV std lkm
MAKEDEVファイルについては現在配布中のものを修正しましたのでご利用下さい。
I2Cドライバが未完成
OK、だと思います
I2Cドライバはまだデバッグが完全には済んでいません。特に1バイトリードはコードが不足していると思います。 RTCのドライバは1バイトリードを行っていないので、問題は出ないと思いますが、他の用途に転用される場合は注意して 下さい。 # 事実上玄箱に限定されたモノと思って下さい。 バグにより時計が大幅にずれることもあるようです _o_ (2005-09-20追記: 2005-09-19版で1バイトリードに対応しました。また、若干のバグも修正しました。まだテストが十分 とはいえませんのでこの項目はここに留め置きます。) (2005-09-20追記: エンバグしました orz 当該個所は修正しましたが、ほかにも何かありましたら教えてください。)
TeraStationの温度計ドライバでの1バイトリード/ライトも正常に出来ていますので、一応解決済みへ移動しました。ドライバの変更は有りません。
ギガビット接続の際、reドライバがデバイスを見失うことがある
その後問題が出ていませんので解決済みへ移動しました。
RTL8110Sを使っている機種でギガスイッチに接続している場合、電源ONやリブート時にreドライバがデバイスのループ バックテストに失敗し、re0が認識しなくなることがあります。 現象はランダムに発生します。電源OFF状態からでも成功/失敗はランダムです。 この現象はどうもハブとの相性も有りそうです。 100BTではこの現象は見られませんので、より安定した動作をお望みならば100BTなスイッチへ接続したほうが良いでしょう。 (2006-03-17追記: if_re.c::re_diag()中のre_init(ifp);の後にDELAY(100000);を試しに入れてみたところ、(今のと ころ)現象が出なくなった模様です。(引き続き実験中))
HDDの拡張領域上のNetBSDを認識しない
2006-09-29版3.xカーネルで対応しました。
NetBSD/sandpointでは拡張領域のNetBSDは認識できません。当面は基本領域をお使い下さい。 対応は実現方法を検討中です。
バグを教えてください。上に反映します。
- (皆様御存知だとは思いますが)
「シリアルに『ブレークの送信』を行うとデバッガに落ちる」
options ZS_CONSOLE_ABORT
ですね。これを消せばいいと思います。
僕は、いつもこれを付けています。
一度付いているものを消すより、追加する方が簡単だから
GENERIC から外しておいた方がいいと思うけれど、それは
それで、それ知らなかったぁ、となるので、どっちもどっち
ですね。
-- Makoto Fujiwara (2005-09-27 21:33:18) - ちょっと引っかかっていたので調べましたが、"options ZS_CONSOLE_ABORT"を使っているarchは
- mac68k
- macppc
- next68k
だけみたいです。
玄箱(sandpoint)の場合は、"options DDB"を外してみて下さい。
-- かわうち (2005-10-16 12:35:27) - > カーネルロードアドレスが0x90000になっている
http://www.unnumbered.net/~umeno/kurobox/tmp/textaddr_0x0.diff
みたいなパッチを作成してロードアドレスを0x0にしてみたところ
0x0 番地から 割り込みベクタの予約した領域が終わる0x3000番地に
ジャンプさせているだけですが、問題なく動作しているようです。
# 予約が0x2FFFまでであって8241の場合は0x1FFFまでしか
# 割り込みベクタに使っていないようです。 -- うめの (2005-10-18 21:36:36) - 情報ありがとうございます。577536バイト得しますね(^_^)。
ブートローダの次ネタも集まりつつあるので、これも含めて検討します。 -- かわうち (2005-10-19 00:00:16)
35776
このwikiの更新情報RSS