Linux日記: 2000年

自分ディストリの作成 その3 (2000.11.11 (2001.3.18加筆))

ブートイメージ、セカンドステージの作成

カーネルパッケージを作り直したとして、そのカーネルからブートしたり、インストーラを立ち上げるようにしなければなりません。 その上、自分の持ってるデバイス専用でなく、汎用のディストリにしたいのであれば、パッケージ内のモジュールを、ローカルブート用、ネットブート用等々、振り分けたりしなければなりません。 また、インストーラが認識、対応モジュールをロードする為には、modules.depやpcitableも書いておかないといけない。 そこが一番面倒かつ難しいとこで、前回あきらめた(^^;とこだったりする。

この作業を助けてくるスクリプトが updmodules (misc/src/trees/updmodules) です。 こいつは、カーネルパッケージから、カーネルとモジュールを抽出して、基本、ネット、PCMCIA用にモジュールを取捨選択してくれます。 同時に、modules.depやpcitableも選択したモジュールに合わせて取捨選択してくれる。 こいつは便利です。

ちなみにこのスクリプトが参照する module-infoは misc/src/anaconda/loader/ にあります。 pcitableは misc/src/anaconda/isys/pci/、misc/src/anaconda/kudzu/、misc/src/anaconda/loader/ 等、いくつかあります。 あ、いい忘れた。 pcitableにエントリがないとデバイスを認識できないし、module-infoにないと認識できても読み込めない(^^;。 というわけで、実行前に更新しておかないといけません(私の場合、qla1280、inic850wドライバのエントリを追加しました)。

cd misc/src/trees/ (以下、misc/src/treesで作業をすると想定)
./updmodules /home/httpd/html/Kondara/RedHat/RPMS(=RPMの位置) BOOT-2.2.18-3ok(=kernelRPMのバージョン)

とすると、カーネルパッケージを展開して、

等の処理をしてくれます。

だけど、updmodulesはそのままでは動きませんでした。 どうやらdepmodのオプションが違うみたいでエラーが出てる。 おかげでmodules.depが空になってしまう(^^;。 多分、modutilsのバージョンが上がったときにオプション指定も変わったのでしょう。 修正。 あれ、まだダメだ。 あ、grep にも問題が。 修正(いったいKondara Projectではどうやってリリース版のイメージファイルを作ってきたのであろう？ 私が中途で挫折した手動作成なのかなぁ)

でモジュールやファイルを用途別に振り分けたら、mkboot、mkhdimageでイメージファイルを作成します。

rm -f initrd-{local,network,pcmcia}.img{.nogz} ../../../images/*.img
./mkboot
./mkhdimage

とすると３種類のブートイメージ( images/ 以下のboot.img、bootnet.img、pcmcia.img)及びRedHat/base/以下のstage2.imgが置き換えられます。 ちなみに、この時に「領域がいっぱいです」みたいなエラーが出ることがあります。 その場合は欲張りすぎです(^^;。 ブートイメージの場合は、1.44MBの容量制限があるので不要なモジュールを削らないといかんでしょう。 セカンドステージの場合は、mkhdimageの中の容量指定が4MBになっているので、8MBとかに増やせば大丈夫みたいです。

パッケージの依存関係等のチェック

RedHat/RPMSのパッケージを入れ替えるときに、同じ名前のパッケージをバージョンアップするだけなら問題はないのですが、元々あったパッケージを削除してしまうと、インストールの最中にエラーを吐いて止まってしまいます。 これはインストーラがRedHat/base/comps を参照しているためで、例えばxmms-aalsaというパッケージをRedHat/RPMSから削除したら、genhdlistするだけでなく、compsの中からも削除しておかないといけません。

また、パッケージ間の依存関係が満たされているかどうか、

cd /home/httpd/html/i586/RedHat/RPMS
rpm -i --test *.rpm

等とやってチェックしておくと良いでしょう。

このへんの手間を惜しむと、せっかく焼いたCDがインストール不能な役立たずになってしまいます。 私がずっと /home/httpd/html 以下で作業していたのは、CDを焼かずにとなりのPCからネットワークインストールして実験していたからです。 おかげさまで、メディアをあまり無駄にしないで済みました。

自作ディストリの概要

というわけでできあがった自作ディストリ(Kondara MNU/Linux 1.2ベース)の概要ですが、次期コンダラ(Jirai)、Rawhide等から改変したパッケージや自作パッケージを盛り込み、かなり趣味の強いものになりました。

等といったところです。 さすがに容量がかなり苦しいので、emacs(xemacsがあるからいいや)、linuxconf等を削ったり、DOCディレクトリ以下を消したりして、ギリギリ650MBに収めてます(^^;。

anacondaの使い方 (3月18日加筆)

と、いろいろ苦労してきたわけですが、RedHat 6.xで採用されたanacondaと呼ばれるインストーラに付属のものを使えばとても簡単にパッケージ構成等のアップグレードが出来ることが分かりました。 acaconda-runtimeというパッケージにあるbuildinstallというスクリプトを使って、 buildinstall (CDツリーのあるディレクトリ) とするだけで、カーネルパッケージその他の展開、ブートイメージの作成等を一発で行ってくれます。 楽々。

私の場合、自分が使う可能性がとても低いドライバなんかはカーネルパッケージから除いているので、途中で警告がいくつか出てます。 最初はうまく動きませんでしたが、これはKondara-JiraiやRawhideのanacondaパッケージがglibc-2.2を前提に作られているためです。 glibc-2.2やkon2等、Kondara-1.2にないパッケージを追加したらうまく動きました。

私のanacondaパッケージはKondara-Jiraiのを元に、1024シリンダを超えたときのlba32オプションのlilo.confへの付加、カーネル2.4のためにshmのエントリをfstabに付加、kudzuのパージョンアップ等の変更を行っています。 


Building images...
/home/Kondara/buildinstall.tree.18153/upd-instroot /home/Kondara/RedHat/RPMS /home/Kondara/image-template /home/Kondara/RedHat/instimage
Assembling package list...
Expanding packages... XFree86-4.0.1-53k3ok.i586.rpm
Expanding packages... Xconfigurator-4.4.6-11k.i586.rpm
Expanding packages...
== 中略 == 

retrieving timezones
Running mkfontdir...
Scrubbing trees...
Scrubbing trees... /home/Kondara/image-template
Scrubbing trees...                             
Scrubbing trees... /home/Kondara/RedHat/instimage
Scrubbing trees...                               
Compressing .mo files in stage2 images...
Patching python library...
Removing unused python files in hdimage... done.
Compressing ramdisk install images...
*** pcitable error *** Card not found: S3 Savage/MX
*** pcitable error *** Card not found: S3 Savage/MX
/home/Kondara/buildinstall.tree.18153/mk-images /home/Kondara/RedHat/RPMS /home/Kondara /home/Kondara/image-template i386
== 中略 == 

Module aacraid not found in kernel rpm
Module agpgart not found in kernel rpm
Module qlogicisp not found in kernel rpm
Wrote initrd.img (964k free)
== 中略 == 

Wrote /home/Kondara/images//boot.img (130k free)
Wrote /home/Kondara/images//bootnet.img (174k free)
Wrote /home/Kondara/images//pcmcia.img (190k free)
Wrote /home/Kondara/images/de/boot.img (129k free)
Wrote /home/Kondara/images/de/bootnet.img (173k free)
Wrote /home/Kondara/images/de/pcmcia.img (189k free)
== 中略 == 

Wrote /home/Kondara/RedHat/base/hdstg2.img (0k of 4096k free)
Wrote /home/Kondara/RedHat/base/hdstg1.img (652k of 3100k free)
 16.70% done, estimate finish Tue Mar 13 23:31:44 2001
 33.35% done, estimate finish Tue Mar 13 23:31:50 2001
 50.05% done, estimate finish Tue Mar 13 23:31:50 2001
 66.72% done, estimate finish Tue Mar 13 23:31:50 2001
 83.38% done, estimate finish Tue Mar 13 23:31:52 2001
Total translation table size: 0
Total rockridge attributes bytes: 370713
Total directory bytes: 882688
Path table size(bytes): 3350
Max brk space used 21c8a4
29984 extents written (58 Mb)
Wrote /home/Kondara/RedHat/base/stage2.img (60032k)

自分ディストリの作成 その2 (2000.11.4)

ブートイメージの作成(→失敗(^^;)

Kondara等、Linuxをインストールするにあたっては、フロッピーまたはCDから起動するとインストーラが立ち上がって、インストールを行うわけですよね。 この際の起動イメージはboot.imgというファイル( ネットワークインストールならbootnet.imgだったりしますが)です。 インストーラ自身はもちろんLinuxで動くものですから、結局これはFDに収まる最小構成のLinuxであるわけです。

もちろん1.44MBしかないFDには最小限のものしか入りません。 そもそもローカル用(boot.img)、ネット用(bootnet.img)、PCMCIA用版(pcmcia.img)と3種類あるのも、全てのデバイスドライバをカーネルにブチ込んだりしたらフロッピーに収まるわけないので、モジュール化しておいて、それぞれの用途に応じたモジュール群だけで構成したイメージを作っているためです。

boot.imgを例にとると、Linuxカーネル(vmlinuz)とinitrd.img、インストール前のメッセージ等が入ったmsdos形式の1.44MBのイメージファイルになってます。 initrd.imgは最小構成のファイルシステム及びコマンド、モジュール群が入ったext2形式のイメージファイルで、容量を稼ぐためgzipで圧縮されてます。 中に収められたモジュールもtarだとバイナリがでかいからか、cpio + gzipでまとめられてたりと、フロッピーの容量内に収めるためにいろいろ工夫されてるようです。

原理的には、mount -o loop 〜でマウントして適当なとこに展開し、中身を入れ替えて作り直せばいけると思ったのですが...、ダメでした。 私の作ったイメージファイルでは、そもそもカーネルが立ち上がらぬ(^^;)。

むむむ。 なんかヒントがないかな〜とKondara CDの中身をいろいろ眺めてみたら、misc/src/anaconda, misc/src/trees 以下にいろいろツールが入ってるのに気がつきました。 ドキュメントがないので、片っ端から動かしまくってみたのですが、どうやらうまくいけそうです。 長くなったので、以下次号。

自分ディストリの作成 その1 (2000.10.7)

私のLinux環境は現在のところ、Kondara MNU/Linux 1.2(ftp版)をもとに自分のプライベートパッケージを加えたりした状態です。 当然、Kondaraではいくつかのバグやセキュリティ問題に対応した修正パッケージも公開してますから、私の最新環境を作るには、Kondaraをインストール後、結構たくさんのパッケージを差し替えなくてはなりません。 といっても、このへんのものはバイナリ・パッケージにしてあるので、もう一度 rpm -Uvh でもすむわけです。 一番の問題は、私の自宅の2台で使っているSCSIカードが普通の2.2系カーネルでは対応してないことなんです。 まぁ QLogic 12160チップの方は2.4系のソースツリーには既にドライバが入っているので近い将来には問題なくなるのですが、INIC-850の方はねぇ(本来Card Bus用のチップをラトックがPCIカードに独自に載せている)。

というわけで、これらカードに対応し、追加・更新したパッケージも含んだオリジナルのディストリビューションを作成してみようと思い立ったわけです(無謀)。

まず、Kondara 1.2のイメージが必要です。 CD-ROMを持ってれば一番楽でしょうが、無い人は ISOイメージをダウンロードしてくるか、mirror で持ってくるしかないですね。 まぁ 600MB以上ありますからツライところですが、これがないとはじまらない。

ISOイメージの場合は、さらにイメージを適当なとこにmountしておいて、内容をコピーしなくてはなりません。 合わせて1.2GBも空きが必要になる〜。 私は ext2のパーティションにそんなに多くを割いてはいないので、ISOイメージを置いとくのには Windowsのパーティションを使っていたりする(^^;。

mount -t iso9660 /tmp/i586.img /mnt/cdrom -o loop
cp -a /mnt/cdrom/* /home/user/i586

ちなみに各ディレクトリに必ずTRANS.TBLができちゃいますが、rm -f `find . -name TRANS.TBL` とかやって消しちゃいましょう。

パッケージリストの更新

まずは RedHat/RPMS の中のパッケージを置き換えます(例：binutils-2.9.5.0.42-0k1.i586.rpm → binutils-2.10.0.18-3k.i586.rpm)。 以下の作業では、CDイメージを /home/user/i586 以下に展開したと仮定してます)。

次に、インストーラが新しいパッケージを使ってくれるようにしなくてはならないわけで実はこれは既に用意されているプログラムを利用するだけで済む簡単な作業で、RedHat/RPMSの中身を書き換えておいてgenhdlistを実行するだけです。 これで、インストール作業時に参照されるリスト(RedHat/base/hdlist)が更新されます。

cd misc/src/anaconda/utils
./genhdlist /home/user/i586

実は今回の話はJFにあるBurning a RedHat CD mini-HOWTO、ほぼそのまんまです。 先人の知恵に感謝しなくてはなりませんね。

ISOイメージを作る、CDを焼く

JFを参考に新しいISOイメージを作ります。

cd /home/user/i586
mkisofs -v -r -T -J -V "Kondara" -b images/boot.img -c images/boot.cat -o /tmp/kondara.img .

後は/tmp/kondara.imgをCDに焼くだけです。 このCDを使ってインストールすると、ちゃんと新しいパッケージ(例：binutils-2.10.0.18-3k)を使ってインストールしてくれます。

cdrecord dev=0,0,0 speed=6 /tmp/redhat.img

CD-Rの速度やデバイスは環境に合わせて変える必要があります。

実は、私のやりたいことはまだまだ先の話しです。 RPMS以下を差し替えたって、インストール時に使用されるカーネル、initrdの中身は元のままですから、私のSCSIカードは認識できないんです。 ここからはかなり面倒な世界になりそうです。 大丈夫かなぁ？

謎のSCSIカードは使えるか？（2000.9.2, (9.9改訂)）

昔、ラトックというベンダーからREX-PCI33というSCSIカードをモニタで頂いたことがありました。 こやつはUltra WIDEなSCSIカードなんですが、搭載しているチップはCard Bus用のはずのInitio INIC-850。 こんな妙なカードじゃ、ドライバはラトックからしか出ないし、どうやってLinuxで使えっちゅうねん。 ということで今までお蔵入りにしてました。

だったのですが、久々にラトックのWebサイトを訪れてみると、Linuxの動作確認情報が掲載されていました。 一応みてみたら、REX-PCI33はTurbo LinuxとRedhatには確認がとれているようで(なぜかKondaraでは未確認みたいだけどね)、βドライバがソース付で公開されていました。 何はともあれソースが公開されるのはいいことですね。 感謝、感謝。

ソースがあるなら、自分でmakeすれば他のディストリでも動くかもしれないじゃ〜ん、ということで早速実験。

... 轟沈(^^;。 コンパイルでエラーでまくりです。 現在TurboやRedhatが採用しているカーネルは当然2.2系ですから、2.4.0-test7なんて入れて遊んでる私の場合は、素直にはいかないようですね。

まぁソースが公開されてるわけですから、何とかなるかもしれません。 コンパイル時のエラーメッセージを見る限り、proc周りやPCIのベースアドレスの取得方法なんかが2.2.xとは違ってきているようです。 linux/drivers/scsi に収録されている他のSCSIドライバを参考にいじってみました(同じInitioの ini9100u.{c,h} あたりが比較しやすいでしょう)。

というわけでとりあえずコンパイルできるようにしてみたのが、いい加減なパッチ シリーズ Part3、inic850ドライバを2.4.0-testxで無理やりコンパイルできるようにするパッチ (10月7日版)です。 手順としては、

  1. ラトックのドライバを解凍し、上の「無理矢理コンパイル」パッチをあてる
  2. pci31_33/src の中身を /usr/src/linux/drivers/scsi にコピー
  3. inic850をカーネル構築時に選択可能にするパッチ(2.4.0-test7用)をあてる
  4. make xconfig (or menuconfig等)で inic850を選択して、カーネルを再構築

みたいな感じでうまくいく(予定)。 REX-PCI33を搭載していないマシンで試した限りでは、insmod inic850w するとちゃんとエラーが出るようです(爆)。 まだ体調も悪いし、ちょっと忙しいので、実はまだREX-PCI33をセットアップして実験してはいないのです。 だってお蔵入りになってるのを取り付け直すのが面倒なんだもん(^^;。

というわけで、そのうち実験するつもりですが、くれぐれもこんなデタラメなパッチを試してみたりしないように。 Cのスキル、ドライバ周りのノウハウなんて、私はまったく持ち合わせていませんので、何が起こるか分かりませんぞ。

9月9日、追記。

ようやくREX-PCI33をセットして実験してみたところ、9月2日のパッチでは「dev_idを指定しろ！」と怒られてしまうようです。 それでも一応SCSIディスクから起動できたのですが、しばらく使っていたら kernel panic でハングしてしまいました(いい加減パッチのせいかどうかはわかりませんが)。

== 中略 == 

inic850: Total Adapters = 1
Bad boy: inic850 (at 0xc680057b) called us without a dev_id!
scsi0 : INIC-850 chip SCSI device driver; Revision: 0.80ok1
scsi : 1 host.
  Vendor: IBM       Model: DCAS-34330W       Rev: S61A
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 1, lun 0
SCSI device sda: hdwr sector= 512 bytes. Sectors= 8467200 [4134 MB] [4.1 GB]
Partition check:
 sda: sda1 sda2 sda3
scsi : 1 host.
== 中略 ==

ブート時のエラーメッセージについては、ドライバやカーネルのソースをみてみるとどうやらinic850.cの中でデバイスを初期化するときのrequest_irqの引数に問題があるみたいですね。 というわけでパッチを変更しました(0.80ok2)。

今度はしばらく動かしてみたり、bonnie++とかディスクベンチで負荷を長時間かけても特にハングする気配はないみたいですが、果たしてこれで大丈夫かどうかは保証しかねます(^^;。

10月7日、追記。
気が付いたら2.2系カーネルでコンパイルできなくなってた(^^;。修正しました(0.80ok3)

XFree86でGeForce2（2000.7.29）

このたびnVIDIA GeForce2 GTSを搭載した、Guillemot / Hercules 3D PROPHET II GTSを購入したのですが、あれ？このチップはまだXFree86では対応してないのね。 nVIDIAって最近はLinuxにも力を入れてて、XFree86-3.3系、4.0系のドライバを公開してるぐらいだから、てっきりOKかと思ってたっす(8月19日の追記参照。nVidiaが公開しているドライバはGeForce2に対応しているようですね)。

XFree86-3.3.6では画面が崩れまくってるし、4.0.1ではXFree86添付のnvドライバ、nVIDIAが公開している4.0.1用ドライバ(Build094)のどちらでも「対応チップじゃない」とされてXが上がりませんでした。 しっかし、GeForce2って先代のGeForce256とそんなに違うチップか？ 3D関係はともかく、2D描画はハード的にもほとんど同じだろうに。 とすれば、チップを認識さえさせちゃえば、後はGeForce256と同じで動くかもしれないなぁ(でも3.3.6では画面が崩れてダメだったからイマイチ自信は持てないけど)。

== 中略 == 

(II) NV: driver for NVIDIA chipsets: RIVA128, RIVATNT, RIVATNT2,
        RIVATNT2 (Ultra), RIVATNT2 (Vanta), RIVATNT2 M64,
        RIVATNT2 (Integrated), GeForce 256, GeForce DDR, Quadro
(EE) No devices detected.

Fatal server error:
no screens found
== 中略 ==

というわけで、XFree86-4.0.1にGeForce2のデバイスID(0150)を追加するいい加減なパッチをあてて、GeForce2を認識できるようにしてみました。 xc/programs/Xserver/hw/xfree86/drivers/nv/、xc/programs/Xserver/hw/xfree86/etc、でそれぞれ一度make cleanしてから、makeし直したバイナリをインストール。 さて、startx。

お、とりあえずXが上がったぞ。 Xからコンソールに戻るとやけに文字が薄くなるとか、ちょっと不具合もあるけど、動かないよりはずっとマシです(文字が薄くなるのはカーネルを2.4.0-test6にしたら直った)。 nVIDIAかXFree86が正式にGeForce2をサポートするまで待たなきゃいけないかと思ったけど、こんなんでとりあえず動けばラッキーですね。 それにしても、やっぱりまだまだLinuxでは最新ハードはやめといた方がいいみたいね(つい先日SCSIカードでハマッたくせに懲りないヤツ)。

== 中略 == 

(II) NV: driver for NVIDIA chipsets: RIVA128, RIVATNT, RIVATNT2,
        RIVATNT2 (Ultra), RIVATNT2 (Vanta), RIVATNT2 M64,
        RIVATNT2 (Integrated), GeForce 256, GeForce DDR, Quadro,
        GeForce2 GTS
(--) Assigning device section with no busID to primary device
(--) Chipset GeForce2 GTS found
== 中略 ==

というわけで強制的にXFree86-4.0.1に環境を移行しなければならなくなりました。 テストは何度かしてたんだけど、xfsとかフォント関係でうまくいってなかったんだよなぁ。 それに、まだnVIDIAのドライバがGeForce2にも2.4系カーネルにも対応してないから、GLXでハードウェアアクセラレートすることもできないし...。

8月5日、追記。
nVIDIAが公開しているドライバ(Build094)ではGeForce2に対応しているのかもしれません。 /var/log/XFree86.0.log をみると、GeForce 256やQuadroに続いて、GeForce2 GTSの文字が出てきます。 でも私の環境ではXがやっぱり立ち上がらないんだよなぁ。 私のパッチではGeForce 2 GTSになっていたので、GeForceと2の間のスペースを削除してみたけど、やっぱりダメっす。
== 中略 == 

(II) NVIDIA: NVIDIA driver for: RIVATNT, RIVATNT2, RIVATNT2 (Ultra),
        RIVATNT2 (Vanta), RIVATNT2 (M64), RIVATNT2 (Integrated), GeForce 256,
        GeForce DDR, Quadro, GeForce2 GTS, , , , , , 
(WW) NVIDIA: No matching Device section for instance (BusID PCI:1:0:0) found
(EE) No devices detected.

Fatal server error:
no screens found
== 中略 ==
8月19日、追記。

やっぱりnVIDIA謹製ドライバ(Build094)はGeForce2に対応してるようですね。 前回のエラーメッセージを見ると、どうやら「BusIDに関する記述がDevice sectionにない」と言ってるようだったので、書き加えてみました。 それにしても、AGPカードなんだからBusIDは1:0:0に決まってるような気もするが...。

( /etc/X11/XF86Config より抜粋) 

Section "Device"
        Identifier      "NVidia GeForce2 GTS"
        VendorName      "NVidia"
        BoardName       "NVidia GeForce2 GTS"
        BusID           "PCI:1:0:0"
        Driver          "nvidia"
#       VideoRam        32768
EndSection

むむぅ。まだダメですか。画面がブラックアウトしてしまう...。 もう一度 /var/log/XFree86.0.log をチェック。

== 中略 == 

(II) NVIDIA: NVIDIA driver for: RIVATNT, RIVATNT2, RIVATNT2 (Ultra),
        RIVATNT2 (Vanta), RIVATNT2 (M64), RIVATNT2 (Integrated), GeForce 256,
        GeForce DDR, Quadro, GeForce2 GTS, , , , , , 
(--) Chipset GeForce2 GTS found
== 中略 == 

(EE) NVIDIA(0): NVIDIA kernel module does not appear to be installed correctly!!
(EE) NVIDIA(0): Please refer to the FAQ for installation instructions.
(II) UnloadModule: "nvidia"
(II) UnloadModule: "vgahw"
(II) Unloading /usr/X11R6/lib/modules/libvgahw.a
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found
== 中略 ==

お、今度はGeForce2を認識してるようですね。 やっぱりBusIDの指定が必要だったようです。 ただ、NVidiaのドライバはカーネルモジュールもないとダメということですか。 う〜ん、現在のNVidiaドライバ(Build094)ではカーネル2.2系しかサポートしてないんだよね〜。 私の環境では、2.4.0-test5ではコンパイルできるがinsmodしようとするとエラー、2.4.0-test6ではコンパイルすらできず。 ぐぁ〜、2.2系に戻るか、NVidiaが対応するのを待つしかないか。 無念。

9月23日、追記。
nVIDIAが新しく公開したドライバ(Build095)では問題なく動くようになりました。 今までの苦労は何だったのかなぁ。

DU3160も何とかOK（2000.5.27, (6.3改訂)）

前回の最後に書いた、「IwillのSIDE-DU3160で、CD-ROM(PIONEER DU-506S)を接続するとLinuxが起動不能になってしまう」問題ですが、何とか解決できました。

DU3160のドライバについては、IwillのサイトかDU3160に載っているISP12160Aのベンダー、QLogic社のサイトからダウンロードが可能です。 が、何故かQLogic社のサイトではバージョン2.08のドライバならソースもあるのですが、最新の3.07はRedhat用のバイナリしかありません。 で、私の場合は2.3.99-pre8に含まれていたバージョン3.0のドライバを使っていたわけです。

どうも今回のトラブルは、ターミネーションの設定も問題なさそうだし、IDのコンフリクトもない。 でも起動時に、HDD、MOとスムーズに認識された後、エラーが出て、timeout → retry → timeoutというループに入ってしまう。 どうもSCSIカードのファームウェア又はドライバの問題が疑われるところです(まぁCD-ROM側のファームウェアの問題かもしれませんが、以前のTekram DC390Fではまともに動いてましたし、DU3160でもファームウェアのアップデート後はWindowsでは一応動作してます)。 とはいえ最新のドライバ3.07はバイナリしか公開されてないし、どうしたものでしょうか(Linuxのドライバはカーネルのバージョンに依存します)。

LinuxカーネルIwill / QLogic
2.08-ソース＆バイナリ
3.02.3.99にソースあり-
3.07-Redhat 6.1/6.2用バイナリのみ

というわけで、CD-ROMを殺しておいて、Linuxを起動。 ドライバのソース ( /usr/src/linux/drivers/scsi/qla1280.c等 )をつらつらと眺めてみました。 qla1280.c では、デフォルトでは有効にされていませんが、いくつかオプションが指定できるようです。 起動失敗時のエラーメッセージから判断すると、SCSIカードが出した何かのコマンドに対して、CD-ROMが反応できていないっぽいので、それらしいオプションを指定してコンパイルしてみることにしました。

(6月3日、加筆修正)

5月27日時点では、linux/drivers/scsi/qla1280.c の中で、

というオプションを有効にして実験していました。 確かにこれで起動はできたのですが、10分ほど使ってると、device I/O errorとか出てきて、動作がどんどん危険な雰囲気をかもしだすという状態になってしまいました。 dmesgで出てくるメッセージからソースを追うと、起動時のretryループから抜け出すだけならAUTO_ESCALATE_RESETを有効にするだけで充分(上のリストの赤字)なようです。 ドライバであんまり適当なことをすると、ファイルシステムを壊したりしかねませんから、その他のオプションは触らない方が安全ですね。 最近私はカーネルもRPM化して管理しているので、AUTO_ESCALATE_RESETを有効にするパッチを作って specファイルに加えています。

(dmesgから抜粋) 

scsi(0): Determining if RISC is loaded...
scsi(0): Verifying chip...
scsi(0): Setup chip...
scsi(0): Configure NVRAM parameters...
scsi(0): Resetting SCSI BUS (0)
scsi(0): Resetting SCSI BUS (1)
scsi0 : QLogic QLA12160 PCI to SCSI Host Adapter: bus 0 device 9 irq 10
       Firmware version: 10.01.19, Driver version  3.00-Beta.ok1
scsi : 1 host.
  Vendor: IBM       Model: DDRS-34560W       Rev: S97B
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
  Vendor: FUJITSU   Model: M2513A            Rev: 1500
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi removable disk sdb at scsi0, channel 0, id 4, lun 0

scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 5, lun 0 0x00 00 00 00 00 00 
scsi(0): ABORT Command=0xc132a400, handle=0x1
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
scsi(): Resetting Cmnd=0xc132a400, Handle=0x1, flags=0x2
qla1280(0):Have already attempted to reach device with abort device
qla1280(0):message, will escalate to BUS RESET.
qla1280(0:0:5:0): Issuing BUS DEVICE RESET.

scsi(0): Resetting SCSI BUS (0)
  Vendor: PIONEER   Model: CD-ROM DR-U06S    Rev: 1.05
  Type:   CD-ROM                             ANSI SCSI revision: 02
  Vendor: QUANTUM   Model: ATLAS_V_18_WLS    Rev: 0200
  Type:   Direct-Access                      ANSI SCSI revision: 03
Detected scsi disk sdc at scsi0, channel 1, id 0, lun 0
scsi(0:0:0:0): Enabled tagged queuing, queue depth 255.
scsi(0:0:0:0): Synchronous tranfer at period 9, offset 24. 
scsi(0:0:4:0): Synchronous tranfer at period 9, offset 24. 
scsi(0:0:5:0): Synchronous tranfer at period 9, offset 0. 
scsi(0:1:0:0): Enabled tagged queuing, queue depth 255.
scsi(0:1:0:0): Synchronous tranfer at period 9, offset 24. 
scsi(0:1:0:0): Dual Transition enabled.
(以下、省略)

やっぱりCD-ROMのとこで、なんかメッセージが出てるけど、一応起動できたし、CD-ROMもマウントして中身を見ることができました。 あー、このオプションがきちんと実装されてたおかげで助かった。

(6月3日、加筆)

ブート時にAlt+Qを押してSCSI BIOS(Fast!Util)を立ち上げ、以下の設定を変更すると、上のdmesgで黒字で書いた警告メッセージも回避できます(これをやればLinuxカーネルに添付のドライバに触らずとも起動できるかも？)。

マニュアルによれば、Sync Period はデフォルトの9は転送速度160MB/s(Ultra160)用の値で、10が80MB/s(Ultra2)、12が40MB/s(Ultra Wide)、25が20MB/s(Ultra, Fast WIDE)、40が12.5MB/s用だということです。 そもそもSCSI BIOSの設定をAutoにしておくと、パフォーマンス重視のセッティングになるので、一部の古い機器では問題が起こることがあるらしい。

でも、私のCD-ROM(PIONEER DR-506S)より古くて転送速度も遅いMO(富士通 M2513A)は問題なく動いてるんだけどな〜。 何か釈然としないものが残りますが、まぁこんなこともあるということで。

その他にも、SCSI-1のデバイス等で問題が発生したときには、

  1. "Negotiate Wide" を Yes から No
  2. "Negotiate Synchrounous" を Yes から No
  3. "Check Parity" を Yes から No
  4. "Enable LUNs" を Yes から No
  5. "Disconnects OK" を Yes から No

の順に、一つずつオプションを変更してくれ、とマニュアルに書いてあります。 ちなみに私の場合は、NarrowのデバイスであるMO、CD-ROMはそれぞれAuto設定でNegotiate WIDEはNoになりました(当然か)。 その他の設定はデフォルトのまま触らずに動作してます。

9月23日、追記。
QLogicのサイトからバージョン3.12のドライバがソースも含めて公開されました。 ファームウェアがアップデートされてる他、2.3系列への対応がすすめられたようです。

Linuxの大移動（2000.5.20）

先日、SCSIカードをTekram DC390FからIwill DU3160にリプレースした私ですが、ハードディスクの構成も変わるし、そもそも容量が豊富で高速な新しいドライブにLinuxも持っていきたい。 というわけで、DU3160用のSCSIドライバに対応＆Linux領域の大移動を行うことにしました。 まず、SCSIドライバをDC390Fで使っていたsym53cxxから、DU3160用のqla1280ドライバに変更しないといけません。 ALL SCSIだからroot deviceもSCSIなんでちょっと面倒だけど、再インストールしちゃうのも芸が無いよね(実はDU3160がKondara-1.1でインストール時にうまく認識されるかちょっと不安だし)。

当然、SCSIカードはDC390Fの状態でまずはLinuxを起動しといて、次回からはDU3160で起動できるようにしときます。

ここまできたらshutdownして電源を落として、コンセントも抜いてSCSIカードをリプレース。 さらに、新しいハードディスクを追加(従来の機器はとりあえずそのまま残す)。

おりゃ！

というわけで、無事に起動できたら、

この際、cpではなくtarを使うのがいいらしい(パーミッションとかタイプスタンプとかの関係かな？cpにもいろいろオプションがあった気もするが...)。

コピーが終了したら、
# chroot /mnt/tmp
して、うまく動くか念のため確認しとこう。

最後に、SCSIのデバイス構成を最終的な姿に変更するので、それに合わせて、/etc/fstabとかを変更。 電源を落として、実際にデバイス構成を変更してもう一度電源ON！ うまくいけばこれでOKです。 よしよし、珍しくスムーズに事が運んだっす。 やっぱ事前に勉強しといたのが功を奏したね。

でも、CD-ROMを繋ぐとLinuxが起動不能になっちまうという予期せぬトラブル(物欲の記参照)はくらってますけどね(^^;。 とりあえず私のSCSIカードのベンダーであるIwillか、チップベンダーのQLogicが出してるドライバで実験してみるかなぁ。

補足1 :
Dr. Kからまたまたコメントを頂きました。
cpのオプションですが、"-a"オプションを使うと同等のことができます。 で、tarの場合ですが、この場合はオプションに"p"をつけた方が良いでしょう。 "p"は"permition"の"p"です。これをつけてないと、permitionが変わってしまうことがあります。 特に "777" のようなOtherに対するfull許可は"775"くらいに減少されてしまいます
だそうです。毎度ありがとう。というわけで、上の例でもtarのオプションにpを付加しました。

Cのお勉強 その2（2000.5.13）

前回に引き続き、Cの勉強をば。

前回はオプションを解釈するところまで行ったので、次は実際にswapを有効／無効にする、mtrrを設定／解除する動作を作りたいですね。 スワップの方は難しそうなんで、今回はMTRRの方を試してみよう。

MTRRの設定を解除する

「MTRRの設定解除」では "disable=1"を、/proc/mtrrに書込みたいわけです。 こんな感じで、disable_mtrr関数を作ってみました。 まず、ファイルを読み書きするために、FILE型変数(fPath)を宣言、関数内で使用する整数型変数(reg, chk)を定義します。 それから、/proc/mtrrがあるかどうかチェック(check_mtrr)し、OKであれば、/proc/mtrrを書き込みモードで開き、"disable=1"という文字列を/proc/mtrrに書き込みます。 


(mainの前に定義を追加)

#define STRMAX 256
#define THISAPP "vfatswap"
#define DEBUG 1

char MtrrConf[] = "/etc/mtrr.conf";
char MtrrPath[] = "/proc/mtrr";
char MtrrSet[] = "write-combining";

(後はほとんど同じで、以下を追加)

/*
******* disabling mtrr *******
 */
int disable_mtrr() {
  FILE *fPath;
  int chk;
  int reg = 1;

/* checking /proc/mtrr */
  chk = check_mtrr();
  if (chk == FALSE) return FALSE;
  if ((fPath=fopen(MtrrPath,"w"))==NULL) {
    printf("%s : Cannot disable mtrr. Must be root.\n", THISAPP);
    return FALSE;
  }
  fprintf(fPath,"disable=%i\n",reg);
#ifdef DEBUG
  printf("disable mtrr : reg0%i\n",reg);
#endif
  fclose(fPath);
  return TRUE;
}

/*
 ******* check /proc/mtrr *******
 */
int check_mtrr() {
  FILE *f;

  if ((f=fopen(MtrrPath,"r"))==NULL) {
    printf("%s : Cannot enable mtrr. Kernel is not support mtrr.\n", THISAPP);
    return FALSE;
  } else {
    fclose(f);
    return TRUE;
  }
}

まず /proc/mtrrの有無をチェックする、check_mtrr関数ですが、

disable_mtrr関数では、

という流れです。

ちなみに#ifdef DEBUG の部分は、DEBUG が定義(最初の方にあるdefine)されている場合だけコンパイルされる部分です。 今は開発中なので、どのように動作しているか確認するためにこんな風に書いてみました。

MtrrPathに直接disable=1と書かずに、変数regを使ってるのは、後々の拡張を考えてです。 そもそもVGA用に設定するMTRRが必ずレジスタ1に入ってるとは限らないみたいなんで。

MTRRを設定する

次に、MTRRを設定する方ですが、/etc/mtrr.conf(MtrrConfとして定義)で指定されたパラメータを、/proc/mtrrに書込みます。 こんな感じで、enable_mtrr関数を作ってみました。 先ほどのdisable_mtrrと似通ってますが、MtrrConfを開いてパラメータを読みとる部分、その内容をもとにパラメータ文字列を/proc/mtrrに書き込む部分が違います。 


/*
******* enabling mtrr *******
 */
int enable_mtrr() {
  FILE *fPath, *fConf;
  int reg, chk;
  char opt_base[STRMAX], opt_addr[STRMAX];

/* checking /proc/mtrr */
  chk = check_mtrr();
  if (chk == FALSE) return FALSE;

/* read config file and set mtrr */
  if ((fConf=fopen(MtrrConf,"r"))==NULL) {
    printf("%s : Cannot enable mtrr. %s is not found.\n", THISAPP,MtrrConf);
    return FALSE;
  }
  fscanf(fConf,"%s %s", opt_base, opt_addr);
  fclose(fConf);

  if ((fPath=fopen(MtrrPath,"w"))==NULL) {
    printf("%s : Cannot enable mtrr. Must be root.\n", THISAPP);
    return FALSE;
  }
  fprintf(fPath,"base=%s size=%s type=%s\n",opt_base,opt_addr,MtrrSet);
#ifdef DEBUG
  printf("set mtrr : base=%s size=%s type=%s\n",opt_base,opt_addr,MtrrSet);
#endif
  fclose(fPath);
  return TRUE;
}
(今回のソース sample02.c)

enable_mtrr関数では、

という流れです。 例によってコンパイルして、実験してみましょう。 suでスーパーユーザになっておかないと、/procに書き込めません。

次は、swapファイルを有効／無効にする部分か。 こっちが面倒だなぁ。 system関数を使って、呼び出す方が楽そうだな...。 そんなの邪道か？

Cのお勉強 その1（2000.5.2）

かつて、領域不足に苦しんでいた私はスワップを専用パーティションではなく、ファイルに作ることを実験したことがありました(98年10月のLinux日記参照)。 その後、改良を重ねて /etc/rc.d/init.d に置くスクリプトを書いたり、ついでにMTRRの設定も可能なようにしたりしてました。

考えてみると、私がLinuxを使い始めて1年半ぐらいですか。 いろんなディストリを試したり、自作パッケージを作ったりしてきましたが、人のソフトをほんのちょっといじったりする程度で、本当に大した事をしてない(^^;。 そもそも何のためにLinuxを入れたんだっけ？

おお、そうだ。 ロハで手に入る開発環境に魅力を感じていたんだった。 仕事場ではMS Excelや各種統計ソフトのマクロを書いたりしてるけど、汎用的なプログラミング言語って最近ろくに触ってないんだよね。 今まで触ってきた言語といえば、昔なつかしのN88-BASICやZ-80アセンブラ。 後は大学でほんの少しPascal、入社後の研修でCOBOLやCのさわりぐらいか。 WindowsでVisual Cなんて揃えるとずいぶん高くつくし(最近は無償提供されている開発環境もあるみたいですが)、Linux入れてCの勉強をしたかったんだよなぁ。

というわけで、初心に返って勉強するため、シェルスクリプトだったvfatswapをCで書いてみることにしよう。 xmmsの3D Now!パッチを書いたりしてたから、少しはC言語がわかるぞ。 


#include <stdio.h>

int main() {
        printf("Hello, World\n");
}

...(^^;。 おいおい、これは書けるって言える範囲じゃないっつうの＜俺。 すんげぇ道は遠いな(^^;。 まぁこんな単純なソースですが、muleで作成し、hello.cという名前で保存。 コンパイル＆テストじゃ。 ちなみにGNU Cコンパイラで、ただgcc hello.cとするとa.outという名前でバイナリが作成される。 -o オプションは作成するバイナリの名前を指定するオプションなわけですな。

$ gcc hello.c -o hello
$ ./hello
Hello, World
$

こんな感じでメッセージが出力されればOK。 ちなみにprintfはダブルクォートで囲まれたメッセージを出力するコマンドで、\nは改行コードです。

まず、どこから手をつけますかね。 う〜ん、vfatswapは start / stop / status等のオプションを受けつけて、それぞれ違う動作をさせなければいけないから、まずはオプションの解釈をさせてみるかな。 


#include <stdio.h>
#include <string.h>

#define TRUE 0
#define FALSE 1

/*
******* Main routine *******
 */
int main(int argc, char **argv) {
  int option;

  option = read_option(argc, (char * const *)argv);

  switch (option) {
  case 1 :
    printf("start :\n");
    break;
  case 2 :
    printf("stop :\n");
    break;
  case 3 :
    printf("status :\n");
    break;
  case 4 :
    printf("restart :\n");
    break;
  default:
    printf("Usage: %s {start|stop|restart|status}\n",argv[0]);
    return FALSE;
  }

  return TRUE;
}

/*
******* read command line options *******
 */
int read_option(int argc, char * const *argv) {
  if (argc > 1) {

    /* start */
    if (strncmp(argv[1],"star",4) == TRUE)
      return 1;

    /* stop */
    if (strncmp(argv[1],"sto",3) == TRUE)
      return 2;

    /* status */
    if (strncmp(argv[1],"stat",4) == TRUE)
      return 3;

    /* restart */
    if (strncmp(argv[1],"r",1) == TRUE)
      return 4;
  }
  return 0;
}
(今回のソース sample01.c)

とさらっと書くと、すんなり進んだように思えるかもしれないけど、ここに辿り着くまでには結構苦労してます。 コンパイルエラーやSegmentation faultと戦いながら、何とかかんとか。

人の書いたプログラムをいろいろ読んでみると、どうやらmain関数のargcが整数型(int)の変数で「引数の数」、文字列型(char)変数のargvに「引数の内容」が格納されるみたいですね(補足1)。 ちなみに引数が指定されていないと、argcは1、argv[0]は実行プログラム名になる。 引数が一つ指定されると、argcは2、argv[0]は同じ、argv[1]に一つ目の引数が格納されるわけですね。

とりあえず、今していることは、

ってあたりまでですね。 実行するとこんな感じ。

$ gcc sample01.c -o sample01
$ ./sample01 start
start :
$ ./sample01 status
status :
$

printfのダブルクォートの囲みの中に%sと入れておいて、char変数を指定すると、変数の内容が%sの位置に出力されます。 mainのcase 0では、printf ("Usage %s ...", argv[0]); となってるので、実際にはこんな感じで結果が出てくるわけです。

$ ./sample01
Usage: ./sample01 {start|stop|restart|status}
$

ぐぁぁ、こんなことしかまだできぬ。 大体C言語の基本的な文法も知らないのに、本も読まずに勉強するというのは無謀か？ 先人の書いたソースを読んで、実験を繰り返して想像しながら作成してます。 こりゃ本当に道は遠いな。

ところで、どの言語でも同じ事をするのに、スマートな書き方で美しいソースも書けるし、強引にやっちまって汚いソースにもなるんですよね。 というわけで、私はCなぞろくに知らずにやってますから、間違いなく後者なわけです(^^;。 「ここはこういう風に書いた方がいいぞ」なんてご意見があればメールを下さい。

というわけで、長くなったので、次回に続く...(気力があれば)。

補足1 :
Dr. Kからのコメントによれば、「Cでは「文字列型変数」はありません。argvはこの場合、文字変数のポインタのポインタになっています。まぁ、実用上は君の理解でOKなのだが。」ということだそうです。な、なるほど。深いな。さんきゅーです。
補足2 :
同じくDr. Kからのコメントによれば、「switch文では最後はdefaultを入れておいた方がよいぞ。万が一、何かの不都合でread_optionが0-4以外の数を返してくるとまずいっしょ。」だそうです。これはごもっとも。defaultね、メモメモ。言い訳すると、私も他の言語では一応そうしてるつもりだったのだが、今回は慣れぬCで見逃しちまいました。

bzip2 : 0.9.5d vs 1.0pre7（2000.4.29）

bzip2は、Linuxでは最もポピュラーなgzipより高効率な、圧縮・解凍ユーティリティです。 まぁ、その分速度は劣っているわけですが、ファイルサイズが小さく出来るのはメリットが大きいので、最近ではいろんなサイトで、gzip圧縮とbzip2圧縮の両方を用意してダウンロードできるようにしている例が見受けられます。

bzip2もバージョンを上げるにつれて少しずつスピードアップが図られてきたようです。 最新の安定版は現在のところ0.9.5dですが、現在出ている1.0pre7では、圧縮速度が10〜25％高速化されたとコメントされてます。

ということで早速実験。 テストに使ったのはlinux-2.3.99-pre5.tar.bz2 (16,284,052 byte)。 init 3にし、不要なデーモンもできるだけ止めた上で、

# time bzip2 -z(またはd) linux-2.3.99-pre5.tar(.bz2)

で所要時間を計測しました。user timeの時間を表にしてみると以下のとおり。

0.9.5d1.0pre7
K6-III/504解凍29.7729.78
圧縮155.92128.46
PIII-500解凍29.2830.23
圧縮124.24103.70

正確を期するなら何回か計測した上で、異常値を除いて平均するとかした方が良いんでしょうが、面倒なんで1回で勘弁。 解凍では差は無いけど、圧縮では17％程度1.0pre7が早いようですね。 看板に偽りなしっちゅうことでなかなかグッドですな。 にしても、前から思ってたんだけどPentiumIIIとK6-IIIでは解凍には差が無いのに圧縮ではずいぶん違うよなぁ。 最適化オプションとかもう少しツメないとだめかな？ CPUが違ってもバージョンが違ってもほとんど同じというのは、別のところにボトルネックがあるのかも。

ちなみに両バージョンのバイナリはpgcc-2.95.3、最適化は-O6 -mk6(pentiumpro) -funroll-loops -ffast-math -fPIC -mmxで作成したshared版です。 staticの方が多分もう少しずつ早いんでしょうな。 pgccでは冗談で-mmxを付けてるけど、本当にMMX命令を使っているかは知らぬ。 計測環境はAMD K6-III/504及びIntel PentiumIII-500 / 128MB memです。

むぅこれじゃダメじゃん（2000.4.1）

先週XFree86-4.0を入れてから、いろいろ設定を試してます。 なかなかうまくないッスね。 特にGLXが期待外れ...。

X-TT

xf86configで作成したXF86Configは、X-TTを利用できる設定になっていません。 XFre86-4.0で統合されたTrueTypeフォント・レンダラはX-TTともう一つxfsttの２種類がありまして、xfsttの方を使うようになっているようです。 Moduleセクションの Load "freetype" を Load "xtt" に変更しないとX-TTが使えません。

GLX

同じく3Dアクセラレート対応のOpenGLライブラリ、GLXを有効にするには、Moduleセクションに Load "glx"、DRIを有効にするには Load "dri" を追加しないといけないみたいです。

また、OpenGL対応のアプリケーションは、libGLだけでなく、libGLUが必要で、libglutも使ってるものがあるみたいです。 それにアプリをビルドするには、GLU、glutのヘッダファイルも必要です。 XFree86-4.0にはこれらのファイルが無いので、Mesaのソースを入手してmakeして必要なファイルをインストールしましょう。 いきなりmake installすると、XFree86-4.0のlibGLや関連するヘッダファイルとぶつかりますんで、手動で以下のファイルだけコピーして、/sbin/ldconfig しました。 

libGLU.so*    -> /usr/X11R6/lib
libglut.so*   -> /usr/X11R6/lib

glu.h         -> /usr/X11R6/include/GL
glut.h        -> /usr/X11R6/include/GL

これで、イケるか？と思ったら、xscreensaverのgearsなんかをやってみても、全然アクセラレートが効いてねぇ。 XFree86のサイトを見に行ってみたら、Supported Hardwareの項目に、3dfx Voodoo3 / Banshee、3Dlabs Oxygen GMX2000しか書いてない...。 あ、そもそもカーネルのDRIサポートにもこの2つしかないじゃん。

がび〜ん。 XFree86-4.0でアクセラレートをがんがん使おう(何に？)という私の目論見はあっさり敗退しました。 XFree86-4.0に含まれているGLXは Precision Insight製で、私が以前テストしたUtah-GLXとは違うのね。 Utah-GLXではMatrox G200 / G400やATI RagePro、Intel i810、nVIDIA RIVA、S3 VIRGEあたりまで使えるんだけど、XFree86-4.0には今んとこ対応してないんだよね。

というわけで、XFree86を3.3.6に戻すか、4.0のままXかUtah-GLXのアップデートを待つしかないっつうのが今回の結論ですね。 どうしようかなぁ。 あ、でもMatrox自身が対応ドライバをリリースする可能性はあるかな。 そもそもXFree86-4.0がドライバを独立したモジュールにしたのは、ベンダーがドライバを供給しやすくすることが狙いだったはずだしね。

ちなみに私のXFree86-4.0用のXF86Config、XFree86-3.3.xで使ってたXF86Configはこんな感じです。 結構、細かいフォーマットが違うよね。

最新のX、最新のカーネル（2000.3.25）

2000年3月、ついにフリーのX Window System、XFree86からメジャー・バージョンアップとなるXFree86-4.0がリリースされました。 XFree86-4.0では、98年11月に実験したX-TT(この時は失敗したけど今は大抵のディストリにX-TT対応のXFree86が収録されてますね)、99年10月に実験したGLX等、様々な機能がXFree86本体に取り込まれました。 また、ドライバがダイナミック・ロードできるようになり、今までビデオカード毎にXサーバが分かれてたのもずいぶんとすっきりしました。 さらに、3Dハードウェアに直接アクセスするDirect Rendering Infrastructure(DRI)にも対応したので、3D描画が高速化されるようです。

XFree86-4.0はまだリリースされたばかりなので、当然ディストリからはまだ収録されたバージョンは出てきていません。 しかし、これだけおもしろそうな機能が満載なので、ぜひ試したい。 と思っていたら、私のLinuxの師匠、Dr. Kが早速実験して、nosrc.rpmも出してくれました。 これは私も続くしかない。

最新カーネルをゲット＆インストール

まずDRIを利用するためにはカーネル側のサポートも必要なので、次の安定カーネル直前版linux-2.3.99-pre2をインストールすることにしました。 ご存知のとおり奇数バージョンは開発版です。 以前に2.3.40前後のときに実験したら、initial RAM diskあたりのコードがおかしかったみたいですが、2.3.99は2.4リリース直前バージョンですからそろそろ実用段階に達しているでしょう。 適当なサイトからカーネルを落としてダウンロードして、makeしました。 カーネルmakeの経験がある人ならそれほど問題なくいけることと思いますが、当然自己責任ですんで、そこんとこヨロシク。 どっちにしてもカーネルのメジャー・バージョンアップですからDocumentを良く読んで、必要なものはアップグレードしときましょう(補足2)。

私の環境では、System V PCだかなんだかの部分でコケました(後のpre3では直ってました)が、ヘルプを見るとdosemuとかを使わなければ大丈夫そうだったんで無効にしてmakeしたら通りました。 あ、そういえばAGPサポートもカーネル本体に含まれてるし、USB系もずいぶんドライバが増えてますね。 まぁ次世代カーネルですからこれぐらいは当然か。

調子に乗って最適化フラグを-O6とかにしてpgccでmakeしたら見事にブッとびました。 まぁこれはカーネルのせいというよりは、pgccのせいでしょう。 今までにもGLXで-O3以上にしたり、-funroll-loopsとか入れてバイナリを吐かれた前例があることですし。

XFree86-4.0をゲット＆インストール

次は本命のXFree86-4.0です。 X400src-1.tgz, X400src-2.tgz, X400src-3.tgzの３つを落として、make Worldしましょう。 まぁDr. Kがnosrc.rpmを公開してくれてるし、自分でXをmakeしたことがある人ならなんとかなるでしょう。 言うまでも無く自己責任ですんで、失敗しても私やDr. Kに文句を言ったりしないように。

makeにはずいぶんと時間がかかりますし、容量も必要です。 多分600MBぐらいは空きがないと無理でしょう。

パッケージが出来上がったら、古いXFree86や、コンフリクトするX11R6-contrib, xpm-devel, xpmなんかをrpm -eで削除しておいて、rpm -ivh X* でインストールします。

実験、実験

というわけで実験です。 当然ですが、実験する前に、起動時からxdmを立ち上げてる人は /etc/inittab を変更して、デフォルト・ランレベルを3にして、コンソール・ログインにしときましょう。 Xがちゃんと動くことを確認してからでないとマズイかんね。

まずはXの設定ファイル、XF86Configを作らないといけません。 こいつはコンソールから、# xf86setupで質問に答えれば /etc/X11/XF86Config に自動出力されます。 フォーマットがXFree86-3.3.xとは少々変わってるんで、まずはxf86configに作らせた方が楽でしょう。

私は一応、質問にちゃんと答えたつもりなんだけど IntelliMouseがまともに動かなかったので、マウスのプロトコルを IntelliMouse から IMPS/2 に変更したら直りました。 ディスプレイの周波数なんかは入力が面倒だったんで、質問には適当に答えておいて、3.3.6のときのXF86Configからカット＆ペーストしました。

設定がうまくいってれば、$ startx で Xが立ち上がり、こんな感じで /var/log/XFree86.0.log にログが出てくるでしょう。 まぁこの辺は各自でトライ＆エラーするしかないよね。 Dr. Kのとこではフォント関係で問題が出て、3.3.xのライブラリと一部置き換えたりして対処したようですが、私のとこでは今んとこ問題ないっすね(補足1)。 ただXの起動時に少し時間がかかるようになりましたね。 フォントのglyph読込みの関係とかかなぁ。 もう少し設定を勉強せんとイカンね。 


XFree86 Version 4.0 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 8 March 2000
        If the server is older than 6-12 months, or if your card is newer
        than the above date, look for a newer version before reporting
        problems.  (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.3.99-pre2 i586 [ELF] 
Module Loader present
(==) Log file: "/var/log/XFree86.0.log", Time: Sat Mar 25 01:40:50 2000
(==) Using config file: "/etc/X11/XF86Config"
Markers: (--) probed, (**) from config file, (==) default setting,
         (++) from command line, (!!) notice, (II) informational,
         (WW) warning, (EE) error, (??) unknown.
(==) ServerLayout "Simple Layout"
(**) |-->Screen "Screen 1" (0)
(**) |   |-->Monitor "SONY GDM-19PS"
(**) |   |-->Device "Matrox Millennium G200 SD 16MB"
(**) |-->Input Device "Mouse1"
(**) |-->Input Device "Keyboard1"
(**) XKB: rules: "xfree86"
(**) XKB: model: "jp106"
(**) XKB: layout: "jp"
(以下、省略)
補足1 :
ウソウソ。そもそもxfontselとかで12ポイントしか選択できん。あと、時々日本語フォントの表示が崩れるような...。
あと動作には支障は無かったんですが、XFree86で shmがなんちゃらとかいうエラーが出てました。linux/Documentation/Changes に書いてあるようにmkdir /var/shm して、/etc/fstabに以下の行を追加すればOKなようです。Thanks ＞ Dr. K

none		/var/shm	shm		defaults	0 0
補足2 :
linux/Documentation/Changes あたりを読むと、私の環境(Kondara MNU/Linux 1.1)ではmodutils以外は大体大丈夫みたいですね。 modutilsもKondara収録の2.1.121でも一応動きましたが、念のためDocumentにしたがって2.3.10にアップグレードしました。

lm_sensorsでハードウェア・モニタ（2000.3.18）

最近のマザーにはLM78等のハードウェアを監視するチップが載っており、センサが読み取った温度やファンの回転速度、電圧等をBIOSやOSから見ることができます。 Linuxでもlm_sensorsというユーティリティを使用して、ハードウェア・モニタを行うことができます。

しかし、lm_sensorsのインストール方法は何種類かあり、結構複雑なようです。 lm_sensorsはi2cを利用しているのですが、現在の安定系カーネルではツリーに含まれているドライバが古いため、新しいものを使わなければいけません(2.3.38以降なら大丈夫らしい)。 で、カーネル本体にパッチをあてるか、別のところに新しく展開するか、どちらかが必要になります。 私はカーネルツリーを入れ替えると面倒そうなので後者を選びました。

ソースの入手

まずlm_sensorsのサイト等からソースを２種類ダウンロードします(現在の最新版は2.5.0でした。ちなみに2.0系カーネルはサポートされてません)。

インストール＆設定

  1. カーネル本体にパッチをあてない場合は、まずi2cを展開して make; make install、次にlm_sensorsを展開して make; make install するだけです。
  2. sensors-detect を使って、自分の使用しているハードウェアを確認します。私の環境では全ての質問に [Enter] を押しているだけで無事終了しました。
  3. 出てきたメッセージにしたがって設定を変更します。
    • /etc/conf.modules に alias char-major-89 i2c-devを追加
    • /etc/rc.d/rc.local に出力された modprobeコマンドを追加
  4. lm_sensorsを展開したディレクトリの prog/mkdev にある mkdev.sh を実行。
  5. 後はリブートするか、さっきのmodprobeコマンドを手動で入れればOK。

実行結果

以上で、sensorsコマンドが使えるようになります。 実行するとこんな感じで出力結果が出てきます。 あぁ、こんなの見てるとケースファンもセンサー付に変えたくなるなぁ。 


eeprom-i2c-0-50
Adapter: SMBus vt82c596 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Memory type:            SDRAM DIMM SPD
SDRAM Size (MB):        128

w83781d-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
VCore 1:   +2.30 V  (min =  +0.00 V, max =  +0.00 V)       ALARM  
VCore 2:   +2.32 V  (min =  +0.00 V, max =  +0.00 V)       ALARM  
+3.3V:     +3.52 V  (min =  +2.97 V, max =  +3.63 V)              
+5V:       +4.91 V  (min =  +4.50 V, max =  +5.48 V)              
+12V:     +12.08 V  (min = +10.79 V, max = +13.11 V)              
-12V:     -11.96 V  (min = -10.78 V, max = -13.18 V)              
-5V:       -5.06 V  (min =  -4.50 V, max =  -5.48 V)              
fan1:        0 RPM  (min = 3000 RPM, div = 2)              ALARM  
fan2:        0 RPM  (min = 3000 RPM, div = 2)              ALARM  
fan3:        0 RPM  (min = 3000 RPM, div = 2)              ALARM  
temp1:    +22 C   (limit = +60 C, hysteresis = +50 C)        
temp2:    +28.5 C   (limit = +60.0 C, hysteresis = +50.0 C)        
temp3:    +26.5 C   (limit = +60.0 C, hysteresis = +50.0 C)        
vid:      +0.00 V
alarms:   Chassis intrusion detection                             
beep_enable:
          Sound alarm disabled

lm_sensors自体はコンソールアプリですが、GNOMEアプレットやらWindow MakerのDock AppやらのGUIフロントエンドはいろいろあります。 freshmeatで検索してもいろいろ出てきますね。

Return to Previous page一つ前のページに戻る / Return to topこのページのTOPに戻る