次のページ 前のページ 目次へ

1. 現在の Linux/Alpha の状況は？

まず確認しておきたいことは、Linux/Alpha は本当に動作するということです。 ほとんど全ての主要なアプリケーションが移植され動作しています。 XFree86をはじめ、LaTeX、ghostview、Mosaic、Emacs、gcc、 C++、NFS、オートマウンタ、各種シェル、perl、python、Java、Tcl/Tk、scheme、 apache HTTPサーバ、およびフリーで提供されている多くのソフトが動作しています。 X11 に関しては、いくつかのビデオカードで動作することが確認されています （ Linux/Alpha で動作するグラフィックカードは？の章を参照）。 Quake も Dave Taylor 氏および Linus Torvalds 氏により、Linux/Alpha 用のバイナリが 用意されています。1997 年 4 月には em86 エミュレータが公開されて、多くの Linux/x86 バイナリを Linux/Alpha 上で動作させることが出来るようになりました （ em86 の章を参照）。applix、netscape、acrobat などのすばらしいアプリケーションも、em86 上で動作させることができます。 em86 は、Digital Semiconductor の Jim Paradis 氏の提供により、無償で 利用することが出来ます。

Linux/Alpha は PCI もしくは EISA 仕様のほとんど全ての Alpha マシンで動作しています。ただし、DEC 3000 シリーズ・ ワークステーションの TURBOchannel 仕様では動作しません。

1.1 サポートされている周辺機器

動作が確認されている周辺機器（もし、下記以外での動作が確認された場合に は、私たちまで連絡を下さい）。

1.2 現在判明しているバグおよび作業中のもの

この章では、現在 Linux/Alpha において判明しているバグ、そしてこれらの 回避方法や作業状況について述べます。下記の事項は現在作業中のため、 変更があるかもしれません。また、ここに記載されていない新たな問題もあるかも 知れません。あるいは、最新のディストリビューションでは、ここに挙げられた バグもすでに解決されているかもしれません。いずれの場合でも、 axp-list メーリングリストに メールを出す前に、まずこの章を最初に調べて下さい。もし、未知のバグ もしくはそのバグに対する解決方法を発見した場合には、私たちへメールで 報告していただけると助かります（できれば linuxdoc-SGML 形式で）。

ルートファイルシステムのマウント中にカーネルがハングアップないしは パニック状態となる：

Linux の Kernel では、デフォルトのルート ファイルシステムが /dev/sda2 にハードコーディング されています。もし異なるディスクあるいはパーティションにルート ファイルシステムがある場合には、起動時のオプションで root=/dev/root-partition と明示的に 指定しなければなりません。 例えば、ルートファイルシステムが /dev/hda1 に ある場合には、root=/dev/hda1 と指定してください。

ELF 用の gdb でシェアードライブラリ中の関数をデバッグする際の 動作がおかしい：

gdb でダイナミックリンクされた バイナリを使用する場合には、ダイナミックシンボルを強制的に 解決させる必要があります。これを行なうには、gdb 中で set env LD_BIND_NOW=1 を実行してください。 これを行わないと、gdb がシェアードライブラリ中の関数へ ジャンプしたときに、おかしな動作をする場合があります。 この不具合が発生する箇所は特定できていますが、 修正する時間がないようです。

カーネルがフロッピードライブの容量を 2.88MB と認識する：

Alpha では、 フロッピードライブに何が接続されていても、カーネルは常に 2.88MB の容量があると認識します。でも心配する必要はありません。 通常フロッピードライバは容量を自動認識するので、全く問題なく 動作します。ただし、フロッピーをフォーマットする場合は例外です。 この場合には、正しい容量のデバイス名を指定して下さい。例えば、 1.44MB のドライブでフォーマットを行なう場合には /dev/fd0 ではなく、/dev/fd0H1440 を指定して下さい。

不整列アクセス（Unaligned access）：

