Proceedings of the 15th Annual Meeting of Particle Accelerator Society of Japan
August 7-10, 2018, Nagaoka, Japan

PASJ2018 WEP098

SPring-8 加速器制御系 VMEbus 計算機の64-bit OS 環境への移行について
MIGRATION EXPERIENCE OF VMEBUS COMPUTERS TO 64-BIT OS
ENVIRONMENT IN THE SPRING-8 ACCELERATOR CONTROL SYSTEM
増田剛正#Takemasa Masuda#
Japan Synchrotron Radiation Research Institute (JASRI)

Abstract
In the SPring-8 accelerator control system, VMEbus computers operated by Solaris OS have been used as front-end
computers. Since 2013 when VME multi-core CPU boards were introduced, the problem that the CPU load wasincreased and the running processes were frozen for over a dozen seconds has been periodically occurred. As the futureoriented approach to solve this problem, these VMEbus computers were migrated to 64-bit OS environment. 64-bit
compliance of device drivers was indispensable to achieve these migrations. The migrations of about forty VMEbus
computers have been completed after porting fourteen kinds of existing device drivers. My adopting approach to reduce
the porting cost of the device drivers, the evaluation of these migrations, and the obtained knowledge through theexperience of the migration work are reported in this paper. In addition, consideration of the future device drivers isdiscussed.

1.

はじめにタイマー割り込みの周期を 10 ミリ秒からより小さな値に変更することができる。例えば HZ 値を 1000に変更することで、1 ミリ秒刻みのきめ細かい時間制御が可能となる。これらが決め手となって Linuxを含む幾つかの候補の中から Solaris を選択した。
近年、VMEbus 計算機においても、ソフトウェアの並列処理が可能なマルチコア CPU が使用可能となった。並列処理が可能な MADOCA II[4]フレームワークへの移行に合わせて、2011 年から積極的にマルチコア CPU ボードの導入を始めた。

１GeV リナック、8 GeV ブースターおよび 8 GeV蓄積リングから構成される SPring-8 加速器複合体の制御系では、加速器コンポーネントを制御するためのフロントエンド計算機として VMEbus 計算機が採用され、サイト内に分散設置されている。およそ120 台の VMEbus 計算機が SPring-8 加速器制御系全体で使用されている（2018 年 2 月時点）。VMEbus
計算機の CPU ボードとしては x86 CPU を、OS としては Solaris を採用している。
1997 年の共用運転開始時は、リナックとブース 2. Solaris デバイスドライバ
ターでは 68000 系の CPU ボードと OS-9[1]、蓄積リ 2.1 構造と特徴
ン グ で は PA-RISC CPU ボ ー ド と PA-RISC 版
VMEbus 上の入出力ボード等のデバイスの制御をLynxOS[2]である HP-RT を採用していた。当時は十行うためには、OSのカーネル空間で動作するデバ分な性能の CPU や十分な容量の物理メモリが無イスドライバを用意する必要がある。Solarisにおけかったため、全世界的にコンパクトでリアルタイムるデバイスはツリー構造になっており（Figure1）、性に優れた OS を採用していた。リアルタイム OS
VMEbusやPCIbus
等のコンピュータバスに関わるネの条件として、優先度に基づくタスクスケジューリング、決定論的なタスク切り替え時間などがあり、 クサスノード部の制御にはネクサスドライバを、個またリアルタイムタイマが使用可能であるというこ 別の入出力ボード等のリーフノードの制御にはリーフドライバをそれぞれ用意する必要がある。リーフとも含まれていた。
2000 年のリナック制御系更新のタイミングで、高 ドライバはコンピュータバスからは独立した形式でい CPU 性能と十分なメモリ容量を備える x86 系 記述され、割り込みや Direct Memory Access (DMA)
CPU ボードと Solaris OS の組み合わせを新たに採用 転送などバスアクセスが必要な処理は基本的にネクすることとなった。Solaris は優先度に基づくスケ サスドライバを介して行う。そしてネクサスドライ
ジューリング、決定論的なタスク切り替えが可能な バ や カ ー ネ ル と の 取 り 合 い は 、 Device Driver
リアルタイム OS であり[3]、当時の Solaris 7 より Interface / Driver-Kernel Interface (DDI/DDK)と呼ばれLinux 同様フリーOS として利用できるようになった るインターフェースを介して行う。DDI/DDK は長（OS-9 や LynxOS はライセンス料が必要）。また 年にわたって殆ど形を変えることなくサポートが継
OS の HZ 値をデフォルトの 100 から変更することで、 続されているため、Solaris のリーフドライバはカーネルが更新されてもほぼそのまま動作する。
_________________________________________
Solaris におけるデバイスドライバの階層構造、#
masuda@spring8.or.jp- 604 -

