Tru64 UNIXで遊ぼう!(インストール編)

今は亡きDECの遺産、OSF/1ことDigital UNIXことTru64 UNIXで遊ぼうというという記事です。

ユーザーが少なくなってきて、記事が散逸し始めているので、基礎的なことをまとめておきます。

インストール編とタイトルに書きましたが、インストールする前に大事なことが1つあります。

Tru64 UNIXはライセンスが無いとまともに動きません。
ヤフオクなどでOSのメディアは時々出品されていますが、ライセンスが付いていないことがほとんどです。
ライセンス付きのTru64 UNIXが出品されていれば、死ぬ気でゲットしましょう。
最低限必要なライセンスはOSF-BASE、OSF-USR、OSF-SVR、OSF-DEVです。

Tru64 UNIXを新し目のハードにインストールする場合は、New Hardware Delivery kits(NHD)というCDが必須です。
Tru64 UNIXのメディアセットに同梱されていますが、無い場合はHPが無料で公開しているので、焼いて使いましょう。

Tru64 UNIX New Hardware Delivery Online Documentation

インストールは以下のNHDのCD1枚とTru64 UNIXのインストールCD1枚の計2枚をとっかえひっかえして進めていきます。

インストーラにTru64 UNIXのCDを要求されてもCDドライブに入れてはいけない場合など罠が満載なので、以下のマニュアルを熟読して進めてください。

NHD for Version 5.1B Installation Instructions

インストール時に英語の他に追加で使用する言語を選択できますが、自分の場合は日本語を選択するとグラフィカルインストールに失敗するという罠に陥っていまいました。
グラフィカルインストールを行う場合は追加の言語で日本語を選ばないほうが良いかもしれません。
テキストインストールならば追加の言語で日本語を選択しても問題ありません。
グラフィカルインストールとテキストインストールの切り替えは
SRM画面で

>>set console graphics
>>set console serial

で切り替えできます。

Tru64 UNIXはインストーラが標準で割り当てるHDDのパーティションの容量が少ないので、後で悶絶必死です。
(以下の例だと/が384MBしかない)

必ずパーティションは切り直しておきましょう。
(以下の例だとパーティションaが/で15GB、パーティションbがswapで1GB、パーティションgが/usrで10GB、パーティションdがLSMの予備で8GB)

一度インストールが完了すると、リブートがかかり、インストーラが自動でパッチを当て始めます。

パッチ当てが終わると再々度リブートがかかり、インストールは完了です。

とっても高性能だけれど、いまいち影が薄いAdvFSで遊んだり、スピードメーターを出したりして遊びましょう。

Tru64 UNIXの管理コマンドはsysmanです。

登録するユーザーはsuする場合はGroupはsystemにしておきます。

【夢を超えた】Mac版XM6iを使ってNetBSD/x68kを動かすという話【夢の、頂きへ】

急にお金M68Kアーキテクチャでコンパイルされたバイナリが必要になることってありますよね。

そんなときあなたならどうしますか？
誰かに借りるにしても、理由を説明して頭を下げないといけない・・何より人間関係が気まずくなるのだけは避けたいものですよね。
そんなあなたにおすすめなのが、即日融資でお金を借りるXM6iにNetBSD/x68kをインストールしてコンパイルする方法です。

XM6iとは?

XM6i - クロスプラットフォーム X68000/X68030 エミュレータだそうです。
XM6i - クロスプラットフォーム X68000/X68030 エミュレータ

X68000/X68030というのは1987年3月28日にシャープが発売したパーソナルコンピューターだそうです。
X68000 - Wikipedia

オープンソースカンファレンス広島のjapan netbsd users groupのブースでは毎年X68000/X68030を使って、すごーい！たーのしー！ことをやっているので、興味がある人は見に行ってみると変なスイッチが入ったり入らなかったりするかもしれません。
OSC2016広島 (2016/11/27) 発表スライド

インストール方法とMac版の問題

配布元のダウンロードページに
http://xm6i.org/download.html

Mac 版について

ver 0.53 から SDL2 を使用しているため、 サウンドなし版、あり版の区別はなくなりました。　
Mac OS X 10.8 でビルドし、10.11 でも動作を確認しています。 それ以外のバージョンについては分かりません。

とあったので、ダウンロードして、展開し、バイナリを実行したところ、異常終了してしまいました。

とっても困っていたところ、@LabDrunkerさんに"MacPortsを使ってGCC5を入れて、/opt/local/lib以下のlibstdc++が使われるようにしたら、動くようになりました。"という貴重なアドバイスを頂きました。

どうして、この解決方法に気づいたのか質問してみたところ、

とのご回答をいただきました。ぼんくら物理学者... だと... こいつ…かなりの切れ者...

確かにotoolを使ってxm6iがリンクしている共有ライブラリを調べてみると、/opt/loca/lib以下のlibstdc++が使われているようです。

実験として/opt/localを掘って/usr/libにシンボリックリンクをはってみましたが、xm6iが異常終了してしまいました。

これは@LabDrunkerもおっしゃっていますが、gcc5からlibstdc++ではデフォルトで新しいABIを利用するようになっているためと思われます。(そしてMac版xm6iはgcc5を使ってコンパイルされているためと思われます)

早速MacPortsから、gcc5をインストールしてみました。



問題が解決したので、XM6iが起動するようになりました!

NetBSD/x68kのインストール

早速準備が整ったので、NetBSD/x68kをインストールしてみます。

やり方は、@tsutsuiiさんのページに詳しい方法が書いてありますので、参考にしてください。
NetBSD/x68k on XM6i ver 0.41 - クロスプラットフォーム X68000/X68030 エミュレータ

インストールCD ISOイメージ