他の RISC CPU と同様に、Alpha でもメモリのアクセスに際しては 自然境界に整列している必要があります。例えば、メモリから 4 バイトの整数を読み込む場合には、先頭のアドレスが 4 の倍数と なっている必要があります。同様に、8 バイトの整数を読み込む 場合には、8 の倍数のアドレスから読み込む必要があります。 もし、CPU が正常に整列していないワードをアクセスする場合には、 CPU はカーネルにトラップをかけて警告を出力します。 そしてカーネルは、不整列アクセスをエミュレートし、何事も なかったかのようにユーザプロセスを実行します （ただし実行速度は大幅に落ちます）。

典型的な、境界不整列アクセス（unaligned falt access）の メッセージは以下のようなものです。 

X(26738): unaligned trap at 000000012004b6f0: 00000001401b20ca 28 1

これは、プロセス ID が 26738 の X（X11サーバ）が、 アドレス 0x1401b20ca で境界不整列アクセスを行なったことを 意味します。また、このアクセスはアドレス 0x12004b6f0 から 実行されたことを示しています。他の数字にはあまり重要な 意味はありませんが、カーネルのソースを調べるともっと詳しい 情報を知ることができます（例えば、load と store の関係など）。

このメッセージが出力されてもそれほど心配する必要はありません。 境界不整列アクセスをしたプログラムでも正常に動作します。 境界不整列アクセスはそのうち修正されると思いますので、 メッセージは無視して結構です（もしあなたがプログラマならば、 境界不整列アクセスが無くなるようにソースを改良して下さい）。

リンカが warning: using multiple gp values というメッセージを 出す：

この警告は大きなプログラムを構築した際に出力されます。 ハードウェアに密着したハッキングを行うのでなければ、気にする 必要はありません。この警告は無視しても安全で、 将来はオプションとなるでしょう。

IDE ドライバの動作が遅い：

デフォルトの設定では IDE ドライバは長期間の割り込みが 禁止されています。これが原因でカーネルの割り込みに対する 反応が鈍くなり、処理速度が低下します。これを 回避するには、以下のコマンドを全ての IDE ドライブに対し 入力して下さい。 

                hdparm -u 1 /dev/hd?
この設定を行うことにより、IDE ドライバの割り込みが再許可されます。

minlabel、fdisk 使用後にカーネルがパーテション認識に失敗する：

パーテションテーブルを変更した後にシステムを使用することは 避けて下さい。たとえ、minlabel や fdisk が正しい 値を示したとしても、必ず再起動してカーネルにパーテションを 認識させるようにしてください。

tar xvMf /dev/fd0 でハングアップする：

（このバグは、GNU libc ベースのシステムでは発生しないはずです） libc-0.43 の malloc のバグのため、マルチボリュームの tar アーカイブが正常に動作しません。gmalloc パッケージを使用して 再コンパイル、リンクするか、あるいは新しい libc を入手して下さい。

日付が 20 年ずれる：

これは本当はバグではありません。しかし、多くの人が遭遇している 問題のようです。Jay Estabrook 氏による最終的な解決方法を 以下に示します。 

ARC コンソールと SRM コンソールは、日付を time-of-year (TOY) 時計に
記録していますが、フォーマットは若干異なっています（年フィールドの
み）。

通常、"/sbin/clock" は SRM が使用しているフォーマットを解釈します。
しかし、"-A" フラグを指定すれば、ARC のフォーマットを理解することも
できます。したがって、ARC フォーマットの日付を読み出すためには 
"clock -r -A" を使用し、書き込むには "clock -w -A" を使用する必要が
あります。もし、日付が期待通りのフォーマットで書かれていない場合に
は、ARC または SRM コンソールが文句を言ってくるでしょう。:-\

正しいフォーマットを使用する一番確実な方法は、コンソールの日付設定
機能を使用して日付を設定することです。これは、ARC コンソールではメ
ニューのなか、SRM コンソールではコマンドになっています（IIRC： 
"help date" を試してください）。

次に、Red Hat の /etc/rc.d/rc.sysconfig スクリプト
（訳注：/etc/sysconfig/clock）のなかで、"clock" の呼び出しが正しく設
定されていることを確認してください。