Proceedings of the 15th Annual Meeting of Particle Accelerator Society of Japan
August 7-10, 2018, Nagaoka, JapanPASJ2018 WEP098

DDI/DKI インターフェースの提供は、作成したデバ して十数秒間制御プロセスがフリーズする問題が発イスドライバの長寿命化に非常に有効である。実際 生した（Figure 2）。この間制御プロセスが動作しなに我々は Solaris の利用を開始した 2000 年から現在 いため、収集データに欠落が生じたり、機器の制御に至るまで、OS のバージョンで言えば Solaris 7 か に遅延が生じたりする現象が発生した。
ら Solaris10 まで、使用する x86 VME CPU ボードが替わっても、殆どのデバイスドライバがそのまま継続して利用出来ている。ただし DDI/DKI インターフェースがサポート外となった関係で、一部のデバイスドライバについてはコードの修正を行っている。

Figure 2: So-called “24 days problem” that the CPU loadbecame high and running processes were frozen.
Figure 1: An example of the Solaris device tree.
2.2

バスブリッジチップ用ネクサスドライバ

初期の x86 VME CPU ボードにおいては、PCIbusから VMEbus へのブリッジチップとして、IDT 社のUniverse II チップ[5]がデファクトスタンダードとして使用されていた。我々は Universe II 用のネクサスドライバを作成し、その上で動作する各種入出力ボード用のリーフドライバを多数整備した。
後期の x86 VME CPU ボードにおいては 64-bit 環境への移行が可能となるよう PCI-Xbus から VMEbusへのブリッジチップである Tsi148 チップ[6]がデファクトスタンダードとして使用されるようになった。これまで多数整備したリーフドライバ群がそのまま使用できるよう、我々は Tsi148 チップ用ネクサスドライバを作成した。実際にこの試みは成功し、どちらのバスブリッジチップを乗せた x86 CPU ボードであっても、対応するネクサスドライバを用いるだけで、同一の入出力ボードは同一のリーフドライバを使用して制御することができるようになった。
2.3

64-bit Solaris への適用について

ただし、この状況には一つだけ例外がある。それは 64-bit Solaris への適用についてである。デバイス
ドライバはカーネル内部に組み込まれて動作するため、64-bit OS においては 64-bit 対応コードで記述されなければならない。残念ながら我々が作成したデバイスドライバは 64-bit 対応のコードにはなっていない。したがって 64-bit の Solaris 10 や 64-bit のみ提供されている Solaris 11 で使用するためには、デバイスドライバのソースコードを 64-bit 対応コードに書き換える必要がある。

3.

32-bit OS 環境で発生した問題

