Linux日記: 2001年
XFree86でRADEON8500 (2001.11.23)
というわけで購入してしまったRADEON 8500LEですが、現在の最新版XFree86-4.1.0では対応していません。 以前GeForce2を買った当時もそうでしたが最新チップはすぐには対応できないんですよね。 ベンダー側もWindowsドライバは自分で開発してカードに添付しますけど、Linux対応はまだそこまではいってません。 XFree86-4.xからはnVIDIAのように自前でクローズドなドライバを開発して配布している例もありますが、ATIではそのようなことはしていません。 とはいえ、Linuxを無視しているわけでもなく、むしろXFree86サイドに情報提供したり、パッチを送付したりしているようですから、ATIの方が好ましい姿勢だと思いますが。
それはさておき、まずは何とか自分の環境でXが使えるようにしたいところです。 まずは従来のドライバに新しいチップを認識さえさせれば動く可能性が考えられます。 GeForce2でもそうでした。 というわけで、例によって xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h とか xc/programs/Xserver/hw/xfree86/drivers/ati にあるドライバのソースに、RADEON8500のエントリとIDを追加してみました。 が、ダメでした。 startxすると画面がブラックアウトしたまま返ってきません。 強制リセットするしかなくなり、XFree86.0.logも壊れてしまって読めませんでした。
次に、まだリリースされていないだけで開発中のソースには取り込まれている可能性が考えられます。 というわけで、XFree86のcvsを見に行ってみたら、やっぱりありました。
XFree86 4.1.99.2 (xx October 2001)
(snip)
283. Support Radeon 7500, 8500 and Rage128ProII (#4941, ATI Technologies).
cvsのソースを丸ごと落とすのもなんですし、XFree86のCVS Repositoryから、xf86PciInfo.hとdrivers/ati以下の関係しそうなソースだけ落としてきて、XFree86-4.1.0にバックポートしてみることにしました。
で、xf86PciInfo.hはRADEON 8500/7500のエントリを追加した部分以外は4.1.0オリジナルに戻します(nVIDIAのTNT2関係のエントリが変更されたりしてるので)。 それから、drivers/atiではIOADDRESSを4.1.0と同じ名前に戻しました。 で、再びmake。 あ〜んど、startx。
== 中略 ==
(II) ATI: ATI driver (version 6.4.6) for chipsets: ati, ativga (II) R128: Driver for ATI Rage 128 chipsets: ATI Rage 128 RE (PCI), ATI Rage 128 RF (AGP), ATI Rage 128 RG (AGP), ATI Rage 128 RK (PCI), ATI Rage 128 RL (AGP), ATI Rage 128 Pro PD (PCI), ATI Rage 128 Pro PF (AGP), ATI Rage 128 Mobility LE (PCI), ATI Rage 128 Mobility LF (AGP), ATI Rage 128 Mobility MF (AGP), ATI Rage 128 Mobility ML (AGP) (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI Radeon VE QY (AGP), ATI Radeon VE QZ (AGP), ATI Radeon Mobility LW (AGP), ATI Radeon Mobility LY (AGP), ATI Radeon Mobility LZ (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 7500 QW (AGP) (--) Chipset ATI Radeon 8500 QL (AGP) found Symbol drmRadeonResetCP from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol drmRadeonStartCP from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved!== 中略 == Fatal server error: Caught signal 4. Server aborting |
う〜む、認識はうまくいったようですが、DRI/DRM関連でエラーが出まくってXはまたもや起動できませんでした。 ハングアップしないだけマシですが、省略したけど100個以上unresolved symbolが出てる...。 DRI周りのコードも4.1.0と現在のcvsでは互換性がないんでしょうね。 そりゃ4.1.99は次期リリース4.2.0のもので、バージョンの上がり方からして仕方がないところですか。 ソースを見てみても、こりゃバックポートするのは私のスキルではかなり厳しそうです。
となればXFree86-4.1を捨てて全面的にcvsに移行するか、4.2.0リリースまで待つしか手がないですか。
4.2.0, which is scheduled for mid-late November 2001.
だそうですが。
というわけでもはや他に打つ手なし、ということでcvsに移行。 最初はagccで -O3 -march=athlon -mcpu=athlon とかでmakeしたらめちゃくちゃ不安定でフリーズしまくり。 -O2 -march=pentium -mcpu=pentiumでは何とかいけました。 だけど、galeonやmozilla、gnumeric等を立ち上げるとXが死んでしまいます(^^;。 ブラウザはw3m + インライン画像表示パッチで頑張るか。
- (11/24追記) どうやらgaleonやmozilla、gnumericが死ぬのは、アプリのせいではないようだ。TrueTypeフォントを使おうとするだけでXが落ちてしまう(xfontselでkochiを選択しただけで(ToT))。 むむぅ、どうしたものだろう。 しばらくTrueTypeフォントなしで生きていくしかないか。 xttじゃなくてfreetypeで2バイト文字って通るんだっけ？
LinuxでもTV(2001.9.1)(9.15追記)
先般、「物欲の記」PCでTVを見ようでも紹介したとおり、AOpenの低価格TVチューナーカード、VA1000を購入し、いろいろ面倒なことにはなりましたが、何とかWindows上では利用することができるようになりました。
VA1000はこのクラスのTVチューナー＆キャプチャーカードでは一般的なConexant Bt878チップを搭載したものです。 Bt8x8シリーズはLinuxでもドライバがあるので結構みなさん動かしているみたいです。 となると、早速実験してみなくてはならんでしょう。
まずは、bttvのサイトから、Btシリーズのチップ用ドライバを落としてきて、インストール。
私はカーネルも私製RPMパッケージにしてるので、カーネルへのパッチの方を落としました(現時点ではカーネル2.4.9用のバージョン0.7.76のドライバが最新のようです)。
セットアップ等の詳細はREADMEを参照。 一応、私がやったのはこんな感じ。
- カーネルのセットアップ
ちなみにカーネルは、I2Cサポート関連のオプション(CONFIG_I2C、CONFIG_I2C_ALGOBIT)とVideo4Linuxサポート(CONFIG_VIDEO_DEV=m)がmで構築されている必要があります。 これらのオプションがONになっていないと、Video4Linuxの中のBt848モジュールがメニューに出てきません。 また、カーネル2.2系の方はi2c関連もアップデートしないとイカンらしいです。 - デバイスファイルの作成
カーネルへのパッチ適用後なら、/usr/src/linux/Documentation/video4linux/bttv にMAKEDEVがあります。# sh MAKEDEV でもしてデバイスファイルを作成しておきましょう。 - /etc/modules.conf に記述を追加
# i2c alias char-major-89 i2c-dev # bttv alias char-major-81 videodev alias char-major-81-0 bttv options bttv card=0 radio=1 options tuner type=2
こんな感じ。
で、次はTVを見るアプリケーション。 代表的なとこでは、XawTVでしょうか。 こいつはHomeディレクトリに、.xawtvみたいな設定ファイルを置いておけば問題ないでしょう。 日本用にNTSCモードにするほか、東京ローカルのチャンネル設定、ショートカットキーも定義してあります。
早速XawTVを立ち上げると、おぉ！確かにTVが見れるようになりました。 キーボードやマウスでチャンネルも切り替えられます。 が、音が出ない...。 bttvのソースファイル中のSound-FAQを見ても、TVを見るだけならBtシリーズのチップがやってるのでどのベンダーのカードでも結構共通でいけるのですが、サウンドまわりは違いが結構あるので大変みたいです。
dmesgでみると、bttvモジュールがカードの自動認識やサブモジュールのロードをしてくれてますが、それが正しいとは限らないし、そもそも認識に失敗してる場合もあります。 で、CARDLISTに対応カードが列挙されているので、自分のカードがリストにあれば、 # insmod bttv card=2 とか番号を入れれば良いみたいですが、リストにのっていない場合は、適当に番号を入れまくって試行錯誤するしかないみたいです。 カードによっては外部チップを使っている場合もあり、サブモジュールもロードしないといけないらしい。 Insmod-optionsをみても、モジュールにはいっぱいオプションがありますし、こりゃ面倒ですな。
結局、いろいろ試行錯誤したけど、音が出ずじまい。 そのうち気が向いたらまた試してみるかもしれません。 うまくいけば、引き続きTVのMPEG録画などまでやってみたいけどね。
(9/15追記)
/etc/modules.conf の options bttvの行を以下のように変更すればVA1000でも音が出るようになります。
元ネタは [linux-users:85352]の斉藤さんのレポートです。
ありがとうございました。
| options bttv bttv_gpio=1 audiomux=2,0,0,0 |
nVIDIAカードでFSAA on Linux(2001.6.2)
先日、nVIDIAからXFree86-4.0.x用の新しいドライバ1.0-1251がリリースされました。 早速、私も使ってますが、X起動時にnVIDIAロゴが出るようになった以外は、さっぱり違いが分からずにいました。
実はKT266搭載のマザーに換装してから、nVIDIAドライバがAGPを使ってくれなくなったので、新しいドライバに期待してたんですけどね(nVIDIAドライバはカーネル添付のAGPドライバではなく自分でアクセスします)。
それはさておき、Evil3Dというサイトでおもしろい記事を見つけました。 NVIDIA & FSAA in Linuxという記事で、どうやら1.0-1251ドライバは非公式にサポートしていて、環境変数 __GL_FSAA_MODEを設定することによりFSAAが利用できるようです。
| n | GeForce256/2 | GeForce3 |
|---|---|---|
| 0 | - | - |
| 1 | - | 2x2 |
| 2 | - | 2x2 Quincunx |
| 3 | 1.5x1.5 | - |
| 4 | 2x2 | 4x4 Bilinear |
| 5 | - | 4x4 Gaussian |
FSAAというのは、ご存知のことと思いますが、フル・シーン・アンチ・エイリアスの略で、低解像度で3Dオブジェクトに出てしまうギザギザをなめらかに表示する技術です。 それをどのように実現するかにいくつか方法があって、それを環境変数で指定できるというわけです。
早速、実験...。 と思ったら、LinuxでOpenGLを使ったゲームなんて、今持ってないっす(^^;。 OpenGL使ったDoomとかがフリーでどっかにあった気がするな〜。
というわけで、今回は未遂に終わりました(爆)。 すみません。 ちなみにEvil3DのサイトにはNVClockというユーティリティもありますね〜。 こっちも実験しなくちゃ。
Advanced Sound Daemonを試す (2001.4.21)
私がいつもウォッチしているfreshmeatに、最近Advanced Sound Daemonというものがあらわれました。
Linuxの多くのディストリで広く採用されているGNOMEでは、メニューのポップアップやアプリの起動、終了に効果音を割り付けることができます。 ところが、そのままだと例えばxmmsでMP3を演奏中には、他のアプリが音を出せなくなってしまいます。 で、いろいろなプログラムが音を出そうとするのを調停して、ミキシングする仕組みが必要になるわけです。 GNOMEではEsounDというミキシング・デーモンが使われていて、これはもともとEnlightenmentというWindowマネージャ用に開発されたものなわけです。
今回とりあげるASDは、このEsounDの上位互換として開発されているもので、さらに多くの機能が備わっている(まだ実装されてないのもあるようだけど)おり、最終的にはEsounDを完全に代替することを目指しているようです。
ASDのホームページによれば、EsounDはシングルスレッドのシンプルなデーモンなので、音の遅延が発生したりするけど、ASDなら大丈夫。
レイテンシが低いからゲームにだって使えるぜ
ってことだそうです(注：私の勝手な意訳)。
というわけで早速実験。 現在の最新版は、asd3-20010416.tar.gz、ソースを落として展開したら make するだけです。 configure等には対応してないので、場合によっては Makefile の修正が必要になるかもね。 開発中のアルファ版なためか、Makefileにはinstallのエントリすらありません。 まぁ実験するだけなら、これでも充分なわけですが。
というわけで、makeが終了したら、daemonディレクトリにあるasdを実行しましょう。
# daemon/asd &
デーモンをバックグラウンドで動かしたら、次に何かアプリで音を出してみますか。
READMEによれば、mpg123で以下のようにやれば良いようです(foo.mp3は適当なMP3ファイル)。
# mpg123 -s foo.mp3 | utils/asdcat
う〜む、確かに音は出るけど、ちょっと変。 まるで早回しにしたレコードみたい(^^;(まぁこれはasd側のせいじゃないかもね)。
ちなみにASDには専用のxmmsのプラグインが入っています。 試しにxmmsディレクトリに出来上がっていた、libasdplugin.soをxmmsのOutputプラグインのディレクトリに放り込んで、xmmsからMP3を再生してみた。 ...。 お、今度はちゃんと再生されてます。
じゃあ今度はxmmsを演奏しながら、mpg123もやってみよう。 ...。 ちゃんとミキシングもされてるようですね。
さらに、ドキュメントをつらつら眺めていると、asdはデフォルトで 0.0.0.0:4711 を通 してアクセスできるようになっているようですね。 環境変数ASDSPEAKERを export ASDSPEAKER=0.0.0.0:4711 みたいに設定すれば、EsounD同様、別のマシンのASDからremoteで音を出したりできるんでしょうね。
まぁまだアルファということで、実装されてない機能もあるし、プチプチとノイズが入る時があったり、不具合もあるようですが(4月16日の前の4月8日版で実験したときは音が何も出なかったし)、今後が期待されますね。 順調に開発が進んで、将来はGNOME側でも対応してくれると面白いなぁ。 でもGNOMEってコマンドラインでEsounDを叩いてるわけじゃなくて、ライブラリ経由だったよね？ ASDもEsounD互換のライブラリにしないと難しいかな。 とりあえず適当にでっちあげたソースRPMをパッケージ置き場においておきますので、試したい方はどうぞ。
まぜまぜ野郎の真髄 (2001.4.7)
私はオリジナルディストリを作るにあたって、Kondara Jirai、Rawhide(Red Hatの開発版)、Mandrake Cooker等のディストリのスナップショットを利用させてもらっています。 もちろんそれぞれのディストリでパッケージ構成が異なりますし、ソースRPMで持ってきて、自分の環境に合わせて修正しつつbuildして利用しているわけです。
私の利用しているRPMパッケージはKondaraのものをベースにしています。 現在、Kondaraは3.0系、RawhideやCookerは4.0系のRPMを採用していますが、KondaraのRPMは4.0系のファイルもサポートしてますので、src.rpmなら問題なく読み込むことができます。
しかしながら、同じRPMであっても設定は微妙に異なっています。 例えば、Kondaraでは、/etc/init.d を %_initscriptdir に登録していますが、RawhideやCookerでは %_initrddir になっています。 また、KondaraとRawhideには大きな違いはありませんが、Cookerは結構独特のマクロを登録しています。 そのため、Kondara環境でCookerのsrc.rpmをそのままrebuildしようとするとエラーが出てしまうわけです。
これらの違いはspecファイルを手で修正しても良いのですが、私はこんなマクロを登録しています。
|
( ~/.rpmmacros ) == 中略 ==
%_make_bin make
%make if [ -z "$NPROCS" -a -f /proc/stat ]; then NPROCS=`egrep -c ^cpu[0-9]+ /proc/stat || :`;fi \
if [ -z "$NPROCS" -o "$NPROCS" -le "0" ]; then \
NPROCS=1 \
fi \
%{_make_bin} -j$NPROCS
# Menu directories
%_menudir %{_libdir}/menu
%_iconsdir %{_datadir}/icons
%_miconsdir %{_datadir}/icons/mini
%_liconsdir %{_datadir}/icons/large
# Games macros
%_gamesdir games
%_gamesbindir %{_prefix}/%{_gamesdir}
%_gamesdatadir %{_datadir}/%{_gamesdir}
#add compatibilities for Red Hat
%_initrddir /etc/init.d
|
例えば、Cookerでは、specファイルの中で makeとする代わりに %make を使っています。 これは複数のCPUを搭載したシステムで効率よくmakeするために、makeのオプションを自動設定してくれるマクロです。 さらにおバカな私はRPM自体にパッチをあてて、.rpmmacrosにいちいち登録しなくてもイケるようにしています。
まぁ、いろんなディストリや自作パッケージをまぜまぜするようなマネは、どこのディストリも当然サポートしてくれません。 不具合が出ても、自分で原因を探して解決しなくてはなりません。 面倒ではありますが、それもまたパズルみたいなもので、解決するまでのプロセスを楽しむ姿勢が必要でしょう(^^;。
liloでグラフィカルなロゴを出そう (2001.3.24)
先日、Linux Magazineに付録で付いていたFisher(RedHat 7.1のβ)を試してみたのですが、LILOの起動画面がグラフィカルになってました。 おぉ、これはなかなか渋い(右側の白いボックスにdosとかlinux等、ブートの選択肢が出ます)。
早速Rawhideからlilo-21.4.4-13.src.rpmを落としてみたところ、オリジナルのliloにRedHatがパッチをあてて、ブート時に画像を表示できるようにしてるみたいですね。 lilo.confに message=/boot/message とか書いておくと表示してくれ、実体はpcxフォーマットのイメージファイルのようです。 これは早速実験でしょう。
ちなみに画像の大きさは320x200で、ファイルサイズの制限もありますし、256色以下にしておいた方がいいみたいですね。 というわけで、Kondaraの画像をいただいて、GIMPでせこせこテスト用のブートロゴを作ってみました。 う〜ん、私はほとんどGIMPを使い込んでいなかったのですが、こんな風に画像を合成できるとなかなかおもしろいですね。
なお、今回の画像の著作権はRedHatとKondaraとNHKにあります(^^;。 こんなことしてしまったけど怒らないで下さいね。 あくまでも今回のは実験です、実験。
またまたmpg123 (2001.3.10)
この不定期日記でもたまにとりあげてるように、私はLinuxでMP3を聞くのにmpg123やxmmsなんかを使ってるわけですが、mpg123は1999年6月にリリースされた0.59r以降、正式版はアップデートされていません。
とはいうものの開発は継続しており、mpg123のサイトで説明されている通り、cvsを使って接続すると現在開発中のバージョンが落とせます。
$ cvs -d :pserver:guest@cvs-ti.informatik.uni-tuebingen.de:/home/hippm/cvs loginlogin : guest
password : guest
$ cvs -z9 -d :pserver:guest@cvs-ti.informatik.uni-tuebingen.de:/home/hippm/cvs checkout mpg123
で、試しに落としてみたところ、現在の最新版は2000年10月の0.59s_mh4となっており、きむらさんの3DNow!パッチがマージされている他、MMX対応デコーダも入っており、機能的にはまだまだ進化し続けています。
さっそく試しに make linux-3dnow、make linux-mmx してみましたが、なかなか具合が良ろしいようです。 というか、Duron 700@888で試してみた限りでは、3DNow!デコーダよりMMXデコーダを使った方がわずかに軽いみたいね(^^;。 最適化の具合が違うのか、あるいは音質を犠牲にしているのかもしれませんが。 アセンブラやCをそこまで深く読みこなせないし、大した耳も持ち合わせてない私にはちょっとわかりかねますね。
ところで、3DNow!対応版はCPUを自動検出して3DNow!かFPUを自動選択したり、手動で指定したりできるわけですが、MMX版は専用になってるみたいです。
というわけで、前回のCPU検出プログラムを組み込んで、3DNow!／MMX／FPUを自動選択してくれるようにしてみよう。
しこしこしこ。お、できた。 ちょっと頑張ればこの程度はできるようになってきたか（＞私）。 ちょっとうれしい。
さっそくパッチはmpg123の作者、Michael Hipp氏に拙い英語で送りました。 ところで、mpg123ってGPLじゃないし、このパッチを当てる対象のソースもCVSにしかないわけですよね。 ここでソース一式やコンパイル済バイナリを公開したらマズイのだろうか。 真面目にmpg123のライセンスとかを読んどいたほうがいいのかな？ でも私の英語力で正確に理解できるかどうかも疑問...。
そういや、mpg123のソースにはmpglibってディレクトリがあるよね。 mpglibは機能を限定した軽量版となっており、3DNow!やMMXは無論非対応ですが、ライセンスはGPLみたいです。 こいつに、3DNow!やMMXルーチンを本体から移植して機能強化した共有ライブラリにして、mpg123とxmmsで利用したらおもしろいかなぁとか、考えてみたり。 でも、そもそもmpg123本体はGPLじゃないから、そんなことしても公開できないかもね。 それができるんなら、このmpglibディレクトリの存在する意味が無いし。
まぁ、mpg123のソースやいろんなパッチは様々なディストリのとこに置いてあるし、大丈夫なんでしょう。 というわけで、CVSソースとパッチを含んだsrc.rpmをパッケージ置き場においておきます。
mpg123 foo.mp3 でCPUを判別してデコーダを自動選択、--force-3dnow を付けると強制的に3DNow!デコーダ、--force-mmx を付けると強制MMX、--force-fpu だと強制FPUモードになります。 なお、mpg123 --test-simd とするとCPU判別の結果が出て終了します。
- 追記：今回のパッチもまたまたxmmsに移植してみました(xmms 3DNow!/MMXパッチを参照)。xmms版の方がいろいろいじって少しは進化させたつもりですが、mpg123にbackportするのが面倒だなぁ...
Cのお勉強？ その4 (2001.3.3)
久しぶりにCのお勉強をしてみました。 たまにはCを書かないと、元々にわか勉強だから、すぐ忘れてしまうしね。 今回のお題目は、「CPUがMMX等の拡張命令に対応しているかどうかを検出」です。
思えば、mpg123のきむらさん版3DNow!パッチでは、「3DNow!対応CPUかどうかを検出し、対応していれば3DNow!デコーダを、非対応ならFPUデコーダを使う」ということをしています。 で、試しにCPU検出部分のソース(getcpuflags.s)を見てみました。 あれ、どうも見にくいと思ったら、これってアセンブラじゃん(ウソ。いくらなんでも最初から分かるって)。
...。 う〜む、私がアセンブラを少しは理解して、プログラムを書いてたりしてたのって、Z-80の頃なんだよね(^^;。 そもそもアセンブラの表記もザイログ形式だったし。
さて気を取り直して、少しネットで周辺知識を集めてみると、どうやら拡張命令に対応してるかどうかを調べるには、CPUID命令(当然機械語ね)を使うらしい。 しかも、この命令って、名前の通りCPUのベンダーとか、モデル、ステッピングの取得とかにも使うんですね。 で、調べて分かった、拡張命令の検出方法はこんな感じ。
| MMXの検出 |
eaxレジスタに1を代入してCPUID命令を実行。 実行後のedxレジスタの23bit目が1の時、MMX対応 |
|---|---|
| SSEの検出 |
eaxレジスタに1を代入してCPUID命令を実行。 実行後のedxレジスタの25bit目が1の時、SSE対応 |
| 3DNow!の検出 |
eaxレジスタに0x80000001を代入してCPUID命令を実行。 実行後のedxレジスタの31bit目が1の時、3DNow!対応 |
う〜ん、さすがアセンブラ、全然ヒトに優しくない(^^;。
それにしても、CPUIDはアセンブラにならざるを得ないとしても、検出プログラム自体を全部アセンブラで書くのはやっぱりツライですね。 もう少し良い手はないもんかなぁ。
というわけで、何かとっかかりは無いものかと、まずはカーネルソースをあたる。 こういうとき、Linuxっていろいろなものがソースからあるから勉強するには便利だよね。 で、linux/arch/i386/setup.c あたりでcpuidってのを多用していました。 どうやら、これは linux/include/asm-i386/processor.h で定義されてるようです。
(定義部分の抜粋)
inline void cpuid(int op, int *eax, int *ebx, int *ecx, int *edx)
{
__asm__("cpuid"
: "=a" (*eax),
"=b" (*ebx),
"=c" (*ecx),
"=d" (*edx)
: "a" (op));
}
|
おお、まさにこれはって感じ。 やっぱりcpuid命令のアクセスってのはアセンブラであるにしても、こういう形になってればCから使いやすいね。
というわけで、これを使ってSSE／MMX／3DNow!の有無を検出するプログラムを書いてみました。 check_cpu関数を呼ぶと、どの拡張命令に対応しているかをint型で返します。
(check_cpu.c)
|
(check_cpu.h)
|
ちなみにソース一式はこれ。 makeして、できあがった cpucapsを実行するだけです。 SSEが使えれば"CPU has SSE"、3DNow!が使えれば"CPU has 3DNow!"、MMXが使えれば"CPU has MMX"、何もなければ"CPU has no extended instructions"と表示されます。 SSEや3DNow!があれば当然MMXもあるわけだから、検索順位はこんなもんでいいでしょう。
最初、どうしてもセグフォ出まくりで悩んでいたのですが、そういやCって配列変数は0から始まるので、int j[4]; と定義したら、使える範囲は0〜3なのね。 すっかり忘れてました。 やっぱりダメダメですね、私。 あやうくCの勉強じゃないまま終わるとこだった(^^;。
祝・新カーネルリリース (2001.2.11)
最近忙しく、カーネルのアップデートもしてなかったのですが、ついに安定版カーネルの新シリーズ、2.4系がリリースされましたね。 2.3.99あたりからずいぶん経ったけど、ようやくリリースと相成ったわけで、これからは各ディストリにも採用されていくことでしょう。
というわけで、今の最新版は2.4.1。 早速実験してみました(やる前にドキュメントを読んでアップグレードが必要なパッケージは入れ替えときましょう。私はプレ2.4の時から追っかけまくってたから問題なかったけど)。
と思ったら、コンパイルした各オブジェクトをリンクして、vmlinuxを作るところで、エラーが出て止まってしまいました。 なんか、__buggy_fxsr_...がundefined referenceみたいな感じだったかな。 で、agcc-0.0.2を使ってるのがイカンのかな、と思ってKondara-1.2に入ってるgcc-2.95.2を使ったら、そこはクリアできたけど、qlogicfc_asm.cのとこでparse errorで止まった。
むぅ、まぁqlogicfcなんてSCSIカード使ってないから外すか(最近カーネルもRPM化してるので、汎用性を持たせて自分の使ってないドライバもmakeしてるのです)。 とりあえず、makeは通りました。
ところが、ブートの途中からいきなり遅くなる...。 CPUの認識とかは順調に進むのですが、ACPIを認識したあたりから急に遅くなって、起動プロセスが終わるまで数分かかってしまいます。 起動後もキーボードをカチャカチャ叩くと、数テンポ遅れて一文字ずつ表示される感じ。 なんじゃ、こりゃ？
むぅ、真面目にドキュメントを見れば、どっかにかいてあるのかな？ とりあえず、最新の2.4.2-pre3にしてみよう(懲りてない)。 やっぱり遅くなるねぇ。 と思ったら、ブート中にこんなメッセージが。
|
== 中略 == ACPI: Using ACPI idle ACPI: If experiencing system slowness, try adding "acpi=no-idle" to cmdline == 中略 == |
なるほど、そういうことですか。 とりあえずカーネルの起動オプションに acpi=no-idleを付け足したらまともな速度で動くようになりました。
そういえば、2.4.0-test11まではACPIを有効でやると、shutdown -h nowで電源が落ちない(カーネルのコンフィグ・オプションでACPIを外してAPMだけにすれば大丈夫だけど)という問題を抱えていたのですが、ちゃんと電源が落ちるようになりましたね。
- 補足1 :
- あれ？ mkinitrd が動かなくなってる？ どうやら イメージファイルを作って、mount -o loopして mke2fs するとこで止まるみたい。おかげでオリジナルLinuxのブートイメージとかも作れない...。2.2系カーネルで起動すれば問題ないし、2.4.0-test11ぐらいまでは2.4系でも動いてたと思うんだけどな。
- 補足2 :
- Dr. Kに聞いたところ、
「Kondaraのkernel24パッケージのconfigを持ってくると大丈夫。何らかの設定ミスらしい」
ということで、試してみたら確かに大丈夫になった。むぅ。 - 補足3 :
- ACPI idleを使うと遅くなる問題は、Pentium III + ASUS P2B (440BX)では発生しませんでした。チップセット or BIOSの問題と思われます。
- 補足4 :
- __buggy_fxsr_alignment でカーネルをmakeできない件については、きむらさんのUNOFFICIAL page of AthlonGCCで解説＆対処パッチが出てます。PGCCに由来した問題だったのね。
一つ前のページに戻る
このページのTOPに戻る