MILO/kernel の起動に ARC コンソールを使用する場合：

1. Red Hat 4.1 では、/etc/sysconfig/clock に以下の記述があること

        CLOCKMODE="ARC"

2. Red Hat 4.2 では、/etc/sysconfig/clock に以下の記述があること

        ARC=true

SRM コンソールから直接カーネルを起動している場合：

1. Red Hat 4.1 では、/etc/sysconfig/clock に以下の記述があること

        CLOCKMODE=""

2. Red Hat 4.2 では、/etc/sysconfig/clock に以下の記述があること

        ARC=false

上記の設定が "clock" を呼び出すときの引数にどう反映されるかは、
/etc/rc.d/rc.sysconfig ファイルを参照してください。

時間がでたらめな日付／時刻になる：

これは、PC164/LX164/SX164 で発生する問題です。原因は、これらの ボードで使用されている TOY クロック・ハードウエアのバージョンが 微妙に違うためです。すでに述べたように、システムクロックは起動時に clock コマンドが TOY クロックを参照して設定されます。 設定に問題があるかどうかを調べるには、以下のコマンドを試してください。 

while true; do /sbin/clock -r [-A]; done
（TOY クロックが ARC フォーマットを使用している場合には -A オプションを指定してください）
これで一致しない場合には、/sbin/clock を アップデートしてください。ファイルは以下のところから入手できます。 
gatekeeper.dec.com:/pub/DEC/Linux-Alpha/Kernels/clock-pc164-rh4.2
gatekeeper.dec.com:/pub/DEC/Linux-Alpha/Kernels/clock-pc164-rh50

0>0>0>0>0>0>：

標準の MILO イメージは、コンソールだけでなく、最初の シリアルポートとも交信するように設定されています。もし、 最初のシリアルポートにモデムがつながっていると、モデムが エコーバックしてしまいます。これを 回避するためには、システム起動時にはモデムの電源を 切ってください。あるいは、異なるシリアルポートにつなぎ直したり、 シリアルポートへの出力を行わないように MILO を 作成してもいいでしょう。

fdiskがディスクパーティションを認識できない：

これは、Digital Unix の disklabel ユーティリティで 作成されたパーティションのように、BSD スタイルの パーティションを使用しているときに発生します。fdisk を BSD モードに切り替えて下さい。

vi が入力を 4 文字一組で処理する：

実際には、ほかのアプリケーションでも同様のことが 起きるかもしれません。これは、ncurses の問題です。 以下の章で説明しているように、プログラムが termio と termios を混同していることに 関するものでしょう。対応策は、vi を起動する前に stty eof '^a' と入力して下さい。

Ruffian（164UX）で X が起動しない：

"Failed to set IOPL for I/O" というメッセージが出て、 X の起動に失敗します。原因は、Red Hat 5.1 の GLIBC が RUFFIAN システムを識別できないからです。root になって、 （訳注：/etc ディレクトリで）以下のコマンドを 正確に入力して下さい。 

ln -s EB164 /etc/alpha_systype

ipfwadm が失敗する：

Redhat 5.1、5.2 for Alpha に含まれている ipfwadm には バグがあります。Redhat 5.0 の ipfwadm を使用して下さい （注意：2.1.* や 2.2.* のカーネルを使っている場合は、代わりに ipchains を使っているでしょう）。

Adaptec SCSI コントローラの動作が不安定：

PC164 で Adaptec 2940 を使っている場合にとくに発生します。 デバイスのスピード、幅（？）、終了の自動認識を オフにすることで改善するようです。 以下のユーティリティーを入手して下さい。 

http://www.windowsnt.digital.com/support/drivers/drivers.asp/
入手したファイルをフロッピーまたは FAT パーティションに コピーし、ARCBIOS メニューの "Run a program" から実行します （新しいシステムでは、ファームウエアの i386 エミュレータを 通してオンボード・ユーティリティを起動することによって、 SCSI コントローラの設定を行うことができます）。

時刻を設定した後で、XL266 が立ち上がらない：