マルチコア CPU ボードと 32-bit Solaris を導入した
VMEbus 計算機において、周期的に CPU 負荷が上昇調査をしたところ、これは uptime カウンタ（32bit OS では 32-bit 幅）の最上位ビットが反転する際に発生する問題であることがわかった。我々の環境
では 1 ミリ秒の精細な時間制御を有効にするためHZ 値を 1000 としていることから、uptime カウンタは 1 秒間に 1000 カウントアップする。そのため最初の問題はシステム起動後 24.8 日目に発生し、以後は 49.7 日周期で問題が発生する。これは実際に問題が発生した周期と一致する。この問題は世間一般では 248 日問題、あるいは 497 日問題と言われている現象であるが、我々の環境では HZ 値を通常の 100から 1000 にしているため問題発生の周期が 1/10 となっている。ここでは以後この問題を 24 日問題と記すことにする。
この 24 日問題を解決するためには OS を 64-bit 化するのがもっとも有効な方法である。OS を 64-bit化するためには、先に述べた通り関係する全てのデバイスドライバを 64-bit 化しなければならない。具体的には 14 種類のデバイスドライバを 64-bit 化する必要があった。これには膨大な時間とコストが掛かるため、先ずは 32-bit OS のままでの問題の解決を試みた。具体的には Oracle とサポート契約を結び、技術サポートを受けながら関係のありそうなパッチを当てるなどの対策を試みた。同時に CPU ボードメーカーからも BIOS の設定等で問題の解決に繋がるものはないか技術サポートを受けたが、結局問題の解決には至らなかった。そのため最終的には、最も未来志向的な解決方法として OS を 64-bit 化する方法を採用することとした。また 64-bit 環境への移行にあたっては、最新の Solaris 11 をターゲットとした。

4.

移行の方針

4.1 方針
先述の通り、64-bit OS（Solaris 11）への移行にあたっては、Tsi148 バスブリッジチップ用のネクサス- 605 -

Proceedings of the 15th Annual Meeting of Particle Accelerator Society of Japan
August 7-10, 2018, Nagaoka, JapanPASJ2018 WEP098

ドライバ 1 種類を含めて 14 種類ものデバイスドライバを 64-bit 化する必要があった。
通常、デバイスドライバの作成・改修は簡単なものを除きアウトソーシングしている。その場合、入出力ボードと組み合わせて動作試験まで行うのが一般的である。簡単なリーフドライバも幾つか含まれているとはいえ、動作試験を含めて 14 種類ものデバイスドライバ改修をアウトソーシングするとなると膨大なコストと時間が必要となる。一方、内部スタッフによる改修は、マンパワーや改修に掛かる時間、必要とされる知見等を考慮した場合現実的ではなかった。デバイスドライバの 64-bit 化は、改修すべき箇所や改修方法のパターンはほぼ決まっているが、実際に改修を行うには後述のように高度な知見が必要とされるためである。そこで移行にあたっては以下のような方針を立てた。
• Solaris デバイスドライバについての高度な知識・豊富な経験を有する会社にアウトソーシングする。
• アウトソーシング先での改修は机上での作業に留め、ハードウェアを含めた動作確認は我々の責にて行う。
• 動作確認で不具合が見つかった場合には、アウトソーシング先において無償で修正する。
4.2

ることができる（Figure 4）。ただしこの改修はアプ
リ ケ ーシ ョ ン側 に影 響 を与 え てし まう 。 幸い 、
SPring-8 ではデバイスドライバを呼び出すためのAPI 関数を用意しているため、改修は API 関数までで済ませられる。したがって、アプリケーションのソースコードまで改修する必要はないのだが、実行形式は作り直す必要が生じる。またアドレス渡しの部分を改修するため、この処理に誤りがあると動作テスト時にシステムのハングアップやシステムクラッシュを引き起こす。このような状況に陥るとデバッグが非常に困難になり、システムの復旧に非常に時間が掛かってしまう。改修にあたって高度な知見が必要となる理由である。

(a) API function

改修項目