http://ftp7.jp.NetBSD.org/pub/NetBSD/iso/6.1.3/ の
iso ディレクトリ内の NetBSD-6.1.3-x68k.iso (約162MB) をダウンロードして c:\XM6i\NetBSD\ に置く。

もちろん、OSのバージョンは適宜読み替えてください。

インストールには数時間かかりますが、きっとうまくいくはず... です...

↓ちなみに失敗例

無事インストールすることが出来ました！

失敗した原因は


です。

よって、ノリでインストールしなければ、インストールに時間はかかるものの問題無くNetBSD/x68k on XM6i Mac版の環境を楽しむことが出来ます！

Mac版XM6iのネットワークの設定は

 Mac OS X 版では Nereid イーサネットエミュレーションのホスト側に bpf(4)
  を使用しており、ホストマシンを介して外部ネットワークとの通信が可能です。
  ただし Mac OS X 側の制約によりホストマシン自身との通信は行えません

とあります。

Mac版のXM6iを試すような人にパソコンを一台しか持っていない人なんていないと思いますので、問題ないと思います。

ああ・・次はpkgsrcだ...

ママー。NetBSDのRAMDISK Kernelの/dev/consoleはどこから来るの？という話

この記事は
NetBSD Advent Calendar 2016 - Qiita 24日目の記事です。
すいません、ておくれました。26日目ということにしてください...

N君がある日RS/6000にNetBSD/ofppcをインストールしようとすると奇妙な事が起こりました。

/dev/consoleが無いというエラーが出てだんまりしています...

調べてみたところ、エラーを出力しているのは
https://nxr.netbsd.org/xref/src/sys/kern/init_main.c#870
のようです。

どういうことなのでしょう?

@tsutsuiiさんにアドバイスを頂きました!

つまりユーザーランド側から/sbin/initが/dev/consoleを開いて文字の読み書きを始めようにも、/dev/consoleが無いのでカーネルが警告を出しているわけですね。
そこで疑問になるのが、RAMDISK Kernelの/dev/consoleはどうやって作っているのだろうか?という事です。

これについても@tsutsuiiさんにアドバイスを頂きました。

なるほど！/dev/consoleが出来るパターンには2パターンあるようです。

というわけで、早速調べてみました!

例えば、NetBSD/i386をCDからbootさせて、/devを見てみると...

とMAKEDEVスクリプトがあります。

また、iso-imageをマウントして中身を見てみると、MAKEDEVスクリプトがあります。

では、別のポートとしてNetBSD/alphaをCDからbootさせて、/devを見てみると...

今度はMAKEDEVスクリプトがありません。

つまり、

★NetBSD/i386は"init(8) が自力で /dev 以下を mfs でマウントして /dev/console その他を自分で作る"パターン
★NetBSD/alphaは"makefs(8) -Fのspec ファイルで定義されたデバイスファイルをファイルシステムイメージとして持っている"パターン

になるわけですね。

/sbin/initでMAKEDEVスクリプトから/dev/consoleを作っているところは
https://nxr.netbsd.org/xref/src/sbin/init/init.c?r=1.107#1647
です。

試しに下記のmakefileをいじって、-DMFS_DEV_IF_NO_CONSOLEを外してやれば、
Cross Reference: /src/sbin/init/Makefile
/sbin/initが/dev/consoleを作ることが出来ないので、下記の様になるわけです。

では、このMAKEDEVスクリプトはどこから来ているのでしょうか?

試しに
Cross Reference: /src/etc/MAKEDEV.tmpl
の

mkdev		console c %cons_chr% 0	600

をコメントしてみると、

のように
warning : no /dev/console
のエラーが出ています。

また、iso-imageをマウントしてMAKEDEVの中身を見てみると、

mkdev		console c %cons_chr% 0	600

がコメントしてあります。

(右枠がソース、左枠がiso-imageのMAKEDEV)

また、NetBSD/alphaも同じように
warning : no /dev/console
のエラーが出ています。

つまり、
"init(8) が自力で /dev 以下を mfs でマウントして /dev/console その他を自分で作る"パターンでも
"makefs(8) -Fのspec ファイルで定義されたデバイスファイルをファイルシステムイメージとして持っている"パターンでも
元ネタは
/src/etc/MAKEDEV.tmpl
だということがわかります。

では、どこで/dev/MAKEDEVスクリプトを作っているのかというと、
NetBSD/i386の場合は、
Cross Reference: /src/distrib/common/Makefile.makedev
になります。

NetBSD/alphaの場合は、/dev/以下をどこで作っているのかというと
Cross Reference: /src/distrib/common/Makefile.makedev
になります。

NetBSD/alphaの場合、
Cross Reference: /src/distrib/alpha/instkernel/ramdisk/Makefile
の

MAKEDEVTARGETS=	minimal

が
Cross Reference: /src/etc/etc.alpha/MAKEDEV.conf
で定義されていて、

makedev std bpf

のstdが
Cross Reference: /src/etc/MAKEDEV.tmpl
MAKEDEV.tmplのstdで定義されています。

したがって、NetBSD/ofppcの場合、下記のようなパッチを作れば...
gist.github.com
ほら

warning : no /dev/consoleが出なくなりました〜

でもこの記事は片手落ちです。
続きはお正月休みにでも書こうと思います。

How to use X Window System on NetBSD/alpha?

Best graphic card for NetBSD/alpha to get X running?

I will answer your question below.

The following chipset have been tested.

Tsunami


Titan

