そこそこ新しい一覧については http://www.macbsd.com/macbsd/macbsd-docs/machine-status/ を参照してください。
[新ADB ROMドライバーを待って、対応・未対応ADBデバイスのmachine-statusファイルのようなリストを作るつもりです]
今のところは INFOシートを参照してください。
[これについても、近々皆に訊いて情報を集め、video-card-statusというファイルを作るつもりです]
一般に24-bitビデオカードはNetBSD/mac68kと相性が悪いようです(どちらにせよ、現在のところ24-bitカラーに対する対応は何もないわけですし)。
今のところは INFOシートを参照してください。
[いつかaccelerator-card-statusというファイルを作ろうと思います]
現状では33MHzと50MHz両方のDaystar 030アクセラレータで動作が確認されています。ただし、コントロールパネルで外部キャッシュをディセーブルしてからブートする必要があるかも知れません。DiiMOの50MHz 030アクセラレータ、またMac II用のDove MaraThon 030アクセラレータでも動作するようです。
Kevin Radke (radke@cpre1.ee.iastate.edu)がDaystarアクセラレータの外部キャッシュの対応作業をしています。彼のカーネルを試してみたい場合は以下のURLから入手できます:
ftp://cpre1.ee.iastate.edu/pub/netbsd/
040の機種用の040アクセラレータも動作するかも知れません。しかし、030の機種で040アクセラレータを使う際には困難が予想されますが、しかしCarrera040アクセラレータに対応するための作業が進められています。
各種アクセラレータカードへの対応状況については INFOシート を参照してください。
イーサネットステータスページ(英語)を参照してください。
[訳註:日本語版は こちらです。]
FDHD (つまりMFMフォーマット、高密度フロッピー)について、中田健 (kenn@eden.rutgers.edu):
SWIMチップを直接制御するために必要なドキュメントが何もない状態なのでフロッピードライブには対応していません。ROM上のドライバーを呼ぶのはあまり良い方法とは言えません。というのはNetBSDのマルチタスクと干渉することが予想されるからです(Mac OSでフロッピーをアクセスするときのマウスカーソルの動きに気づきましたか?)。
低密度フロッピーについては、Hauke Fath (saw@sun0.urz.uni-heidelberg.de)が極めて実験的な IWMドライバーをLKMの形で開発しました。関連するファイルは以下のURLから入手できます:
ftp://ftp.macbsd.com/private/hauke/README.iwm
ftp://ftp.macbsd.com/private/hauke/iwmModule.tar.gz
Haukeも注意していますが、このキットを使うに当たっては自分の責任で行ってください。
現在のカーネルはApple Sound Chipに対応していますから、コンソールやdt最新版(1.1.5)ではビープ音を出すことができます。しかし、X Window Systemでは音が出ない場合があります。詳しくは X使用中のビープ音に関する項を参照してください。EASCまたは他のサウンドチップを内蔵した機種はまだ対応されていません(私のQuadra 700のEASCではカチッという音がするだけです)。しかし、より良いサウンド対応のため作業が進められています。
CPUとしてMC68020を使用している場合のみ外付けPMMUが必要です。Mac IIに標準で搭載されているAMUではNetBSDは動作しません。
現在のカーネルはFPU無しの機種でもブートしますが、FPU命令を必要とするプログラムはカーネル組み込みのFPE (floating-point emulation)無しでは動作不可能です。実行するとカーネルデバッガーに落ちます。幸いなことに、この問題はほとんど解決されています(LC040については後述)。
中田健(kenn@eden.rutgers.edu)からのコメント:
最近のカーネルはどれでも、不完全ながらFPEが組み込まれています。FPE機能が必要ならcurrentカーネルを入手してください。
NetBSD/mac68kをハードウェアFPU無しで使用している人は、ぜひこの、FPU無し環境用のmathライブラリーをインストールしてください:
ftp://ftp.macbsd.com/private/kenn/libm-nomc68881.tar.gz
このgzip圧縮されたtarファイルには、FPEがうまくエミュレートしないFPU命令の実行を避けるよう作られたlibm (mathライブラリー)が入っています。したがって、これを使えば、現状の不完全なFPEでも"unimplemented instruction"エラーが避けられるでしょう(ここでやろうとしているのはi386でずっとやっていることと非常に似たことです)。
[訳註:上のURLに示されたファイルは1.1か1.2当時の古いライブラリーなので、現在の1.3用には適していません。以下の手順に従って自分でライブラリーを作ってください。私も1.3用ライブラリーを作って上のディレクトリーにアップロードするつもりです]
もし自分でFPU無し用mathライブラリーを構築する場合は、/usr/src/lib/libm/Makefileに以下のパッチを当て、make && make installを行ってください:
*** Makefile~ Sun Oct 26 10:28:48 1997
--- Makefile Sun Oct 26 10:30:30 1997
***************
*** 61,70 ****
# s_sinf.S s_tan.S s_tanf.S
.elif (${MACHINE_ARCH} == "m68k")
.PATH: ${.CURDIR}/arch/mc68881
! ARCH_SRCS = e_acos.S e_asin.S e_atanh.S e_cosh.S e_exp.S e_fmod.S e_log.S \
! e_log10.S e_remainder.S e_scalb.S e_sinh.S e_sqrt.S s_atan.S \
! s_ceil.S s_copysign.S s_cos.S s_expm1.S s_finite.S s_floor.S \
! s_log1p.S s_logb.S s_rint.S s_scalbn.S s_sin.S s_tan.S s_tanh.S
.elif (${MACHINE_ARCH} == "vax")
.PATH: ${.CURDIR}/arch/vax
NOIEEE_ARCH=n_infnan.S n_argred.S n_sqrt.S
--- 61,67 ----
# s_sinf.S s_tan.S s_tanf.S
.elif (${MACHINE_ARCH} == "m68k")
.PATH: ${.CURDIR}/arch/mc68881
! ARCH_SRCS =
.elif (${MACHINE_ARCH} == "vax")
.PATH: ${.CURDIR}/arch/vax
NOIEEE_ARCH=n_infnan.S n_argred.S n_sqrt.S
上のパッチは1.3のソースに対してもきれいに当たるはずです。それよりも古いもの(または、ひょっとして新しいものも)では手でパッチを当てる必要があるかも知れません。
1.1リリースのカーネルにはFPEは組み込まれていないこと、また1.2リリース以降のカーネルには組み込まれていることに注意してください。
注意: FPEは存在しますが、MC68LC040をCPUに持つ機種では、現在のところFPEは完全には動きません(たとえ上に挙げたmathライブラリーを使っていても、です)。典型的な症状は、頻繁な"illegal instruction"エラーやセグメンテーションフォールトです。多くの人達が利用可能なMacBSDシステムを実現するため、このバグの修正作業が進められています。LC040とFPEにまつわる情報については以下のページをご覧ください:
http://www.macbsd.com/macbsd/LC040-and-BSD.html
LC040でのセグメンテーションフォールトの大部分を引き起こしていたバグを、Kelly Campbellが最近見つけて修正しました。しかし、未だにLC040上でのある種の操作に対してFPEは正しい動作をしません。
実はそれはもうやってみたのです。その結果、Software FPUは基本的に例外処理をSANEルーチンへリダイレクトするだけであることがわかりました。自前ではFPUをエミュレートしていないのです。FPUエミュレーションは中田健によって作業が進められています。
詳しくは 前の項を参照してください。
IIシリーズMacで内蔵ビデオを持つものでは内蔵ビデオは対応しています。Quadra/Centrisシリーズの内蔵ビデオも、NetBSD 1.3リリースではほとんどの機種で対応しています。ただ、Booterの"Booting Option"ダイアログボックスで、"LC575 video hack"を有効にする必要がある機種もあるかも知れません。PowerBookについては対応しているものもしていないものもあります。現在のところ、公式にはモノクロのみのサポートですので注意してください。カラー対応は作業中です。
より詳しい情報を得るにはマシンステータスファイルをご覧ください:
http://www.macbsd.com/macbsd/macbsd-docs/machine-status/
Connected to localhost.
Escape character is '^]'.
telnetd: All network ports in use.
Connection closed by foreign host.
中田健(kenn@eden.rutgers.edu)より:
Ptyが足りなくなっています。デフォルトでは古いバージョンのInstallerは4個のptyデバイスしか作りません。一方、1システムで最大64個までのptyデバイスを持つことができます(/dev/pty[pqrs][0-9a-f])。デバイスを追加するにはrootにsuして/devディレクトリーに移動し、以下のコマンドを実行してください:
sh MAKEDEV pty0
これで、デフォルトに加えて12のpty (ptyp4からptypfまで)が作られます。GENERICカーネルコンフィギュレーションでのデフォルトのptyデバイス数は16ですから:
sh MAKEDEV pty1
もし16より多くのptyデバイスが必要な場合は、カーネルコンフィギュレーションファイルのmaxusersとpseudo-device ptyに指定する数を増やしてカーネルを再構築する必要があります。
註釈:バージョン1.1e以降ではInstallerは、GENERICカーネルで利用可能な最大数である16のptyデバイスを作成するようになりました。しかし、デバイスを作成するルーチンにバグがあり、これはバージョン1.1fで修正されました。ですから1.1f以降のInstallerを使用してください。
Mac OSのモニターコントロールパネルで、「メイン」[訳註: 1番]のモニターに外部モニターを指定してください。
NetBSDでのSCSIデバイスのナンバーは、SCSI IDの順に0から順につけられます。つまり、最も小さなIDのSCSIディスクドライブが/dev/sd0、次のものが/dev/sd1といった具合です。これはブート時に割り当てられる番号であることに注意してください。
カーネルを自分でコンパイルすれば、SCSI IDとデバイスファイルの対応を固定することも可能です。それにはカーネルコンフィギュレーションファイルに次のように書きます:
sd0 at scsibus0 target 4 lun 0
sd* at scsibus? target ? lun ?
はい、できます。Bill Studenmund (wrstuden@loki.stanford.edu)がghostscript用ドライバーを書きました。それについて彼はこう言っています:
私はDeskWriterを使っていますから、手助けできるかも知れません。
LocalTalkコネクターを使ってはいけません。
printcapを使ってシリアルポートを設定しないでください。lpdは古い形式の
tty設定ルーチンを使うので、いかした(かつ必要な)現代的ttyの機能を使用す
ることができません(ルーチンの名前を忘れてしまったのでちょっと曖昧です
が)。さらに、lpdは19200bpsより速い転送速度が使えないようにハードコード
されています。正確にどこでこの制限が課せられているのかは忘れましたが、
私の知る限りでは、その転送速度を設定するルーチンは57600bpsではうまく動
かないので、lpdだけの問題ではありません。
私は"stty -f /dev/tty01 raw 57600 crtscts"という行を私の/etc/rc.local
スクリプトに入れてあります。あなたの場合は[訳註:この「あなた」と
はBillのemailの直接の受取人のことでしょう] "stty -f /dev/tty01
raw 57600 crtscts opost onlcr"をお薦めします。これによってすべての文字
処理が無効とされ、ポートの転送レートが設定され、ハードウェアフロー制御
が選択され、そして出力処理が有効とされてUNIXのNLがCRに変換されるように
なります。
または、もう少し待つ気があれば、私はDeskWriterにNLをCR+NLとして受け付
けさせ、そしてファイルをプリントするような、単純な入力フィルターを持っ
ています。この方法ならstty出力処理は必要なくなりますから、PCLコードを
プリンターにダンプするだけでグラフィックスをプリントすることができます。
さらにBillからのフォローアップ:
私はDeskWriterプリンターでGhostScriptを動かすことに成功しました。
gsを動かすにはこれをダウンロードしてください:
ftp://ftp.macbsd.com/pub/NetBSD/contrib/gs
.
gs262.mac68k.tgzはgzip圧縮されたtarファイルで、私が作ったgsバイナリー、
変更されたソースファイル、インストールに必要なすべてのファイル、ドキュ
メント、そしてenscriptのフリーウェアバージョンであるnenscriptが含まれ
ています。ドキュメントはまだ粗くて、ある人がどれだけ酷いか見てくれてい
ます。:-)
ghostscript-fonts-2.6.2.tgzはgsをもっと使えるものにするためのPSフォン
トのコレクションです。
それ以外のファイルはソースコードです。必要ないでしょうがもしかしたら見
たいと思うこともあるかも知れません。:-)
試してみてどう思うか教えてください。
はい、Monroe Williams (monroe@pobox.com)のおかげで、Color StyleWriter 2400に対応したドライバーができました。これはStyleWriter IとIIにも(恐らくStyleWriter 1200も)対応しているはずです:
私のNetBSD用StyleWriterドライバーの新バージョンは以下から入手できます:
このドライバーはColor StyleWriter 2400 (白黒とカラー)、StyleWriter IIとStyleWriter I (*)で動作します。他の機種では動くかも知れませんし、動かないかも知れません。誰でも実験台は歓迎です。;)前バージョンと比較していくつもの改良が行なわれました。例えばより良いシリアルポート制御、高速プリントのためのより良いバッファ管理、実行時オプションによるより良いコンフィギュレーション、といったものです。
(*):私のStyleWriter Iはちょうど2400が動きはじめたときに壊れてしまいましたので、StyleWriter Iについてテストはできませんでした。でも動くと思います。
中田健 (kenn@eden.rutgers.edu)のコメント: [訳註:内容が古いのでばっさり削除してしまいました。最初にマルチボタンポインティングデバイスのサポートを組み込んだのは確かに私ですが、この辺りの話の最近のエキスパートは疑いなくJohn P. Wittkoskiでしょう。で、代わりに:
現在サポートされているマルチボタンポインティングデバイスは、以下のリストの通りです:
最初のふたつは恐らく真中と右ボタンが出力するキーコードをプログラムできるタイプだと思います(オプション+矢印キーを出すよう設定すればよい)。同様のデバイスであれば上の製品に限らず対応できるはずです。Logitech (日本でのブランド名はロジクール)の対応機種とアルプスグライドポイントはApple Extended Mouse Protocolに対応しています。残り二機種(Mouse Systems A3とMicroSpeed)はそれぞれ独自プロトコルを使用していますが、プロトコルが解析されてカーネルのADBドライバーにサポートが組み込まれました。Kensingtonの製品も有名ですが、独自プロトコルを使用しているのは間違いなく、まだ誰も解析していないので対応はされていません。誰かよろしく:-)
上に挙げた以外のマルチボタン製品でも、最低1個のボタンだけは使用できることが多いようです。これはApple純正品との互換性を持たせているためでしょう。]
Extended Mouse Protocol に関するさらなる情報は Apple の web サイトの http://developer.apple.com/technotes/hw/hw_01.html#Extended Apple Mouse Protocol で参照できます。1.2G以降のカーネルでは、オプションキーと同時に"1"、"2"、"3" のキーを押すことで、それぞれ左・中・右のマウスボタンをエミュレートすることも 可能です。ただし、これは GENERIC カーネルではデフォルトで無効になっています。 FAQ 9.22 を参照してください。
以下のようにしてください:
/dev/cd0?が存在することを確認する
cd /dev; sh MAKEDEV cd0
mkdir /cdrom
mount -t cd9660 -o ro /dev/cd0c /cdrom
mountコマンドの実行だけで済みます]
Jack Culpepper (jack@cs.hmc.edu)からの情報:
モニターのコネクターピン番号を調べて、ペーパークリップで4番と11番のピン(モニターセンスコードピン)をショートします。(私はもう何箇月もこの手を使っています。)もうひとつの手は、$25かそこらでMacモニターをエミュレートできるSVGAアダプターを買うことです。しかし、何のビデオハードウェアもついていないマシン(例えば古いIIシリーズのMacでNuBusビデオカードを接続していない場合など)でブートするのは不可能でしょう。というのは、そのような構成ではMac OSをブートすることもできないからです。
ビデオコネクターのピン構成についての詳しい情報は、AppleのTechNoteにちょうどその話題を取り扱ったものがあります:
http://developer.apple.com/technotes/hw/hw_30.html
このポインターについて教えてくれたNigel Pearson (nigel@ind.tansu.com.au)に感謝します。
はい、NetBSD/mac68kはUNIXの習慣にしたがい、ディスクあたり8パーティションまでしか使えません。この上限を取り払うのはなかなか大変なことになるでしょうが、NetBSD 1.4リリースに向けてプロジェクトが進行中です。さて、この上限は古いカーネルで問題を引き起こすことがあります。なぜなら古いカーネルは、使えるファイルシステムが格納されているかどうかのチェックを最初の8パーティションに対してしか行わないからです。Apple SCSIドライバーとパーティションマップそれにその他のパーティション[訳註:特にMac OSパーティション]がディスクの先頭にきますから、後ろの方に追いやられたNetBSDパーティションが見過ごされてしまうことがありました。しかし、最近のカーネルでは(NetBSD 1.2以降なら確実)最初の32個のパーティションをスキャンしてその中からNetBSDパーティションを拾い集めてきます。これでほとんどの場合問題はなくなるはずです。パーティションの文字のつけ方があるので最大で6個までしかパーティションは使えないことに注意してください(すなわち、a、d、e、f、g、hの6個がFFSやHFSパーティションに割り当て可能ですが、bは常にスワップ用、cは常にディスク全体を表わします)。
この問題は、認知はされているもののまだ修正はされていない、ncrscsiドライバーのバグによるものです。何らかの理由でQuantum製ドライブでよくこのバグが顕在化するようです。よく見られる症状としては、大量のディスクI/Oが行われているときに、ドライブのアクセスランプが突然つきっ放しになり、しかしシステムはハングしてしまいます。そしてリブート後にfsckをかけるとファイルシステムにはかなりいやらしいダメージが与えられている、というものです。時には、あるバイナリーファイルを実行しようとしてみるまでダメージに気がつかないこともあります。バイナリーファイルがデバイスファイルになってしまうのです(つまり、ls -lで見てみると、b---------とかc---------のように見えます)。
この問題を修正するために、Scott Reynolds (scottr@og.org)がsbc SCSIドライバーを書きました。これは標準のncrscsiドライバーを置き換えるものです。このドライバーはデフォルトではポール(poll)モードで動作するため、ncrscsiよりもやや転送が遅くまたCPUインテンシブです(とくにCD-ROMドライブやテープドライブのような遅いSCSIデバイスでは)。しかし、データ破壊の可能性はかなり少くなります。Scottは、ncrscsiドライバーでトラブルが発生している場合にのみsbcドライバーの使用を薦めています。
最近Scottはいくつかの変更をドライバーに対して行ない、それによってMOドライブでの安定性が増し(メディアダメージや部分的に書き込まれたブロックなどの問題がなくなりました)、また、いくつかの/遅いデバイスでの性能を向上させました。性能向上について、Scottは以下のように語っています:
いくつかの/遅いターゲットで性能が向上するような変更を`sbc' SCSIドライバーに加えたところです。もっと細かくいうと、あまり枯れていない[訳註: ? `not-quite-cooked']ブラインドモード転送を使わないでもディスコネクト・リセレクトに対応しました。しかし、SCSI仕様にはディスコネクト後の動作について曖昧な点があるのでデータ破壊の危険性もあることに注意してください。もしあなたが壊れたファイルシステムの取り扱いに慣れていない/自信がない場合は、ここで読むのを止めてください。
このモードを有効にするには、単純に`flags 0x5'をカーネルコンフィギュレーションファイルのsbc0の行に加えます。このように:
sbc0 at obio? flags 0x5
[訳註:この段落はちょっと曖昧な部分があってよく意味がわかりませんでした。書いた本人に訊いてみようかとも思いますが、忙しいのでたぶん教えてくれる暇がないでしょう。]単一SCSIターゲットの場合、ドライバーの実際の性能はほんの少し落ちますが、もしあなたが性能を測定してみたら性能は目に見えて飛躍的に向上するでしょう!このパラドックス(もしそう呼ばせてもらえれば)の理由は、ドライバーがターゲットをディスコネクトせずにPDMA処理で多くのCPU時間を消費するので、ディスクが要求されたデータを取ってくるのを待っている間にもクロックティックが失なわれるからです。この変更によって、多くの場合クロックティックが捕まるようになり、SCSIによって「失なわれる」ティックはEthernetの大量I/Oによって失なわれるよりもずっと少なくなります(私のIIcxでのクロックのずれは90秒/日未満です)。また、テープドライブのような遅いデバイスが、SCSIバスを一旦放棄してCPUにしばらくの間他のことをさせることも可能になりました。
最後に: もしあなたのターゲットがSCSI仕様の緩い解釈によって影響を受けているもののひとつである場合、sys/scsi/scsiconf.cのquirkテーブルにSDEV_AUTOSAVEが必要になるでしょう[訳註:例えば、こんな感じでscsi_quirk_patterns[]にエントリーを加えます:
{{T_DIRECT, T_FIXED,
"QUANTUM ", "ELS85S ", ""}, SDEV_AUTOSAVE},
内側の大かっこの中の、最初と2番目は、ハードディスクであれば変える必要はありません。3、4番目はdmesgの出力の、sdX(Xは数字)で始まる行を見て、その情報を書き込みます。例えば、dmesgで以下のように表示されるとします:
sd0 at scsibus0 targ 0 lun 0: <QUANTUM, LPS270S, 590A> SCSI2 0/direct fixed
このドライブをquirkテーブルに加えるとしたら:
{{T_DIRECT, T_FIXED,
"QUANTUM ", "LPS270S ", ""}, SDEV_AUTOSAVE},
のように書くことになるでしょう。ここで注意が必要なのは、ベンダーと製品名の文字列は固定長なので、短い場合は空白でパッディングする必要があることです]。この問題について総合的により良い解決策を探す努力が行われていますが、今のところはソースツリーに対するローカルな変更でなんとかできます。どうすれば影響をうけているかわかるでしょうか?通常、ファイルシステム破壊がすぐに起きます。ドライバーの作業中そしてquirkテーブルの必要性を調べている間、私はいくつかのディスクのスーパーブロックを、少くとも6回は壊しました。(バックアップコピーがあって良かった!)
このドライバーは以前のドライバーと同じく安定しているはずです。確かなのはこっちの方がより「正しい」ことですが、ドライバーの機種非依存部分に少くともひとつのバグが残っており、パニック後のカーネルダンプに障害を及ぼしています。少くとも一台のIIciでトラブルがあるのを知っていますが、私の個人的経験では二台のIIciが安定して動作しています(実際、そのうち一台ではsbcドライバーが_必要_です)。
いくつか新ドライバーを組み込んでコンパイルされたカーネルがありますから、そちらを使うのが良いでしょう。そうしたカーネルは通常GENERICSBCやkernelname-SBCのように、末尾にSBCという文字列を持った名前がついています。最近のSBCドライバー入りカーネルは、以下の場所で入手できます:
ftp://ftp.NetBSD.org/pub/NetBSD/arch/mac68k/new/
言うまでもないことですが、一度壊れてしまったファイルは削除・再インストールが必要です(私の場合、このためだけにbase.tar.gzファイルを常に保存してあります)。
しかし、ncrscsi ドライバーがただひとつの問題発生源であるとは限りません。たくさんのSCSI関連のトラブルは、質の悪いSCSIケーブルやお粗末なバス終端の結果であることを気に留めておいてください。SCSIチェーンの両端がターミネーターによって終端されなければなりません。また、より短くて高品質のケーブルやアクティブターミネーターに買い換えることを検討するのも良いでしょう。
はい、コンソールソースコード(/sys/arch/mac68k/dev/ite.cを見てください)を変更するか(どちらかというと難しいでしょう)、またはdtというプログラムを入手することができます。dtユーティリティーには色々役に立つ機能があり[訳註:例えば仮想コンソール機能やマウスを使ったカット&ペーストなど]、ビデオ反転も可能です。そのためにはconfig.hというファイルを変更して、INVERSEというマクロを定義し、dtを再コンパイルします。dtはここから入手できます:
ftp://ftp.macbsd.com/pub/NetBSD/utils/dt/dt-1.1.5.tar.gz
まず自分でカーネルを再構築できるようにしてください。次に、カーネルコンフィギュレーションファイルの次の行をコメントアウトしてカーネルを再コンパイルします:
options DISABLE_EXT_CACHE
ADBハング問題は[訳註:32-bit?]dirty ROMを持った機種にだけ起きるようです(つまりSE/30、II、IIx、およびIIcx…実際に障害が報告されているのはIIcxとSE/30だけですが)。症状は二重です:
1) NetBSD 1.2.x以後のある時点から、キーボードとマウス両方接続されていない場合、これらの機種でブート時にハングするようになった。
2) 1997年11月7日以降のカーネルは、もしこれらの機種で拡張キーボードが接続されているとハングするようになった。
注意ですが、これらの症状はMRG_ADBを使用したカーネルでのみ起きるようです。HWDIRECTのものは心配ないようです。
この問題は(少くともこれらの機種では)キーボードまたはマウスが接続されていなくても、あたかも接続されているかのような「おばけ」を作ることが原因と見られています。新しい機種ではこのような「おばけ」デバイスをプローブすると、実際には存在しないことがわかるのですが、上に挙げた機種ではこのような存在しないデバイスをプローブすると反応を待つ無限ループの中でハングしてしまうのです。これが1.2以降で現れた理由は、拡張マウスプロトコル対応によって、そのようなプローブが行われるからです。11月7日の変更は、Logitechの非拡張マウスプロトコル機種への対応で、そのようなプローブが加わったことによります。
解決策は、MRG_ADBではなくHWDIRECT ADBを使う、カスタムカーネルを再構築することです。そうするには、カーネルコンフィギュレーションファイルの次の行をコメントアウトして再コンパイルします:
options MRG_ADB
ftp://ftp.macbsd.com/pub/NetBSD/eskimo.copy/kernels/
前項を参照してください。
あなたがOS本体に加えてXもアップグレードしたと仮定して、これはQuadraおよびCentrisシリーズのMacで内蔵ビデオ回路を使用する、多くのユーザーに影響を与えた問題です。1.3リリースのカーネルでは800x600の解像度への対応がどうも不完全のようです。Steve BrownのMADHATTERカーネルを入手すると良くなるかも知れません:
ftp://ftp9.ba.best.com/pub/sbrown/NetBSD/kernels/
自分でカーネルをコンパイルする場合は、大部分の場合うまくいっている、以下のパッチを当てます。最初のものがMADHATTERパッチで、sys/arch/mac68k/mac68k/machdep.cに適用します:
*** machdep.c.orig Sun Jan 25 18:19:02 1998
--- machdep.c Sun Jan 25 18:20:32 1998
***************
*** 2241,2246 ****
--- 2241,2249 ----
case MACH_CLASSQ:
case MACH_CLASSQ2:
mac68k_machine.sonic = 1;
+ /* The next two lines are the infamous "madhatter" patch */
+ mac68k_vidlog = mac68k_vidphys = 0xf9000000;
+ mac68k_vidlen = 1 * 1024 * 1024;
case MACH_CLASSAV:
VIA2 = 1;
IOBase = 0x50f00000;
こちらのパッチは内蔵ビデオドライバーのモードセンスコードの問題を修正します(sys/arch/mac68k/dev/grf_iv.c):
*** grf_iv.c.orig Sun Jan 25 18:22:18 1998
--- grf_iv.c Sun Jan 25 18:27:53 1998
***************
*** 108,116 ****
sense = (bus_space_read_4(oa->oa_tag, bsh, 0x1C) & 7);
- if (sense == 0)
- found = 0;
-
/* Set "Turbo SCSI" configuration to default */
bus_space_write_4(oa->oa_tag, bsh, 0x24, 0x1d1); /* ch0 */
bus_space_write_4(oa->oa_tag, bsh, 0x28, 0x1d1); /* ch1 */
--- 108,113 ----
上のパッチを提供してくれたSteve Brown (sbrown@shellx.best.com)とMichael Zucca(mrz5149@cs.rit.edu)に感謝します。
今現在では使用できません。NetBSD/mac68kシリアルドライバーが機種非依存ドライバーを使用するよう変更されたときに、この機能は壊れてしまったようです。Bill Studenmund (wrstuden@loki.stanford.edu)によれば:
問題は、現在のオープンコードの中に競合条件[訳註:?"race condition"の訳です]が存在することです。外部クロックが入力されていると、外部クロックピンのステータス割り込みを、本来割り込み許可すべきでないタイミングで許可してしまうでしょう[訳註:割り込みハンドラなどが正常にインストールされていない状態で割り込みがかかるとカーネルパニックの原因になります]。
CTS ピンへのクロック入力は、カーネルにちょっと変更を加えれば大丈夫でしょう(/sys/dev/ic/z8530tty.cの825行目の"#if 0"を"#if 1"に変更します)。CTSのステータス割り込みはデフォルトでは許可されません。;-)この機能を再有効化するための作業が進行中です。
Table of contents of this chapter, General table of contents