デバイスドライバの 64-bit 化にあたっては、以下の事項を確認し、必要に応じて改修する[7, 8]。基本的にはデータ型の変更に起因するものである。
• long 型の確認
• ポインタのアドレス計算の確認• ビットシフトの確認• 構造体の確認• 定数の型指定• ioctl エントリポイントの確認• ioctl パラメータの確認• 32-bit/64-bit 共用マクロ• DDI アクセス関数の確認• 書式付き出力の確認
このうち、改修へのインパクトが大きいのが ioctlのパラメータである。基本的には、64-bit 化への改修はデバイスドライバ内で閉じるのであるが、これについてはアプリケーション側にまで改修の影響が及ぶことがあるためである。
通常、ioctl のパラメータには構造体を使用することが多いのだが、構造体のメンバに long やポインタが含まれる場合には、呼び出し側のアプリケーションが 32-bit か 64-bit かによってデバイスドライバの参照の仕方を変える必要がある。また、パラメータとして構造体ではなく配列を用い、その中でアドレスを渡している場合も注意が必要である。アプリ
ケーション側で int 型に cast してしまっているような場合、64-bit アプリケーションでは上位 32-bit のアドレスが省かれ、デバイスドライバ側に正しいアドレスが伝わらなくなる（Figure 3）。
このような問題に対しては、新規に構造体を用意してそのメンバの中でアドレスを渡すことで回避す(b) Device driver
Figure 3: An example of a device driver which doesn’t
work in the 64-bit environment.

5.

移行の実際

5.1 机上改修について3.1 項で述べた方針に従って、14 種類のデバイスドライバ全てをアウトソーシングによって改修した。
24 日問題が発生するホストをできる限り早く減らせる よ う、 改 修は 多く の ホス ト で使 用さ れ てい る
VME ボードのデバイスドライバから始めることにした。全てのホストで使用される Tsi148 ネクサスドライバからスタートし、光伝送ボード、リフレクティブメモリボード、RIO ボード、BPMDSP ボードの 4 種類のリーフドライバを 64-bit 化することにした。これで移行が必要な 37 ホストのうち 25 ホストの移行が可能となる。その後、残りの 12 ホストの64-bit OS 環境への移行が可能となるよう、使用数の少ない残り 9 種類のリーフドライバの 64-bit 化を行なった。
ハードウェアを含めた動作確認を行わず机上での改修に留めたことで、通常の 1/7~1/10 程度の予算で済ませることができた。アウトソーシング先の技術者が Solaris デバイスドライバに関する高度な知識や経験を持っていたことで、机上での改修にも関わらず、多くのデバイスドライバが 64-bit Solaris においてほぼ問題なく動作した。動作確認において幾つか- 606 -Proceedings of the 15th Annual Meeting of Particle Accelerator Society of Japan
August 7-10, 2018, Nagaoka, Japan

PASJ2018 WEP098

問題はあったが、その多くが 3.2 項で述べた ioctl パラメータに関わるものであった。

(a) Newly introduced data structure

一方、RIO ボードと BPMDSP ボードについては先に述べた ioctl パラメータに関わる改修を行ったた
め、デバイスドライバを呼び出すための API 関数も修正した。その関係でアプリケーションを再リンクする必要が生じた。結果的にはデバイスドライバ自体には全く問題はなかったのであるが、5.3 で述べるように、アプリケーションのビルド環境に起因する問題で、再リンクし直したアプリケーションに問題が発生した。そのため RIO や BPMDSP を含むホストについては何度か 64-bit 環境への移行を中止する事態を経験した。
残りの 9 種類のリーフドライバ、12 ホストの移行作業ではアプリケーションの再リンクが必要な場合も含まれていたが、上述の経験を元に問題を回避することが出来た。デバイスドライバ自体に問題が含まれているケースが含まれていた関係で、デバッグや修正には時間が掛かったが、移行自体は問題なく実施することが出来た。
移行時に発生した問題(b) Revised API function

5.3(c) Revised device driver

