Orz日記 by Akio Morita

_ [FreeBSD]em driver

新鯖のon-boardの em device(82573L)で watchdog timeout -- resettingが多発 orz

部品ストックから掘り出した Intel PRO/1000 MT Server Adapter(82545EM)だと netioで 90MB/sec程度まで負荷をかけても 何エラーも出ずに動作する模様

現状では、on-boardの 82573Lのみ NGで、on-board 82547EI(旧鯖)と Intel PRO/1000 MT Server Adapter(82545EM)がOKってことなので、 em driverの chip supportが不味いのか、IRQ Routingが不味いのか...

_ [SAD]CVS MAIN trunkはg95サポートで荒れてますね

状況はかなりひどいようなので安定するまで バックポートは凍結かな?

• GNU make的な enbug(conditional-else-endifはネスト出来ないと infoに書いてある)
• Intel Fortran portを破壊(まあ、運転では使ってないのでセーフ?)
• g95 0.91(20070129)ではコンパイルできるが、出力がバグる(g95サポートになっていない!)
• 新 writeb@tfprinta.fには、コンパイラ実装依存な香りが漂っている

GNU makeに関しては、既存の amsad/alsad/acsadでの makeで 発覚するはずなので、既存の環境での make試験をせずに commitしたのは明白。

CVS MAIN trunkに関しては KEKBの運転で使っている以上、 運転環境の構築で問題が出る変更を入れるのは NGなはず。

writebで使っている character*Nな bufferへの write文の結果だが、 Fortran規格をチェックしていないのだが、出回っているコンパイラの 出力を比較する限り実装依存な気がする。 全てのコンパイラで動くことを期待するなら、Fortranの標準規格の 範囲内で書くべきで、可能ならコンパイラの実装バグを避けるよう 実装が安定している範囲で書くべき。

Fortranの場合、1文字入出力等のプリミティブなI/Oが標準規格に無いので、 Cと異なりread/write文の実装が腐っているからといって置き換えを 作れないところが頭痛の種ですね。プリプロセッサで open/close/read/write系を Cの関数に置き換えるというのは原理的には 可能だが、それは Fortranの部分コンパイラを作ることであって、 腐った処理系の再実装に相当する。