XL266 のハードウエアクロック設定の際に、-A オプションを つけ忘れた場合、ARCBIOS は無効な時刻と認識して、全ての OS の起動を拒否します（時刻の再設定が必要になります）。 不幸なことに、設定が明らかに間違っていると分かっている 場合でも、再設定することはできません（これは明らかに バグです）。回復させるには、修正した linload.exe を ftp://ftp.ub.uni-marburg.de/pub/unix/linux/alpha/ から入手して下さい（Juergen Schroeder 氏に感謝します）。 入手したファイルを適当な MILO と一緒にフロッピーにコピーし、 メニューの "Run a Program" から実行します。MILO のなかから linux の起動が成功したら、時刻を再設定して下さい。-A を つけるのをお忘れなく...
（linload.exe の修正は、MILO の位置をプログラムのなかに 書き込んだのだと思います）

1.3 Alpha への移植：long と short に関して

UNIX 上で、C を使ってプログラムする際に陥りやすい、いくつかの落し穴を、 ここに思いつくままに集めてみました。これは実のところ Linux や Alpha に 限った話ではないのですが、Linux/Alpha は 64bit の世界での先駆的な OS の 1 つですので、ここに記された問題は、他の 64bit OS でも発生する可能性が 高いでしょう。

sizeof(long)!=32

多くのプログラムが long を 32 ビットとして処理していますが、 ANSI C 規格にはこのような規定はありません。例えば、 DEC Unix や Linux のような OS が Alpha 上で動作する場合に、 主な C における型のサイズや制限事項は以下のようになっています。

したがって、ビット落ちなしにポインタを整数 (int) に 変換することはできないことに注意して下さい。事実 Alpha のバイナリでは、基本的にこのようなキャストを行なった 場合には、意図的に core ダンプをするようにしてあります。 このような難しいエラーをデバッガで探すよりは core ダンプさせてしまった方が見つけやすくなるからです。

もし正確に n ビットの変数が必要な場合には、Linux 用の アプリケーションでは（および GNU libc を使用している他の システムでも）、以下の型を使用することができます。

カーネルでは代わりに以下の型を使用します。 しかし、上記のなかにはシステム依存の型も存在します。 とくに 32 ビットマシンでは、GNU C を使用した場合のみ 64 ビット整数を使用することができます。同様に、例えば 36 ビットのように特殊なワードサイズを持つようなシステムもあります。 したがって、移植性の点からも、これらの変数の使用は控えて下さい。

inet_addr() の返り値のエラー

inet_addr() はエラー時に -1 を返すという、 一般的な規則を適用してしまったためです。Linux の man-page でさえこのような記載があります。しかしこれは誤りで、 本当は inet_addr() はエラー時に INADDR_NONE を返します。この値は netinet/in.h で定義されています。もっと良い 解決法は、この関数を使用しないことです。最近のライブラリで 提供されている inet_aton() 関数を使用すれば、 成功／失敗を表す返り値で間違えることはなくなります。

struct termio と struct termios は同じではない

多くの Linux のプログラムは struct termio、 struct termios および ioctl() を混同して 使用するという間違った使い方をしています。多くのシステムでは この 2 つのインタフェースは両立しません（歴史的な経緯もあり、 簡単には修正できません）。したがって、struct termio を 使用する場合には TCGETA、TCSETAF、TCSETAW、 TCSETA のみを使用し、struct termios を使用する 場合には TCGETS、TCSETSF、TCSETSW、 TCSETS のみを使用して下さい。

ロード／ストアに関する原子性（atomicity）に関して

一般にマシンのワードサイズよりも小さい読み出し／書き込み時の データ量が原子的（atomic）であるという仮定は安全ではありません。 とくに、初期の Alpha チップは byte もしくは short のデータを 読み書きするための原子的な命令を持っていません。他の デバイスや割り込みと同期を取るために、カーネルのハッキングを 行なうのでなければ、気にする必要はありません。しかし、 共有メモリを通して他のプログラムとデータを共有するような 場合には、通常のユーザ空間でもこの問題が発生する場合があります。

次のページ 前のページ 目次へ