64-bit OS への移行時に以下のような問題が発生した。いずれも改修したデバイスドライバの問題ではなく、開発環境や OS 自体の問題であった。
1. アプリケーション側ではデバイスドライバのシステムコールが正常に実行されているにも関わらず、実際には対応するデバイスドライバがコールされておらず、ボードのレジスタ操作が行われない問題。
2. 時々5~10 秒程度プロセスがフリーズする問題。
1 については明確な原因が特定できずにいるが、デバイスドライバの API 関数を再コンパイルした開発環境に問題があったようである。別の開発環境でAPI 関数をコンパイルした場合にはこの現象は起きなくなった。この問題は全てのドライバコールで起きたわけではなく、一部の特定のドライバコールでのみ発生した。また改修箇所とも無関係であった。
2 の事象は、Solaris10 までには見られなかった現象で、Solaris11 から新たに出現した問題である。詳細に調査を行うと、10 秒前後のプロセスのフリーズと、5 秒前後のプロセスのフリーズの 2 種類の問題に分けられることが分かった。前者は Solaris11.2 以降で起こる問題で、システムパラメータの変更によって回避可能である。後者は Solaris11.2 以降で、かつ特定の CPU ボードでのみ起こる事象であり、現時点で原因は不明である。両者とも Solaris11.1 では発生しないため、OS を Solaris11.1 に戻すことで回避した（移行作業時は Solaris11.3 を選択）。
いずれの問題も事前に見つけ出すのは難しかったと考えられるが、これらの問題が起きたために64-bit 環境への移行が大きく遅延してしまった。改修したデバイスドライバ自体の問題ではなく、別の要因で移行作業が遅れたことは非常に残念であったが、64-bit 環境への移行は改修したデバイスドライ
バが問題なく動作すれば良いというわけではなく、開発環境やビルドしたアプリケーション、OS まで含めて考えなければならないことを改めて認識した。

Figure 4: An example of the revised device driver which
work in both 32-bit and 64-bit environment.
5.2 64-bit OS への移行作業
実際の 64-bit OS への移行作業は、加速器の長期運転停止期間に順次実施した。先に 64-bit 化を終えた Tsi148 ネクサスドライバと４種類のリーフドライ
バ（光伝送ボード、リフレクティブメモリボード、RIO ボード、BPMDSP ボード）で構成されたホストの移行作業から開始した。
4 種類のリーフドライバのうち、光伝送ボードとリフレクティブメモリボードについては改修がデバイスドライバ内部に留まったため、デバイスドライバのみを入れ替えるだけで済んだ。このため光伝送ボードならびにリフレクティブメモリボードのみから構成される 13 ホストの移行については全く問題なく実施できた。

- 607 -Proceedings of the 15th Annual Meeting of Particle Accelerator Society of Japan
August 7-10, 2018, Nagaoka, Japan

PASJ2018 WEP098

6.

移行から得られた知見ドライバに集約することで、デバイス固有の制御を行うリーフドライバがシンプルになり、コードの可読性が向上する。64-bit 化のような改修作業も容易になる。そして手順が複雑なバスアクセス部の制御を担うネクサスドライバの信頼性を向上させることで、システム全体の堅牢性が増す。
Solaris よりも一般的に利用されている Linux においても同様のアプローチでデバイスドライバを作成し、バスアクセス部分のデバイスドライバを共同で開発・利用するのが良いと考える。既に DESY で
MicroTCA プラットフォームをターゲットにした
PCI Express Universal Driver (upciedev)が開発され、
オ ー プ ン ソ ー ス で 公 開 さ れ て い る [9] 。 こ れ はMicroTCA がターゲットではあるが、通常の PC をはじめとした PCI Express ベースのプラットフォームであれば適用出来るはずである。この upciedev の活用を世界的な取り組みとして拡大させ、デバイス固有のデバイスドライバを upciedev の上に作成する。
これらデバイス固有のドライバもオープンソースで公開し、誰でも利用出来るようにすることで、ドライバ開発の時間とコストを削減し、対象デバイスの導入までの時間を短縮できるようになる。他のバスアクセスドライバについても、upciedev と同様の手法で標準化を進めては如何であろうか。