DEC Multia UDB May not work :-(

Just for more information.
AlphaStation - Wikipedia

The following graphic card have been tested.

ATI RADEON 7500(HP genuine parts)

See:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/alpha/conf/GENERIC?rev=1.357&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/radeonfb.c?rev=1.82&content-type=text/x-cvsweb-markup&only_with_tag=MAIN

ELSA GLoria Synergy(Compaq genuine parts)

See:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/alpha/conf/GENERIC?rev=1.363&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/pm2fb.c?rev=1.27&content-type=text/x-cvsweb-markup&only_with_tag=MAIN

3DLabs Oxygen VX1(Compaq genuine parts)

If your alpha station has Oxygen VX1 graphics card, please try this patch!

See:
NetBSD Problem Report #49518: I wrote Permedia3 3Dlabs Permedia 3 framebuffer console driver.(genfb driver doesn't work correct on Proformance 3)

Just for more information.
Graphic Card Compatibility List for Alpha Systems

Building the System from Source.

NetBSD-7.0.2/alpha has wrong(vely old) Xfree driver.
Please don't use it.(At least you want to run X)
The reason is because X cannot access /dev/mem in my opinion.

See:

# uname -a
NetBSD  7.0.2 NetBSD 7.0.2 (GENERIC-$Revision: 1.358.4.2 $.201610210724Z) alpha
# pwd
/usr/X11R6/bin
# ls -l
total 26694
lrwxr-xr-x  1 root  wheel       25 Oct 21 08:22 X -> /usr/X11R6/bin/XdecNetBSD
-rws--x--x  1 root  wheel  2142841 Oct 21 08:22 XalphaNetBSD
-r-xr-xr-x  1 root  wheel  2210822 Oct 21 08:22 XdecNetBSD
-r-xr-xr-x  1 root  wheel  2274112 Oct 21 08:22 Xdmx

Please try NetBSD/alpha current branch and building the System from Source.

See:
how to build netbsd-current

The following condition is correct.(At least you want to run X)

See:

# pwd
/usr/X11R7/bin
# ls -l
total 15524
lrwxr-xr-x  1 root  wheel       19 Nov 13  2016 X -> /usr/X11R7/bin/Xorg
-r-xr-xr-x  1 root  wheel    27271 Feb 21  2011 Xmark
-r-xr-xr-x  1 root  wheel  2449912 Nov 13  2016 Xnest
-rws--x--x  1 root  wheel  3481376 Nov 13  2016 Xorg
-r-xr-xr-x  1 root  wheel  2655728 Nov 13  2016 Xvfb
-r-xr-xr-x  1 root  wheel    14504 Nov 13  2016 appres

System Settings.

NetBSD/alpha current branch has been successfully installed, The system outputted an following dmesg.

ATI RADEON 7500

See:

pci1 at tsp1 bus 0
radeonfb0 at pci1 dev 7 function 0: vendor 1002 product 5157 (rev. 0x00)
radeonfb0: 64 MB aperture at 0x40000000, 64 KB registers at 0x01060000
radeonfb0: display 0: initial virtual resolution 640x480 at 32 bpp
radeonfb0: using 32 MB per display
radeonfb0: port 0: physical 1024x768 60Hz
radeonfb0: port 1: physical 1024x768 60Hz
wsdisplay1 at radeonfb0 kbdmux 1
drm at radeonfb0 not configured
tlp0 at pci1 dev 9 function 0: DECchip 21140A Ethernet, pass 2.0
ELSA GLoria Synergy

See:

usb0 at ohci0: USB revision 1.0
pm2fb0 at pci0 dev 11 function 0: vendor 104c product 3d07 (rev. 0x01)
pm2fb0: no width property
pm2fb0: no height property
pm2fb0: no depth property
pm2fb0: 8 MB aperture at 0x01000000
pm2fb0: pm2 using 1280 x 1024 in 8 bit, stride 1280
wsdisplay0 at pm2fb0 kbdmux 1: console (default, vt100 emulation)
wsmux1: connecting to wsdisplay0
isa0 at sio0
3Dlabs Oxygen VX1

See:

usb0 at ohci0: USB revision 1.0
pm3fb0 at pci0 dev 11 function 0: vendor 3d3d product 000a (rev. 0x01)
pm3fb0: no width property
pm3fb0: no height property
pm3fb0: no depth property
pm3fb0: 16 MB aperture at 0x40000000
pm3fb0: pm3 using 1280 x 1024 in 8 bit, stride 1280
wsdisplay0 at pm3fb0 kbdmux 1: console (default, vt100 emulation)
wsmux1: connecting to wsdisplay0
isa0 at sio0

Next, you have to configure X.

See:
Chapter 9. X

Modify the /etc/X11/xorg.conf settings.

radeon or glint driver does not work.
Please use wsfb driver.

See:
ftp://www.x.org/pub/xorg/X11R7.5/doc/man/man4/wsfb.4.html

Section "Device"
        Identifier  "Card0"
        Driver      "wsfb"
        BusID       "PCI:0:7:0"
EndSection

Everything is ready!

I hope that a happy X time will come around for you.

OpenBSD/sgi MPカーネルの性能の話

序論

OpenBSD/sgiのリリース6.0でIP27カーネルを使う一部の機種(TezroやOnyx350やOrigin350)にシングルノード限定ではあるものの、Multiprocessorサポートが入りました。
https://www.openbsd.org/sgi.html

Origin350を始めとしたNUMA機のカーネルのSMP化は@syuu1228さんが過去に挑戦されていた実績があります。

www.slideshare.net

@syuu1228さんはIP30カーネルを使う機種(Octane、Octane2)のカーネルのSMP化を実装された実績があります。

www.slideshare.net

@MiodVallatさんと性能テストをするという約束をしていたのですが、すっぽかしていたので、とても時間が経ってしまいましたが、(半年ほど遅れてしまいましたが)テストを行いました。


とりあえずdmesg

SGI Tezro R16000 800 MHz x 4
SGI Tezro - Wikipedia

# dmesg                                                                 
[ using 632960 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2016 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 6.0 (GENERIC-IP27.MP) #112: Thu Jul 28 18:21:48 MDT 2016
    deraadt@sgi.openbsd.org:/usr/src/sys/arch/sgi/compile/GENERIC-IP27.MP
real mem = 4294967296 (4096MB)
rsvd mem = 20643840 (20MB)
avail mem = 4205133824 (4010MB)
warning: no entropy supplied by boot loader
mainbus0 at root: Origin 350
cpu0 at mainbus0 nasid 0: R16000 CPU rev 2.2 800 MHz, R16000 FPU rev 2.2
cpu0: cache L1-I 32KB D 32KB 2 way, L2 4096KB 2 way
clock0 at mainbus0 nasid 0: int 5
cpu1 at mainbus0 nasid 0: R16000 CPU rev 2.2 800 MHz, R16000 FPU rev 2.2
cpu1: cache L1-I 32KB D 32KB 2 way, L2 4096KB 2 way
cpu2 at mainbus0 nasid 0: R16000 CPU rev 2.2 800 MHz, R16000 FPU rev 2.2
cpu2: cache L1-I 32KB D 32KB 2 way, L2 4096KB 2 way
cpu3 at mainbus0 nasid 0: R16000 CPU rev 2.2 800 MHz, R16000 FPU rev 2.2
cpu3: cache L1-I 32KB D 32KB 2 way, L2 4096KB 2 way
spdmem0 at mainbus0 nasid 0 dimm 0: 1GB DDR SDRAM registered ECC PC2000CL2.5
spdmem1 at mainbus0 nasid 0 dimm 1: 1GB DDR SDRAM registered ECC PC2000CL2.5
spdmem2 at mainbus0 nasid 0 dimm 2: 512MB DDR SDRAM registered ECC PC1600CL2.5
spdmem3 at mainbus0 nasid 0 dimm 3: 512MB DDR SDRAM registered ECC PC1600CL2.5
spdmem4 at mainbus0 nasid 0 dimm 4: 512MB DDR SDRAM registered ECC PC1600CL2.5
spdmem5 at mainbus0 nasid 0 dimm 5: 512MB DDR SDRAM registered ECC PC1600CL2.5
xbow0 at mainbus0 nasid 0: PXBow revision 3
xbridge0 at xbow0 widget 15: PIC revision 3
xbpci0 at xbridge0 bus 0: 66 MHz PCI bus
pci0 at xbpci0 bus 0
iof0 at pci0 dev 0 function 0 "SGI IOC4" rev 0x4f: irq 0, xbow irq 62
com0 at iof0 base 0x380: ns16550a, 16 byte fifo
com0: console
com1 at iof0 base 0x388: ns16550a, 16 byte fifo
com2 at iof0 base 0x390: ns16550a, 16 byte fifo
com3 at iof0 base 0x398: ns16550a, 16 byte fifo
iockbc0 at iof0 base 0x200
dsrtc0 at iof0 base 0x80000: DS1742W
ppb0 at pci0 dev 1 function 0 "TI PCI2050" rev 0x01
pci1 at ppb0 bus 1
envy0 at pci1 dev 2 function 0 "IC Ensemble Envy24PT/HT Audio" rev 0x01: irq 1, xbow irq 61
envy0: unknown 1724-based card, 2 inputs, 8 outputs
audio0 at envy0
midi at envy0 not configured
qlw0 at pci0 dev 2 function 0 "QLogic ISP12160" rev 0x06: irq 2, xbow irq 60
qlw0: nvram corrupt
qlw0: firmware rev 10.4.41, attrs 0x0
scsibus0 at qlw0: 16 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <SGI, ST373307LC, 2741> SCSI3 0/direct fixed serial.SGI_ST373307LC_3HZ6HQZS00007421QXB8
sd0: 70007MB, 512 bytes/sector, 143374744 sectors
scsibus1 at qlw0: 16 targets, initiator 0
bge0 at pci0 dev 3 function 0 "Broadcom BCM5701" rev 0x15, BCM5701 B5 (0x105): irq 3, xbow irq 59, address 08:00:69:13:ea:b8
brgphy0 at bge0 phy 1: BCM5701 10/100/1000baseT PHY, rev. 0
xbpci1 at xbridge0 bus 1: 33 MHz PCI bus
pci2 at xbpci1 bus 0
"SGI Rad1" rev 0xd0 at pci2 dev 0 function 0 not configured
ioc0 at pci2 dev 1 function 0 "SGI IOC3" rev 0x01
onewire0 at ioc0
owserial0 at onewire0 "16kb EPROM" sn 00000059b2e0
owserial0: "PCI_SIO_UFC" p/n 030-1657-003, serial MNC900
ioc0: superio irq 1, xbow irq 57
com4 at ioc0 base 0x20178: ns16550a, 16 byte fifo
com5 at ioc0 base 0x20170: ns16550a, 16 byte fifo
qlw1 at pci2 dev 2 function 0 "QLogic ISP1240" rev 0x01: irq 2, xbow irq 56
qlw1: firmware rev 8.15.0, attrs 0x0
scsibus2 at qlw1: 16 targets, initiator 7
scsibus3 at qlw1: 16 targets, initiator 7
xbridge1 at xbow0 widget 11: PIC revision 3
xbpci2 at xbridge1 bus 0: 133 MHz PCIX bus
pci3 at xbpci2 bus 0
qla0 at pci3 dev 0 function 0 "QLogic ISP2312" rev 0x02: irq 0, xbow irq 54
firmware load failed
qla0: firmware load failed
qla1 at pci3 dev 0 function 1 "QLogic ISP2312" rev 0x02: irq 4, xbow irq 54
firmware load failed
qla1: firmware load failed
xbpci3 at xbridge1 bus 1: 133 MHz PCIX bus
pci4 at xbpci3 bus 0
qla2 at pci4 dev 1 function 0 "QLogic ISP2312" rev 0x02: irq 1, xbow irq 53
firmware load failed
qla2: firmware load failed
qla3 at pci4 dev 1 function 1 "QLogic ISP2312" rev 0x02: irq 5, xbow irq 53
firmware load failed
qla3: firmware load failed
odyssey0 at xbow0 widget 12: Odyssey device has not been setup by firmware!
"Kona" revision 0 at xbow0 widget 13 not configured
vscsi0 at root
scsibus4 at vscsi0: 256 targets
softraid0 at root
scsibus5 at softraid0: 256 targets
boot device: sd0
root on sd0a (ff91e3200f2e2df7.a) swap on sd0b dump on sd0b
cpu3 launched
cpu2 launched
cpu1 launched
#

ちゃんと4CPU認識されています。

ベンチマーク1

せっかくなのでGENERIC-IP27.MPをコンパイルする時間をMPカーネルとUPカーネルで計ってベンチマークをとってみました。

MPカーネルの場合

make -j 4

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   13m05.77s real    24m17.81s user     2m02.76s system

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   13m00.37s real    24m15.41s user     2m00.92s system

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   13m01.00s real    24m15.54s user     1m59.89s system

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   13m00.40s real    24m15.03s user     1m59.35s system

-----------------------------------------------------------------------

make -j 1

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   28m36.97s real    24m13.87s user     1m22.54s system


text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   28m35.14s real    24m13.25s user     1m23.49s system

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   28m36.12s real    24m13.78s user     1m23.73s system

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   28m36.16s real    24m12.82s user     1m23.91s system

UPカーネルの場合

make

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   31m09.58s real    26m12.86s user     1m38.79s system

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   31m01.38s real    26m17.84s user     1m38.67s system


text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   31m04.14s real    26m17.53s user     1m40.29s system


text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   31m03.50s real    26m14.39s user     1m41.37s system

考察1

★このようにMPカーネルを使った場合、make -j 1とmake -j 4では処理にかかる時間が半分以下になっていることがわかります。

★また意外なことに、UPカーネルでmakeを行った場合とMPカーネルでmake -j 1を行った場合では、MPカーネルのほうが性能が良いことがわかります。(CPUを1個しか使わない場合では、MPカーネル特有のオーバーヘッドがかからないぶん、UPカーネルのほうが性能が良いのでは？と予測していたので意外でした。)

ベンチマーク2

せっかくなので他の機種でもGENERIC-IP27.MPをコンパイルする時間を計ってベンチマークをとってみました。

SGI Fuel R16000 900 MHz x 1

SGI Fuel - Wikipedia

OpenBSD 6.0 (GENERIC-IP27) #721: Thu Jul 28 16:32:25 MDT 2016
    deraadt@sgi.openbsd.org:/usr/src/sys/arch/sgi/compile/GENERIC-IP27
real mem = 4294967296 (4096MB)
rsvd mem = 20643840 (20MB)
avail mem = 4205166592 (4010MB)
warning: no entropy supplied by boot loader
mainbus0 at root: Fuel
cpu0 at mainbus0 nasid 0: R16000 CPU rev 3.0 900 MHz, R16000 FPU rev 3.0
cpu0: cache L1-I 32KB D 32KB 2 way, L2 8192KB 2 way

IP27カーネルを使用 1CPUマシンなのでUPカーネルのみ

make

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
   25m48.50s real    20m36.65s user     0m40.77s system
SGI O2+ R5000 300 MHz x 1

SGI O2 - Wikipedia

OpenBSD 6.0 (GENERIC-IP32) #639: Thu Jul 28 17:34:01 MDT 2016
    deraadt@sgi.openbsd.org:/usr/src/sys/arch/sgi/compile/GENERIC-IP32
real mem = 671088640 (640MB)
rsvd mem = 7020544 (7MB)
avail mem = 632971264 (603MB)
warning: no entropy supplied by boot loader
mainbus0 at root: O2
cpu0 at mainbus0: PMC-Sierra RM52X0 CPU rev 10.0 300 MHz, RM52X0 FPC rev 10.0
cpu0: cache L1-I 32KB D 32KB 2 way, L2 1024KB direct

IP32カーネルを使用 1CPUマシンなのでUPカーネルのみ

make

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
  139m49.04s real   127m17.12s user    10m24.63s system
SGI POWER Indigo2 R8000 75 MHz x 1

SGI Indigo² and Challenge M - Wikipedia

OpenBSD 6.0 (GENERIC-IP26) #239: Thu Jul 28 16:08:43 MDT 2016
    deraadt@sgi.openbsd.org:/usr/src/sys/arch/sgi/compile/GENERIC-IP26
real mem = 536870912 (512MB)
rsvd mem = 1064960 (2MB)
avail mem = 526106624 (501MB)
mainbus0 at root: POWER Indigo2 R8000
cpu0 at mainbus0: MIPS R8000 CPU rev 0.0 75 MHz, R8010 FPU rev 0.1
cpu0: cache L1-I 16KB D 16KB direct, L2 2048KB direct

IP26カーネルを使用 1CPUマシンなのでUPカーネルのみ

make

text    data    bss     dec     hex
6399024 123304  740132  7262460 6ed0fc
  240m49.90s real   222m52.90s user    15m03.00s system

考察2

★FuelとTezroは同じIP27カーネルを使ってテストを行ったのですが、Tezroの800Mhに比べてFuelの900Mhzは処理がかなり高速なことがわかります。これはTezroが4MBという2次キャッシュを持っているのに比べ、Fuelが倍の8MBという巨大なキャッシュを持っていることが原因だと思われます。

★75Mhzというクロックの割にPOWER Indigo2 R8000の性能が良いことがわかります。R8000も2MBという巨大なキャッシュを持っているので、キャッシュが性能を発揮しているのかもしれません。

思ったこと

考察2でも述べたようにFuelとTezroは同じIP27カーネルを使うのですが、FuelにOSをインストールする時には、MPカーネルが選択肢に出ないことに気づきました。これについて感想を述べたところ@ao_kenjiさんから以下のようなアドバイスをいただきました。

マルチノードのNUMA機のサポートってどうするんでしょうか?@tsutsuiiさんとこのような話をしたことがありますが、メモリのアクセス速度に差があるという点では一致しているものの、そもそもアーキテクチャがまったく違う次元の話でしょうし... 教えて、偉い人


結論

★今回、UPカーネルとMPカーネルでベンチマークを行い、MPカーネルで処理の高速化がかなり期待できることがわかりました。

★将来、OpenBSD/sgiのIP27カーネルがマルチノードをサポートした場合、大量のCPUがconfigureされた状態でmake -j 100などを行うと、こちらのブログの”ポテトチップス容量推移の予想”のようにmakeにかかる時間がマイナスになり、時間の逆流が始まることが予想されます。

　以上

ジャンクの価値は？

ジャンクの価値？

N君がある日TLを見ていると、とても興味深いtweetが流れてきました。


Alphaマシンなどは一般的にはジャンク品という扱いになると思います。

ジャンク品 (パーソナルコンピュータ) - Wikipediaではジャンク品（ジャンクひん、junk）とは、本来、「故障品」「不要品」「がらくた」の意味のことである。と解説してありました。

さて、一般的にジャンクと呼ばれるコンピュータの価値はいかほどなのでしょうか？

Nくんの家のジャンク

Nくんの家には足の踏み場もないほどにジャンク品のコンピュータが転がっています。
ちょっとだけ紹介してみます。みなさん、いくつご存知でしょうか？

NEC SX-8i


S-4/20LとEWS4800 430とAlphaStation DS15
GENIALstation 737
Sgi Tezro Fuel O2+ O2 Octane2 Power Indigo2 Indy Indigo
Sgi Onyx350
Sgi Power Indigo2
EWS48000 430 EWS4800 530
RS/6000 170
Alpha Server DS25
Alpha station XP1000
VAXstation 4000 Model 96
Apple PowerMac9700 Power Express
Omron Luna68K

HP c8000
AlphaStation 200 4/166

ここには写っていませんが、他にもDaystar millenniumとかNextStation Turbo ColorだとかSgiのAltix 350とかAltix 330だとかSun Ultra25とか色々あります。

"コンピュータ OSなければ ただの箱" とはよく言ったもので、OSももちろんあります。

BSD/OS


IRIX
AIX HP-UX Tru64 UNIX UX/4800 MacOS X Server SnowLeopard

特にUX/4800やTru64 UNIXやBSD/OS、Mac OS X Serverはライセンスを入力しないと動きません...
が、メディアはともかくライセンスを手に入れるのがとても難しいです。(おそらくハードを手に入れるよりも)
また、HP-UXはライセンスが無くても動きますが、OnlineJFSなどで遊ぶにはEnterprise OEのメディアを手に入れないといけません…

どうやって手に入れたのか？

東京大学などではComputer Zooなどで研究室単位？で集めているようですが、私のような個人の力では残念ながらヤフオクなどでコツコツ買い集めるしかありません…

そんな私にもコンピュータを譲ってくださる篤志家がいらっしゃいまして、@tsutsuiiからはEWS4800/430を@syuu1228からはAlphaStation 200 4/166を@impreza_gf8からはAlpha Station XP1000をいただきました。(とてもありがとうございます)

ジャンク=一期一会？

さて本題です。私のコレクション、いくらの価値があるのでしょうか？
これらのコンピューターは一般的にはヤフオクなどでオークションという形で販売されます。相場はあって無いようなものです。
値段は読めません。一期一会の出会いかもしれません。
かって、こんなことがありました...
"NECのEWS4800というコンピューターシリーズの後期のモデルにEWS4800/570EXという機種があります。このマシンはEWS4800の中では最速のマシンです。
以前一度だけオークションに出品され、私は入札したのですが、お金がなくて負けてしまいました。(最終的に7万円くらいだったかな?)
先にも後にも、このマシンをオークションで見たのはその一度だけです… 未だに痛い思い出です。"

もちろんその逆で、オークションで高値で購入したけれども、その後リースアウトしたものが大量に出回ってたたき売られることもあります…

ジャンク=Priceless？

私の母親など普通の人から見てみれば、これらのコンピューターはただの”粗大ごみ”かもしれません。
ですが、私がこれらのコンピューターを持っていたおかげで、たくさんのひとに出会い、アドバイスを頂き、勉強をし、友達ができ、とても楽しい思い出をたくさん作ることが出来ました！
togetter.com
www.slideshare.net

ですので、@LabDrunkerさんの質問にはこう答えたいと思います。
確かにそのAlphaStationは高いです。ですが、今後その値段で買える保証はどこにもありません。
もしかしたらAlphaStation XP1000などが出品されるかもしれません。
ちなみにAlphaStation DS15は12万円程度しましたが、それ以上のリターンを与えてくれました。

昔の人は言いました...
bokete.jp

でも、お金は大事だよ〜
ジャンクは用法用量を守って正しくお使いください。

それではHappy Hacking！

最後の楽園の開拓を(ちょこっとだけ)手伝った話

相変わらず謎マシンいじりが最近の趣味のN君。
家の中の"積みマシン"の電源を入れてみたところ、
珍しいCPUを積んでいる事が分かりました。

>> hinv
                   System: IP26
                Processor: 75 Mhz R8000, with FPU
     Primary I-cache size: 16 Kbytes
     Primary D-cache size: 16 Kbytes
     Secondary cache size: 2 Mbytes
              Memory size: 512 Mbytes
                 Graphics: GR5-XZ
                SCSI Disk: scsi(0)disk(1)
                    Audio: Iris Audio Processor: version A2 revision 1.1.0

MIPS R8000というCPUはMIPS系のCPUの中では、かなり変わり者です。

R8000 - Wikipedia
Power Indigo2 (R8000) - Nekochan Net

"命令キャッシュは16KBで、ダイレクトマップ方式、仮想インデックス・仮想タグ方式で、ラインサイズは32バイトである。"
とか
"TLBはデュアルポートで384エントリあり、3ウェイセットアソシアティブ方式になっている。"
とか
"ストリーミングキャッシュは外付けの1MBから16MBのキャッシュで、R8000の二次キャッシュ、R8010の一次データキャッシュとして機能する。"
とか
"マルチチップで構成されている"
とか
変態度が高くて、イカしています。

暇を見つけて以下記事のようにボチボチ遊んでいたのですが、一部問題が有るものの動き始めました。

OpenBSD/sgi、カーネルのクロスコンパイルと起動方法について - nullnilaki’s blog
OpenBSD/sgi、IP26カーネルインストールにまつわるトラブル - nullnilaki’s blog

というわけで前置きが長くなりましたが、

"最後の楽園の開拓を(ちょこっとだけ)手伝った話"と題しまして、
NetBSD Advent Calendar 2015 - Qiita
23目に寄稿させてもらいます。

自分が触り始めた時は、OpenBSDにはR8000対応のソースは入っているものの、
自分でMakefileを修正しないとカーネルは作成されない状態で、
手つかずのまま3年程度眠っていた状態でした。

また、commit logには、

IP26 kernels currently boot single-user, but don't live long; I am suspecting
a bug in the tcc cache routines, but am currently not able to find it (come
to think of it, my understanding of how this cache works could be wrong, and
of course there is no documentation for it but what can be gathered from
IRIX'  comments and defines).

と書いてある状態でした。

/src/sys/arch/sgi/localbus/tcc.c

で、まずはキャッシュが怪しいかなと思って
(特に命令キャッシュはダイレクトマップ、仮想インデックス、仮想タグ方式なので)
いろいろいじってみたのですが、R8000のマニュアルとOpenBSDのキャッシュのフラッシュ方法が同じだったのと、
カーネルのPanicのしかたがキャッシュに起因するものでは無いような気がして、
キャッシュが原因説は保留しました。

/src/sys/arch/mips64/mips64/cache_tfp_subr.S

さて、よくよく落ち方を観察すると、最終的にPanicはするのですが、
結構良いところまで行く場合が有る事に気付きました。


>> bootp()bsd.rd.IP26
Obtaining bsd.rd.IP26 from server macbook2006
3577592+722344 entry: 0xa800000008010000
ARCS64 Firmware
Found SGI-IP26, setting up.
...
Bus error (core dumped) 
starting early daemons: syslogd pflogd.
starting RPC daemons:.
savecore: /dev/sd0a: Device busy
checking quotas: done.
kvm_mkdb: can't open /dev/ksyms
panic: trap: utlbmod: invalid pte
Stopped at      0xa800000008294424:     jr      ra
0xa800000008294428:      move   zero,zero
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb>

TLB modified faultについて、調べてみると

‏@koieさん、ありがとうございます!

どうやら、ユーザーランドTLBミス時の処理が良くないのが原因なような気がします。
そこで、今度はユーザーランドTLBミス時の処理を調べる事にしました。

/src/sys/arch/mips64/mips64/exception_tfp.S

utlb_miss:
	.set	noat
	.align	4
	PRE_MFC0_ADDR_HAZARD
	DMFC0	k0, COP_0_VADDR
	MFC0_HAZARD
	DMTC0	k0, COP_0_WORK0
	MTC0_HAZARD
	PTR_SRL	k0, SEGSHIFT
	sltiu	k1, k0, PMAP_SEGTABSIZE
	beqz	k1, _inv_seg
	 NOP
	DMFC0	k1, COP_0_UBASE		# PCB_SEGTAB(CI_CURPROCPADDR(curcpu))
	MFC0_HAZARD
	PTR_SLL	k0, LOGREGSZ
	PTR_ADDU k1, k0
	PTR_L	k1, 0(k1)		# get pointer to page table
	DMFC0	k0, COP_0_WORK0		# saved COP_0_VADDR
	MFC0_HAZARD
	beqz	k1, _inv_seg
	 PTR_SRL k0, PAGE_SHIFT - 2
	andi	k0, ((NPTEPG / 2) - 1) << 2
	PTR_ADDU k1, k0
	lwu	k0, 0(k1)		# get pte
	DMTC0	k0, COP_0_TLB_LO
	MTC0_HAZARD
	TLBW
	ERET

このあたりの処理は、一刻も早く終わらせる為に全部アセンブリ言語で書かれているようです...
ウーン、わからん!呪文みたいだ...
ですが、MIPSの解説本を片手に読み進めていくと、
「なんとなく意味が分かるところ」と「わけがわからないよ」
な部分に分かれて来ました。

上記コードの赤文字の部分が「わけがわからないよ」な部分です。
やたらと"2"で引いたり、割ったり、左シフトしたりしています。
アセンブリ言語で書かれていてコードの意味は解らないし、デバックもやりづらいし、
お手上げです。

そこで思いつきました!
"一刻も早く終わらせる為に全部アセンブリ言語で書かれている"
なら
"同じような処理をCで書いている部分"を探して
参考にしてみれば良いんです。

そして、あっちこっち探して、見つけました!

/src/sys/arch/mips64/include/pmap.h

/* User virtual address to pte page entry */
#define	uvtopte(va)	(((va) >> PAGE_SHIFT) & (NPTEPG -1))

あれ?
/src/sys/arch/mips64/include/pmap.hに書かれているマクロでは
"2"で引いたり、割ったり、左シフトしたりしていません。

そこで、mips64/exception_tfp.Sを書き直してみました。

utlb_miss:
	.set	noat
...
	PTR_L	k1, 0(k1)		# get pointer to page table
	DMFC0	k0, COP_0_WORK0		# saved COP_0_VADDR
	MFC0_HAZARD
	beqz	k1, _inv_seg
-     　 PTR_SRL k0, PAGE_SHIFT - 2 
-       andi    k0, ((NPTEPG / 2) - 1) << 2 
+         PTR_SRL k0, PAGE_SHIFT 
+       andi    k0, NPTEPG - 1 
	PTR_ADDU k1, k0
	lwu	k0, 0(k1)		# get pte
	DMTC0	k0, COP_0_TLB_LO
	MTC0_HAZARD
	TLBW
	ERET

すると...

やったねたえちゃん！
しかし、起動はするものの、SIGABRTが頻発してしまうため、調査を続けることにしました。

そのうち、シルバーウィークがやってきたので、実家に帰る事にしました。

そこで転機がやって来たのです!
そのころには、Miodさん(OpenBSD/sgiのえらい人)とTwitter上でやりとりをしていたので、
メンションもらったついでに、思い切ってパッチを見てもらう事にしました。
この機会を逃すと、また、手元で眠らせてしまう気がしたので...

そしたら、あれよあれよという間に...

OpenBSD/sgiの公式?サポートになったのでした。

今まで動かなかった原因は、

cvsweb.openbsd.org

が原因でした!

これでOpenBSD/sgiはsgiのマシンに使われていたすべてのMIPS系CPUを制覇した事になります。

何故、自分がこのようなお手伝いを出来たかというと、
R8000が特殊で誰も持っていないという事につきると思います。

実際、Linux/MIPSのページには
"R8000 は現在未サポートです。これはこのプロセッサが一部の SGI の機種のみで使われた
比較的まれなプロセッサで、Linux/MIPS 開発者が誰もこのような機種を持っていない、
ということも理由の一部です。"
と書いてあります。

http://archive.linux.or.jp/JF/JFdocs/MIPS-HOWTO-9.html#ss9.8

また、他のMIPS系のCPUと構成が違うためソースの共有が出来ない部分が多数有り、余計誰も見なかったという事が考えられます。

/src/sys/arch/mips64/mips64/cache_tfp.c
/src/sys/arch/mips64/mips64/cache_tfp_subr.S
/src/sys/arch/mips64/mips64/exception_tfp.S
/src/sys/arch/mips64/mips64/tlb_tfp.S

残念ながら負荷をかけるとSIGBUSやらSIGSEGVやら発生する問題が有るのですが、
おいおい調べていきたいと思います。

まぁ、

が感想です。(日頃お世話になっているし)
それと、MiodさんにR8000の話を振られた時に、タイミングよくパッチを提出
できた事は大きかったと思います。
タイミング、大事です。

謎の/src/sys/arch/mips64/exception_tfp.Sでやたらと
"2"で引いたり、左シフトしたりしている理由は、

The 2 in the original code is log2(pte size); k0 >> PAGE_SHIFT will be 
the pte number. But in the page table, it is stored as an array of 
32-bit words, so we need to shift it to the left by 2. The original 
instructions: 
        PTR_SRL k0, PAGE_SHIFT - 2 
        andi    k0, ((NPTEPG / 2) - 1) << 2 
are equivalent to: 
        PTR_SRL k0, PAGE_SHIFT 
        andi    k0, (NPTEPG / 2) - 1 
        PTR_SLL k0, 2 
and guarantees the address is correctly aligned for the `lwu' 
instruction later.

だそうでした。

反省点は、10月11月12月とIngressにハマって、まったくマシンいじりを放置していました。

このようなアドバイスを頂いていたのに、@gussunoyoyoさん、すいません...

よく遊び、よく学べということで!

あしたは、いよいよNetBSD developerのnonakapさんの登場です！
今年もどんな記事を書いてくださるのか、大変楽しみですね！(・∀・)ﾆﾔﾆﾔ
(相変わらず中指を飛ばすコミュニケーション)

おしまい。

えっ
NetBSD Advent Calendarなのに、OpenBSDだって!?
(ﾟεﾟ)ｷﾆｼﾅｲ!!

それと、R8000関係で最近こんなことがありました。

どうやら、この変更が原因

'Re: CVS: cvs.openbsd.org: src' - MARC

らしいのですが、

+	 * Execution of the `sync' instruction is not supported by the
+	 * T-Bus and raises a machine check exception.

を疑問に思いました。

バスから見てCPUの命令ってどういう風に見えるんでしょうね?
おしえてつついさ〜ん!

参考文献など:
はじめて読む MIPS(リローデッド)
OpenBSD/sgi on octane2 - exception.S・tlbhandler.SにおけるGET_CPU_INFO()とコンテキスト保存、割り込みの話 - かーねる・う゛いえむにっき

謝辞:
いつもtwitterでふぁぼってくださる皆様
なまあたたかい目で見守ってくださるつついさんをはじめとしたNetBSD関係者の方々

追加:
つついさんにきいてみたところ、下記のような回答でした。