今回は移行のためのコストを抑えるため、デバイスドライバの改修を机上で行ったが、やはり机上の改修作業だけでは完全な移行は難しい。オリジナルのデバイスドライバの出来が余り良くないと改修量が多くなってしまうし、特に ioctl のパラメータ部分の改修、すなわちユーザー空間とのデータの受け渡しに関わる部分の改修は困難が伴う。可能であるのならば、デバイスドライバ改修時にボードレベルでの動作確認試験を行うのがベターである。
上述の移行時の問題はいずれもビーム診断系のホストで発生したが、ビーム診断系のホストは運転停止期間中の動作試験が容易ではなく問題の発見が遅れてしまった。他の機器は運転停止期間中でも動作確認試験が行えるので問題ないが、可能であれば、電子ビームの蓄積中に動作試験が行えるとよりスムーズな移行が実現できたと思われる。
また新しい OS の導入は慎重になるべきである。
今回 64-bit OS として Solaris11、厳密には Solaris11.3
を 導 入 し た が 、 こ れ は 既 に SACLA に お い てSolaris11、厳密には Solaris11.1 の運用実績があり問題 な いと 考 えた ため で ある 。 しか し、 実 際に はSolaris11.3 において上述の問題が生じてしまった。
デバイスドライバの 64-bit 化自体が非常に困難な作業であるから、OS の選択肢としてはより安定な動謝辞作が期待できる Solaris10 の 64-bit 版を選択した方がデバイスドライバの 64-bit 化改修作業においては、ベターであった。
有限会社平成の河原章氏に多大なる貢献を頂きまし32-bit OS 環境から 64-bit OS 環境への移行を実際に行って強く感じたことは、この移行は容易ではな た。デバイスドライバの机上での改修は、彼のソフいということである。ioctl のパラメータ部の改修は トウェアスキルを以って実現できた手法であると言アプリケーション側の改修が必要となる点で特に困 えます。この場を借りて御礼申し上げます。
難である。故に 64-bit OS への移行は必要最小限にすべきである。問題を回避する別の方法があるので 参考文献あれば、先にそちらを検討した方が良い。問題の解 [1] http://www.microware.com/
決は、出来る限りアプリケーションサイドで行うべ [2] Lynx Software Technologies, Inc.;
http://www.lynx.com/products/real-time-operatingきである。
systems/lynxos-rtos/
今後新たにデバイスドライバを製作する場合には、 [3] T. Masuda et al., “SPring-8 線型加速器ビーム位置モニ
当然 64-bit OS への対応を考えるべきである。更に
ター用同期データ収集システムの更新”, Proceedings ofthe 10th Annual Meeting of Particle Accelerator Society of
言うならば、デバイスドライバ内の記述量は出来るJapan, Nagoya, Japan, Aug. 3-5, 2013, pp. 1118-1121.
限り減らすべきである。すなわち、デバイスドライ[4] T. Matsumoto et al., “Next-Generation MADOCA SPring-8
バにはレジスタアクセスや割り込み、DMA 転送なControl Framework”, Proceedings of ICALEPCS2013, San
どカーネル内部でしかできない必要最小限の処理にFrancisco, California, USA, 2013, pp. 944-947
とどめ、ユーザー空間でも可能な処理であれば、 [5] https://ja.idt.com/products/interface-connectivity/vme/
ca91c142d-vme-pci-bridge
ユーザー空間で動作する API 関数として提供した方が良い。デバイスドライバを出来るだけシンプルに [6] https://ja.idt.com/general-parts/tsi148-vme-pci-x-bridge[7] Solaris 64bit Developers Guide:
することで、 64-bit 化の改修量を減らすことが出https://docs.oracle.com/cd/E53394_01/html/E61689/
来る（アプリケーション側は 32-bit のままでも問題index.htmlないため）。
[8] Writing Device Drivers, Appendix C Making a Device
Driver 64-Bit Ready:

7.

デバイスドライバの在り方について

今回の 32-bit OS 環境から 64-bit OS 環境への移行 [9]の経験を通して、移行作業の中心であったデバイスドライバの在り方について、ここで考察したい。
Solaris が提供するデバイスドライバの階層構造は、保守性や堅牢性の向上を考慮した場合、非常に有益なアプローチである。バスアクセス部分をネクサス- 608 -

https://docs.oracle.com/cd/E36784_01/html/E36860/lp64-35004.html#scrolltoc
https://github.com/MicroTCA/upciedev