HN 日本語サマリー

← 一覧へ戻る
プログラミング

OpenBSD Stories: 奇妙な中世のデバイス

OpenBSD Stories: Strange Medieval Devices (miod.online.fr)

77 pointsby zdw16 コメント

要約

この記事は、1970年代から80年代にかけて高性能・大容量ストレージとして利用されていたSMDディスクについて解説しています。その物理的な大きさ、重量、インターフェースの特徴を説明し、著者がOpenBSD開発のためにSun-4/260サーバーとSMDディスクを入手し、セットアップした経験を詳細に語っています。

全文翻訳

Strange Medieval Devices

1970年代後半から1980年代にかけて、高性能・大容量ストレージの最良の選択肢は、いわゆるSMDディスクでした。

SMDインターフェースは、5年間の作業を経て、ついに1982年にANSI X3.91M-1982として標準化され、その後1987年に改訂されました。この改訂版はBitsaversで見つけることができます。

1980年代には、ESDI（1984年標準化）やSCSI（1986年標準化）のような他のストレージ技術も登場しましたが、最も大容量のディスクはすべてSMDインターフェースを使用していました。

SMDディスクは当初11インチプラッターを使用し、後に8インチになりました。公称速度は3600rpm、つまり毎秒60回転（ただし、富士通は後に標準から外れて一部のドライブを3961rpmでさらに高速に回転させました）であったため、これらのディスクを回転させるにはかなりの電力が必要でした（そして、電気料金の請求書を見たときに気づくように、回転を維持するためにはより少ない電力で済みました）。

これらのディスクは、たとえ2つでなくても、死んだロバと同じくらいの重さがありました。8インチモデルは一人で慎重に運ぶことができましたが、11インチディスクの移動には通常、何らかの台車が必要でした。

［画像］
SCSI標準ドキュメント（クリックすると拡大表示されます）。

そのため、Sun MicrosystemsがハイエンドサーバーやワークステーションにSMDディスクとXylogicsコントローラーを搭載して出荷していたのも不思議ではありませんでした。

［画像］
Xylogics 451 Multibusコントローラーボード（中央）が、下部のMultibus-to-VMEコンバーターに接続されています（クリックすると拡大表示されます）。
ESDIと同様ですが、SCSIやより現代的なストレージインターフェースとは異なり、SMDインターフェースにはコマンドケーブルとデータケーブルが別々にあります。
コントローラーによっては、コマンドケーブルはすべてのディスクをデイジーチェーンで接続するか、ディスクごとにコントローラーに直接接続された専用のコマンドケーブルがあります。
データケーブルは独立しており、常にコントローラーとディスクを直接接続します。
451は4台のディスクを駆動できますが、Sunのバージョンではコマンドケーブル（中央）と4本のデータケーブルのうち2本しか配線しないため、2台のディスクしか使用できません。
Sunのコネクタの選択により、コマンドは2つの小さなケーブルに分割されます。

これらのシステムがホビイストの地下室に持ち込まれた頃には、大容量SCSIドライブが登場していました。私は2000年代初頭に、私のSun-3/260で2GBのMicropolis 1924 5インチ1/4 SCSIディスクを使用していました。私の知る限り、SMDディスクドライブの最大容量はわずか1.25GBで、そのSCSIディスク容量の3分の2未満でした。

2000年にOpenBSD/sun3で作業を始めたとき、私はSMDドライブを持っていなかったので、Xylogicsドライバーをテストすることができませんでした。

これは2001年の夏に変わりました。前年の夏に、私はSMDディスクキャビネットの隣に、それに合うフォームファクターの、廃止されたSun-4/260キャビネットを見つけました。それが何であるかを認識した後、私はその状態について問い合わせ、適切な人々に説得するのに丸1年かかり、私の車をその部屋の近くに駐車し、両方のエンクロージャーをトランクに移動させることができました。

Sun-4/260には何が入っているのか、とあなたは尋ねるかもしれません。4/200シリーズはSunが最初に販売したSPARCシステムでした。VMEエンクロージャーの実際のサイズに応じて、12スロットの大型デスクトップキャビネットに入った4/260か、19インチラックの半分を占め、この構成で16個のVMEスロットを可能にするラックマウント可能な4/280でした。

しかし、マザーボードは同じで、16.67MHzのSPARCプロセッサーとその浮動小数点演算ユニットを備えた大型（9U）の正方形ボードでした。2つのシリアルポート、Sun Type 3キーボード用の統合キーボード・マウスポート、モノクロ高解像度（1600x1200）フレームバッファ、およびEthernetインターフェースを備えていました。

［画像］
Sun-4/200ボード（クリックすると拡大表示されます）。
左側のCPUチップ用のZIFソケットに注意してください。

しかし、オンボードメモリはありませんでした。メモリはVMEボードとしてインストールされ、CPUボードともSun独自の「P2」バスで通信し、メモリへのアクセスを高速化し、VMEバスの他の部分とバス帯域幅を共有しないようにしました。最大4枚のメモリボードをインストールでき、8MB、16MB、または32MBのバリエーションがあったため、最大128MBの物理メモリが可能でした。

ストレージコントローラーもVMEボードとして追加されました。ほとんどのシステムには、少なくともSCSIコントローラーがスロット7にあり、内部ドライブベイを処理していました。これは、パリティ信号を正しく処理できず、接続されているすべてのデバイスで無効にする必要があった非常に限定的な自作「Sun-2」scコントローラーか、そのような制限のない、わずかに優れたNCR5380ベースの「Sun-3」siコントローラーでした。

通常、スロット8には別のコントローラーが追加されました。外部コネクタを備えた別のSCSIコントローラー（外部SCSIデバイスを接続できるようにするため）、またはSMDコントローラー（場合によっては2つ）でした。

［画像］
ハイエンドのXylogics 7053 VME（9U）コントローラーボード（クリックすると拡大表示されます）。
このコントローラーは4台のディスクを駆動できますが、Xylogics 451とはバックプレートのコネクタが異なるため、異なるケーブルが必要です（残念ながら私は持っていません）。
モデル7053は、より小型の（6U）VMEボードとしても存在し、古いSilicon GraphicsシステムやMotorolaなどの他のVMEシステムで使用されます。
この小型サイズでは、モデル753として知られ、（私が適切なケーブルを持っていない）シールド付き高密度コネクタを使用しています。Sub-D*（https://en.wikipedia.org/wiki/D-subminiature）の代わりに。

シャーシ内のさまざまなVMEスロット間の微妙な違いにより、Sunは各ボードを配置する推奨場所と、適切な割り込み配信のためにVMEバックプレーンジャンパーを構成する方法について、cardcage slot assigment and backplane configuration procedures（Bitsaversへのリンク）という特定の маニュアル を作成しました。これは、最盛期には100ページを超える表と脚注に成長しました。

［画像］
前述のマニュアル（クリックすると拡大表示されます）。

自宅でそのマシンをセットアップしたとき、セルフテストでメモリボードの1枚が故障していると報告されました。これがこのマシンがサービスから外された理由の1つかもしれません（そして、おそらく電気料金と限られた処理能力も）。しかし、4枚の16MBメモリボードが搭載されていたため、それを取り外しても48MBで作業を続けることができました。

ストレージキャビネット内の2台のSMDディスクのうち、どちらも生の（フォーマットされていない）容量は約368MBでしたが、フォーマット後の容量はわずか280MBでした。動作しているように見えたのは1台だけでした。

故障したメモリボードを取り除き、そのうち2枚を当時より重要だったSun-3/260に移動した後、ついにマシンをセットアップすることができました。

Date: Sun, 15 Jul 2001 05:05:25 +0000
From: Miod Vallat
To: dmesg@openbsd.org
Subject: sun 4/260

Wow, I added SMD and scsi disks to the diskless 4/260. Still slow as
hell, but I don't care, I have a reputation to preserve.

Kernel is SUN4 from 07/13/2001 with my dmesg fix that mickey commited
later.

Miod

OpenBSD 2.9-current (SUN4) #2: Sun Jul 15 04:32:56 GMT 2001
    root@tekumel:/src/current/src/sys/arch/sparc/compile/SUN4
real mem = 16752640
avail mem = 13221888
using 102 buffers containing 835584 bytes of memory
bootpath: /vmes0/xyc0/xy@0,0
mainbus0 (root): SUN-4/200 series
cpu0 at mainbus0: MB86900/1A or L64801 @ 16.670 MHz, MB86910 or WTL1164/5 FPU
cpu0: 128K byte write-back, 16 bytes/line, sw flush cache enabled
obio0 at mainbus0
oclock0 at obio0 addr 0xf3000000 delay constant 6
eeprom0 at obio0 addr 0xf2000000
memreg0 at obio0 addr 0xf4000000
zs0 at obio0 addr 0xf1000000 pri 12, softpri 6
zs0a: console i/o
zs1 at obio0 addr 0xf0000000 pri 12, softpri 6
bwtwo0 at obio0 addr 0xfd000000: bwtwo, 1152 x 900
bwtwo0: attached to /dev/fb
ie0 at obio0 addr 0xf6000000 pri 6 address 08:00:20:00:c8:78, type onboard
vmel0 at mainbus0
vmes0 at mainbus0
xyc0 at vmes0 addr 0xffffee40 vec 0x48 pri 3: Xylogics 450/451
xy0 at xyc0 drive 0: ready (drive type 1)
xy0: <CDC EMD 9720 cyl 1147 alt 2 hd 10 sec 48>, pcyl 1149
xy0: 268MB, 1147 cyl, 10 head, 48 sec, 512 bytes/sec
xy1 at xyc0 drive 1: off-line
si0 at vmes0 addr 0xff200000 vec 0x40 pri 3
si0: options=1<DMA>
scsibus0 at si0: 8 targets
sd0 at scsibus0 targ 0 lun 0: <EMULEX, MD21/S2     ESDI, A00> SCSI0 0/direct fixed
sd0: 312MB, 1224 cyl, 15 head, 34 sec, 512 bytes/sec, 640500 sec total
sd1 at scsibus0 targ 0 lun 1: <EMULEX, MD21/S2     ESDI, A00> SCSI0 0/direct fixed
sd1: drive offline
st0 at scsibus0 targ 4 lun 0: <, , > SCSI1 1/sequential removable
st0: rogue, drive empty
led0 at mainbus0
root on xy0a
rootdev=0x300 rrootdev=0x900 rawdev=0x902
ie0: TDR detected an open 9472 clocks away

そのマシンの処理能力の限界と、電源を入れたときの巨大なシャーシファンの騒音を考えると、私はそれほど頻繁には使用しませんでした。特定のマザーボードで何かをテストする必要がある場合にのみ、再び電源を入れ、最新のOpenBSDバージョンにアップグレードし、別のマシンでコンパイルされた新しいカーネルをテストしました。sun4クラスのマシンを必要とするテストは、通常、25MHzで動作するSun-4/330で行われました。このマシンは消費電力も少なく、80MB（8x4MB SIMMのオンボード32MBと、48x1MB SIMMのVME拡張ボード）に到達するためにメモリ拡張ボードを購入していました。

［画像］
前述のメモリボードとその48個のSIMM（クリックすると拡大表示されます）。
残念ながら、4MB SIMMは受け付けません。

Sun-4/200およびSun-4/100マザーボードは、他のSPARCシステムと比較して、不揮発性メモリとしてIntersil EEPROMチップを使用しているという点で特別です。他のすべてのSPARCシステムが悪名高い MostekバッテリーバックアップSRAMチップを使用しているのとは対照的です。そのため、Intersilドライバーとの後方互換性のない回帰がないことを確認するために、消費電力の少ないSun-4/110でも同様のカーネル変更をテストできました。

そのため、sparcコンソールオーバーホール作業の一部としてVME cg2フレームバッファに取り組んだ時期を除き、このマシンは2年に約数時間しか稼働する機会がありませんでした。

ある時点で、そのオンボードEthernetインターフェースが故障し、送受信ができなくなりました。マザーボードに目に見える損傷はなく、Ethernetヒューズも切れていなかったので、Intel 82586 Ethernetコントローラー、または（より可能性が高い）マンチェスターエンコーダーのような関連信号コンバーターのいずれかの半田付けされたICが誤動作していた可能性が高いです。

これにより、マシンは数年間使用できなくなりました。しかし、2011年にスウェーデンのPeter Erikssonからリサイクル行きだった大量のVMEボードを救出し、OpenBSD開発者のJohan M:son Lindmanがそれらを私の元へ輸送する手配をしてくれました。そのロットの一部には、2枚のIntel 82586ベースのEthernetボード（Sun部品番号501-1153）が含まれていました。これにより、私の4/260は再びネットワーク経由で通信できるようになりました。

［画像］
Intel Multibus Ethernetボードが、Multibus-to-VMEコンバーターに接続されています（クリックすると拡大表示されます）。

2010年秋にOrgerusに引っ越した後、そのマシンは、新しく追加されたEthernetボードが機能し、マシン全体が元通りになることを確認した以外は、まったく使用していませんでした。しかし、2015年初頭、私は、その（25年以上前の）標準的な年齢にもかかわらず、まだ生きていることを確認するためだけに、再びマシンを試すことにしました。

システムはまだ起動しただけでなく、マシンを入手した日からSMDデータケーブルの1本を誤って接続していたことも判明しました。ケーブルを正しく接続すると、死んでいると思っていた2台目のSMDドライブが動作していると報告されました。

xyc0 at vmes0 addr 0xffffee40 vec 0x48 pri 3: Xylogics 450/451
xy0 at xyc0 drive 0: ready (drive type 1)
xy0: <CDC EMD 9720 cyl 1147 alt 2 hd 10 sec 48>, pcyl 1149
xy0: 268MB, 1147 cyl, 10 head, 48 sec, 512 bytes/sec
xy1 at xyc0 drive 1: ready (drive type 3)
xy1: <Fujitsu-M2333 cyl 821 alt 2 hd 10 sec 67>, pcyl 823
xy1: 268MB, 821 cyl, 10 head, 67 sec, 512 bytes/sec

この予期せぬ改善により、私はもう少しシステムをいじり、再インストールする気分になりました。ディスク容量が倍になったからです。しかし、再インストールした後、マシンは起動しなくなりました。

そして、その理由を突き止めるのにかなりの時間がかかりました。

PROMモニターは、ディスクパーティションの最初の8KBに書き込まれた最初のステージブートブロックバイナリを正しくロードしました。最初のステージブートブロックは、サイズが限られているため、ディスクセクター（実際にはブロック番号）の埋め込みリストから2番目のステージブートブロックをロードし、それに制御を転送するのに十分な機能しか持っていません。2番目のステージブートブロックは、そのような深刻なサイズ制限がないため、ファイルシステムを理解し、ファイル名や場所に関係なくカーネルファイルをロードできます。

2番目のステージブートブロックを含むセクターを読み取ろうとすると、あいまいな「xy: error A」というメッセージが表示されて失敗しました。これはブートブロックのどの出力とも一致せず、PROMモニター自体から来ているようでした。

もちろん、これはネットワークブートや古いブートブロックの再インストールでは回復できないものでした。少なくとも私はそう思っていました。

しかし、奇妙なことに、古いバージョンのブートブロックを再インストールしようとしても役に立たず、次にディスクから起動しようとしたときも同じエラーメッセージが表示されました。

古いPROMモニターには簡単なデバッグ機能がないため、PROM呼び出しがこのエラーメッセージを引き起こすポイントを絞り込む最初のステップは、最初のステージブートローダーに余分なコードを追加して、エラーが発生するまでにどこまで実行されたかを知ることでした。

しかし、サイズ制限のため、printfデバッグで詳細なメッセージを表示するのは簡単ではありません。なぜなら、そうすると8KBの領域がオーバーフローしてしまうからです。

そこで、最初のステージブートブロックに一時的に余分な、しかし簡潔な出力を追加し、他のメッセージを単一の文字に縮小して補いました。これにより、最初のディスクI/O操作まで実行されたことを把握できました。これらの余分なメッセージを削除し、ディスクI/Oルーチンに余分なコードを追加したところ、PROMが有効なセクター番号でディスクの16KBチャンクを読み取るように要求し、その操作が失敗したことが示されました。

しかし、私のセットアップでは何も変わっていませんでした！
あるいは、変わっていたのでしょうか？

マシンを再インストールしたことで、ディスク上に新しくクリーンなファイルシステムが作成されました。インストールプログラムによってディスクの先頭に配置された最初のステージブートローダーコードは、2番目のステージブートローダーを取得するために、ファイルシステムのブロックをロードするための有効なリストを埋め込むように内容が変更されていました。これらのブロックの各サイズは、最初のステージブートローダーイメージにも書き込まれるファイルシステムのブロックサイズになります。

私が最初にこのマシンにOpenBSDをインストールしたとき、ファイルシステムのデフォルトブロックサイズは8KBでした。これは、FreeBSDでの同様の変更に続いて、2003年7月に16KBに変更されました。

これにより、最初のステージブートローダーが以前の8KBではなく16KBを読み取ろうとした理由が説明されます。しかし、これは操作が失敗した理由を説明しませんでした。しかし、それは良いヒントでした。

PROMモニターには独自のI/O操作サイズ制限があり、その制限は驚くべき値である8216バイト（したがって、8KB、または8192バイトよりわずかに大きい）であることが判明しました。さらに、それはその値を公開されている（そして文書化された）データ構造の1つで宣伝しています。したがって、私がする必要があったのは、ブートローダーコードが行うI/O要求のサイズをその制限にクランプし、完全なデータを読み取るために必要なだけ多くの短い読み取りを実行させることでした。単一のI/O要求が常に十分であると仮定するのではなく。

この簡単な修正により、そのマシンで動作するブートブロックを再び使用できるようになりました。

残念ながら、2台のSMDディスクを使用できるようになった喜びは長くは続きませんでした。最初のディスクはすぐにセクター不良を発生させ始め、I/Oエラーを引き起こしました。

現代のディスクでは、セクター不良の処理（数が多すぎない限り）は、ディスク上のコントローラー自体によってバックグラウンドで自動的に行われます。それにはスペアセクターのリストがあり、セクター不良が見つかると、I/Oはそのスペアセクターにリダイレクトされます。スペアセクターがなくなると、コントローラーはエラーを報告するしかなくなり、ディスク交換の計画を立てる必要があります。

SMDディスクにもこのための規定がありますが、ドライバーが初期化時にセクター不良リストとその再配置された位置をロードし、新しいセクター不良が検出されたときにそれを管理（追加）する責任があります。

Xylogicsコントローラーのドライバーのそのコードパスは、ほとんどテストされていなかったか、まったくテストされていなかったため、多くの問題と追加のエラーメッセージを引き起こしました。当時の他の開発者へのメールで報告されたように、それは次のとおりです。

Date: Sun, 11 Jan 2015 19:44:22 +0000
From: Miod Vallat
To: David Gwynne, Matthew Dempsky
Subject: bufq, disksort, SMD disks, the universe, and everything

So, as you might have guessed from my recent commits, I've been
tinkering with my Sun 4/260 system with SMD disks again.

I have finally found that annoying boot blocks bug which would cause
booting the miniroot in xy0b to work, but booting the installed system
from xy0a to fail with the PROM printing ``xy: error A".

[...]

However, when I installed onto xy0a (lazy man's setup: only `a' and `b'
partitions), I got a lot of ``new'' I/O errors (by ``new'', I mean that
I did not experience them the last time I installed onto this disk,which unfortunately was in january 2009, 5 years ago, with xy.c r1.41.)

The disk being:
xyc0 at vmes0 addr 0xffffee40 vec 0x48 pri 3: Xylogics 450/451
xy0 at xyc0 drive 0: ready (drive type 1)
xy0: <CDC EMD 9720 cyl 1147 alt 2 hd 10 sec 48>, pcyl 1217
xy0: 268MB, 1147 cyl, 10 head, 48 sec, 512 bytes/sec

and the label being:
# disklabel xy0
# /dev/rxy0c:
type: SMD
disk:
label: CDC EMD 9720 cyl
duid: 51d31bad235f6a87
flags: vendor
bytes/sector: 512
sectors/track: 48
tracks/cylinder: 10
sectors/cylinder: 480
cylinders: 1147
total sectors: 550560
boundstart: 0
boundend: 550560
drivedata: 0

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
  a:           491520                0  4.2BSD   2048 16384    1 # /mnt
  b:            59040           491520    swap
  c:           550560                0  unused
#

... one would expect that the valid disk sectors go from C/S/H 0/0/0 to
1146/48/9. Note that I am using C/S/H instead of C/H/S because this is
how xy(4) reports its error at the moment (fixing this is on my list
now).

So anyway, during install, which is supposed to only touch xy0a and
never use swap until MAKEDEV time, I got a lot of errors:

xy0a: write 1147/46/0: Illegal head
xy0a: write 1147/45/9: Illegal head
xy0a: write 1147/45/8: Illegal head
xy0a: write 1147/45/7: Illegal head
xy0a: write 1147/45/6: Illegal head
xy0a: write 1147/45/2: Illegal head
xy0a: write 1147/45/4: Illegal head
xy0a: write 1147/45/3: Illegal head
xy0a: write 1147/44/5: Illegal head
xy0a: write 1147/44/6: Illegal head
xy0a: write 1147/44/4: Illegal head
xy0a: write 1147/44/0: Illegal head
xy0a: write 1147/47/9: Illegal head
xy0a: write 1147/47/8: Illegal head
xy0a: write 1147/47/7: Illegal head
xy0a: write 140/6/7: Header not found [still trying, new error=Header not found]
xy0a: write 140/6/7: Header not found [still trying, new error=Header not found]
xy0a: write 140/6/7: Header not found [still trying, new error=Header not found]
xy0a: write 140/6/7: Header not found [still trying, new error=Header not found]
xy0a: write 140/6/7: Header not found
xy0a: write 1147/47/5: Illegal head
xy0a: write 1147/47/1: Illegal head
xy0a: write 1147/47/0: Illegal head
xy0a: write 1147/46/8: Illegal head
xy0a: write 1147/46/6: Illegal head
xy0a: read 1147/45/4: Illegal head
xy0a: read 1147/45/4: Illegal head
xy0a: read 1147/45/4: Illegal head
xy0a: read 1147/45/4: Illegal head
xy0a: read 1147/45/4: Illegal head
xy0a: read 1147/45/4: Illegal head
xy0a: read 1147/45/4: Illegal head
xy0a: read 1147/45/4: Illegal head
xy0a: read 1147/45/4: Illegal head
xy0a: read 1147/45/4: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/45/9: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
xy0a: write 1147/43/9: Illegal head
xy0a: write 1147/43/8: Illegal head
xy0a: write 1147/43/7: Illegal head

While 140/6/7 is likely a newborn bad sector, all the other messages
refer to bogus disk positions.

Note however, that it reports ``Illegal head'', not ``Illegal cylinder
address''. So it might be the case that the last cylinder does not
support all the heads, and that our naive computation of the disk space
as `#cylinders * #heads * #sectors' is wrong, but that's a topic for
another day.

What worries me is that, while installing onto xy0a which is only
spanning about 85% of the disk, I see I/O errors referring to the very
end of the disk.

Which in turn, makes me believe that the changes to xy.c after 1.41 -
which I promised I would test, and am only finally testing now, after
getting an extra Ethernet board as the onboard Ethernet is no longer
working - introduce regressions in the way geometry of the actual I/O is
computed, but only in corner cases (since many binaries have been
installed correctly), such as, during boot:

openssl: generating isakmpd/iked RSA key... xy0a: read 1147/45/9: Illegal head
failed.
xy0a: read 1147/46/0: Illegal head
xy0a: read 1147/46/0: Illegal head
cp: /etc/iked/private/local.key: Input/output error
xy0a: read 1147/46/0: Illegal head
chmod: /etc/iked/private/local.key: Input/output error
xy0a: read 1147/46/0: Illegal head
cp: /etc/iked/local.pub: Input/output error

I will try to dissect the xy.c changes in order to figure out what goes
wrong. But if you guys have ideas of debug stuff to enable or things to
check, I'd love to hear about them.

You have to understand that I want to be able to brag I am booting a
1988 sparc machine off an SMD disk, in 2015. So getting rid of SMD
support is not an option yet (-;

いくつかの調査の後、これらの無意味なディスクアドレスを引き起こしたいくつかのバグを発見しました。それらはコードの最初から存在しており、20年近く経過していました。

Date: Mon, 12 Jan 2015 17:08:48 +0000
From: Miod Vallat
To: David Gwynne, Matthew Dempsky
Subject: Re: bufq, disksort, SMD disks, the universe, and everything

Nevermind, it turns out this is a 19 years old bug (from day one) in the
xy driver. Fix coming soon.

そこで、私はそれらを容赦なく修正しました。

さらに微妙なバグがまだその領域に潜んでおり、ファイルシステムの破損が遅く発生し、最終的にはカーネルパニックを引き起こしました。これは2日後に修正されました。

そして、その領域で作業している間に、disklabel -A を使用したSMDディスクの自動パーティショニングを可能にするための必要なioctlハンドラーを実装しました。

これは見過ごされませんでした。

<mlarkin> miod: "As a result, this makes disklabel -A now work on SMD disks."
<mlarkin> im not sure i want to ask if you still have these
<dlg> he does
<dlg> the best thing is my bufq changes to those drivers didnt break them
<dlg> they were already broken and he's fixing 19yo bugs in them
<tedu> i was amused to learn there are not-scsi sun4 disks
<deraadt> so those drives are about 100x the weight of a laptop drive, and if
          you are lucky they can fit one src tree.

（この最後のコメントは、現在[2026年]では重く響きます。OpenBSDのsrcツリーは現在、1.8GBという肥大化した重さで、400MBのllvmコードと550MBのLinux DRMコードを含んでいます。）

セクター不良処理コードが修正された後も、セクター不良の増加が懸念されました。古いSMDディスクの取り扱いに関する一つの古い規則は、物理的に移動した場合は再フォーマットすることが強く推奨されるということです。なぜなら、輸送中にヘッドの配置がわずかに変化する可能性があるからです（洗濯機とは異なり、SMDディスクは通常、輸送のために「格納」モードにすることはできません）。

しかし、ハードウェアを入手して以来、何度か引っ越したにもかかわらず、私は一度もこれを実行していませんでした。

OpenBSD（またはNetBSD）にはSMDディスク用の低レベルフォーマットプログラムはありません。そのため、古いSunOS 4.1を起動して、そのformatプログラムを実行し、両方のSMDディスクを低レベルフォーマットしました（ディスクあたり1時間以上かかりました）。

残念ながら、低レベルフォーマット後も、CDC 9720ディスクはますますセクター不良を発生させ、信頼性が低下しました。

2016年後半に再び引っ越し、さらに低レベルフォーマットを試みましたが、敗北を認め、2017年4月にそのディスクを引退させました。

その当時、そのディスクの分解写真をソーシャルネットワーク（青い鳥をロゴに使っているもの）で共有しましたが、これは今では失われています。いくつかの写真は、あなたの正当な好奇心を満たすために以下に見つけることができます。

［画像］
ディスクエンクロージャー（スケール用にセンチメートル定規付き）（クリックすると拡大表示されます）。

［画像］
ラベルのクローズアップ（クリックすると拡大表示されます）。
368MBは生の容量であり、フォーマット済み（したがって使用可能）容量ではありません。そこからファイルシステムのオーバーヘッドも差し引く必要があります。

［画像］
エンクロージャーに貼られた「設定ログ」シート。1988年春に製造されたことを示しています（クリックすると拡大表示されます）。

［画像］
ディスクを開いた状態（クリックすると拡大表示されます）。
ディスクプラッターのオレンジ色に注意してください。1990年代初頭には、すべてのディスクプラッターが灰色になりました。

［画像］
ヘッドアセンブリ（定規付き）（クリックすると拡大表示されます）。

［画像］
ヘッドの別のビュー（クリックすると拡大表示されます）。

［画像］
ヘッドを取り外したディスクシャーシの底面（クリックすると拡大表示されます）。
この茶色のプラスチック部品はブレーキです。シャーシの下には、大きなコンデンサとスプリングを備えた小さな電子基板があり、スプリングはブレーキを回転軸から離しておきます。ディスクへの電源が切れると、コンデンサはゆっくりと放電し、数秒後、スプリングを圧縮している電磁石は無効になり、スプリングが解放されてブレーキが作動し、回転スピンドルを急速に減速させます（慣性のため、停止するのに数分かかる可能性があります）。

そのディスクについてさらに知りたい場合は、操作マニュアルがBitsaversで見つかります。3-2ページ（PDF 51ページ）には、電流使用量の経時変化グラフがあり、ディスクを起動するために、一時的に最大6アンペア（https://en.wikipedia.org/wiki/Ampere）が必要になる場合があることが示されています。

これらの修正とディスク1台の損失の後、私はそのマシンであまりいじりませんでした。

しかし、まだ取り組むべきプロジェクトが1つ残っています。SunOS Ciprico RimfireドライバーをBSDにポートすることです。

Cipricoは高性能ディスクおよびテープコントローラーを製造していました。彼らのSMDコントローラー「Rimfire」は、（コントローラー自体に512KBのキャッシュメモリとそれを満たすための十分なリードアヘッドのおかげで）Xylogicsコントローラーよりも大幅に高速でした。Cipricoはハードウェアのドライバーソースコードを公開しました（今回は、このソースコードはBitsaversではなく、Peter KochのSun-3 Zooのダウンロードページで見つけることができます）。

SunOS 4は4.2BSDに非常に近いため、IOMMUのDMA転送（Sun-4システムでは「DVMA」と呼ばれる）の処理を除けば、ドライバーの移植は比較的容易になるはずです。

以前から長らくこれを試すことができませんでした。なぜなら、以前入手したCipricoボードに必要なケーブルを持っていなかったからです（Xylogicsボードとは異なるバックパネルコネクタを使用しています）。数年後、Rimfire 3224の物理コネクタがMultibus Xylogics 451のコネクタと同一であることに気づき、451自体とVMEバックプレーンの間で見つかるSunの中間コネクタケーブルを再利用できることがわかりました。（同様に、Rimfire 3223はXylogics 7053と同一のコネクタを持っています。）

［画像］
Ciprico Rimfire 3224ボード、最大4台のSMDドライブをサポート（クリックすると拡大表示されます）。

別の便利な機能として、Rimfireのモデル3223および3224（私のものなど）は、Xylogics 451互換モードでジャンパー設定でき、ドライバーが引き継ぐまで（これは上記の写真の左下にあるJSUNジャンパーで、黄色いキャップでジャンパーされています）、本物のXylogicsデバイスのように動作します。これにより、Sun PROMはこのコントローラーをサポートしていませんが、Rimfire接続ディスクから起動できます。

SMDコントローラーを別のモデルに交換する場合、新しいコントローラーに接続されているすべてのドライブを再フォーマットすることが強く推奨されます。これは、すべてのSMDコントローラーマニュアルで読んだことであり、したがって、異なるコントローラーでディスクを読み取ること（ましてや書き込むこと）を防ぐ、各ディスクフォーマットにはコントローラー依存の機能があるはずだと推測します。

RimfireをシステムのXylogicsの代わりにインストールした後、確かにそこから起動できなくなりました。SCSIディスクからSunOSを起動しても、ディスクが読み取れないことが示されました。フォーマットユーティリティを起動し、さらに低レベルフォーマットを実行したところ、ディスクは再び使用可能になりました。

技術的な注意点（安全に無視できます！）（クリックして展開または折りたたむ）

SCSIのようなより現代的なストレージインターフェースとは異なり、SMDはコントローラーがデバイスに物理ジオメトリを問い合わせる方法を定義していません。

Ciprico Rimfireは、ジオメトリを取得するために「Interrogate Disk」コマンドをサポートしていますが、これはシークコマンドを発行し、ディスクがエラーを報告するまでシリンダーヘッドとセクター番号の値を増やしていくことによって行われます。これは非常に遅い方法です（シリンダー番号は最大値を絞り込む最初のステップとして128ずつ増やされます）。また、1024シリンダー以上のディスクでは失敗することが文書化されています。なぜなら、SMD標準の最初の改訂ではシリンダー番号に10ビットしか許可されていなかったため、1024シリンダーの制限があったからです（したがって、1147シリンダーのCDC 9720ディスクでは機能しなかったでしょう）。

この制限のため、システムが行う最初のことは、SMDドライブをフォーマットした後、ジオメトリを最初のセクターに書き込むことです（シリンダー#0、ヘッド#0、セクター#0を使用して、シリンダー数、ヘッド数、セクター数が実際にはいくつであるかを知らなくても、最初のセクターへのアクセスを要求することは常に可能です）。

もちろん、フォーマットプログラムは操作対象のディスクのジオメトリを知る必要があり、フォーマットプログラムが書かれた時点で購入可能だったSMDドライブの短いリストからしか選択できません。これらのパラメータはよく知られています。

SunOSでは、これらのパラメータは/etc/format.datのテキストファイルにありましたが、異なるファイルをformatに渡すこともできます。以下は、既知のSMDドライブのリストです。

#
# This is the list of supported disks for the Xylogics 450/451 controller.
#
disk_type = "Fujitsu-M2312K" \
        : ctlr = XY450 : fmt_time = 4 \
        : ncyl = 587 : acyl = 2 : pcyl = 589 : nhead = 7 : nsect = 32 \
        : rpm = 3600 : bpt = 20480 : bps = 621 : drive_type = 1

disk_type = "Fujitsu-M2284/M2322" \
        : ctlr = XY450 : fmt_time = 4 \
        : ncyl = 821 : acyl = 2 : pcyl = 823 : nhead = 10 : nsect = 32 \
        : rpm = 3600 : bpt = 20480 : bps = 621 : drive_type = 2

disk_type = "Fujitsu-M2351 Eagle" \
        : ctlr = XY450 : fmt_time = 4 \
        : ncyl = 840 : acyl = 2 : pcyl = 842 : nhead = 20 : nsect = 46 \
        : rpm = 3961 : bpt = 28160 : bps = 595 : drive_type = 0

disk_type = "Fujitsu-M2333" \
        : ctlr = XY450 : fmt_time = 4 \
        : ncyl = 821 : acyl = 2 : pcyl = 823 : nhead = 10 : nsect = 67 \
        : rpm = 3600 : bpt = 40960 : bps = 600 : drive_type = 3

disk_type = "Fujitsu-M2361 Eagle" \
        : ctlr = XY450 : fmt_time = 4 \
        : ncyl = 840 : acyl = 2 : pcyl = 842 : nhead = 20 : nsect = 67 \
        : rpm = 3600 : bpt = 40960 : bps = 600 : drive_type = 3

disk_type = "CDC EMD 9720" \
        : ctlr = XY450 : fmt_time = 4 \
        : ncyl = 1147 : acyl = 2 : pcyl = 1217 : nhead = 10 : nsect = 48 \
        : rpm = 3600 : bpt = 30240 : bps = 613 : drive_type = 1

disk_type = "Hitachi DK815-10" \
        : ctlr = XY450 : fmt_time = 4 \
        : ncyl = 1735 : acyl = 2 : pcyl = 1737 : nhead = 15 : nsect = 67 \
        : rpm = 3600 : bpt = 40960 : bps = 600 : drive_type = 1

disk_type = "NEC D2363" \
        : ctlr = XY450 : fmt_time = 4 \
        : ncyl = 964 : acyl = 2 : pcyl = 1024 : nhead = 27 : nsect = 67 \
        : rpm = 3600 : bpt = 40960 : bps = 600 : drive_type = 2


#
# This is the list of supported disks for the Xylogics 7053 controller.
#
disk_type = "Fujitsu-M2351 Eagle" \
        : ctlr = XD7053 \
        : ncyl = 840 : acyl = 2 : pcyl = 842 : nhead = 20 : nsect = 46 \
        : rpm = 3961 : bpt = 28160 : bps = 595

disk_type = "Fujitsu-M2333" \
        : ctlr = XD7053 \
        : ncyl = 821 : acyl = 2 : pcyl = 823 : nhead = 10 : nsect = 67 \
        : rpm = 3600 : bpt = 40960 : bps = 600

disk_type = "Fujitsu-M2361 Eagle" \
        : ctlr = XD7053 \
        : ncyl = 840 : acyl = 2 : pcyl = 842 : nhead = 20 : nsect = 67 \
        : rpm = 3600 : bpt = 40960 : bps = 600

disk_type = "CDC EMD 9720" \
        : ctlr = XD7053 \
        : ncyl = 1147 : acyl = 2 : pcyl = 1217 : nhead = 10 : nsect = 48 \
        : rpm = 3600 : bpt = 30240 : bps = 613

disk_type = "Hitachi DK815-10" \
        : ctlr = XD7053 \
        : ncyl = 1735 : acyl = 2 : pcyl = 1737 : nhead = 15 : nsect = 67 \
        : rpm = 3600 : bpt = 40960 : bps = 600

disk_type = "NEC D2363" \
        : ctlr = XD7053 \
        : ncyl = 964 : acyl = 2 : pcyl = 1024 : nhead = 27 : nsect = 67 \
        : rpm = 3600 : bpt = 40960 : bps = 600

disk_type = "Fujitsu-M2372K" \
        : ctlr = XD7053 \
        : ncyl = 743 : acyl = 2 : pcyl = 745 : nhead = 27 : nsect = 67 \
        : rpm = 3600 : bpt = 40960 : bps = 600

disk_type = "CDC 9720-850" \
        : ctlr = XD7053 \
        : ncyl = 1358 : acyl = 2 : pcyl = 1360 : nhead = 15 : nsect = 66 \
        : rpm = 3600 : bpt = 41088 : bps = 610

Xylogicsコントローラーの両方には8台中6台のディスクが共通しています（つまり、両方で使用可能）。最初の2台のXylogics 451ディスクは7053では使用できないようで、最後の2台のXylogics 7053ディスクは451では使用できないようです。なぜでしょう。これは技術的な制限ではなく、商業的な制限だった可能性があります。

CDC 9720-850（Sabre-V）ディスクの寄付を歓迎します。Xylogics 451コントローラーで動作するかどうかを確認し、この問題を最終的に解決するためです。これは無料でやります。人類全体の利益のためです！

次のステップは、OpenBSDインストーラーを起動して再インストールすることでした。残念ながら、RimfireはXylogics互換モードでSunOSではうまく動作するようですが（カーネル設定からXylogicsドライバーを削除した場合）、OpenBSDドライバーはドライバー初期化中にハングしてしまいます。

Xylogicsエミュレーションは、ポーリングモードでPROMと連携するのに十分なだけだと思われます。BSDドライバーは、制御レジスタの特定のビットが値の変化を待っている可能性が高いですが、Rimfireではこれが起こりません。

そのため、Xylogicsドライバーの初期化シーケンスを詳しく調べ、どこでスタックしているのか、そしてなぜなのかを理解する必要があります。そして、Xylogicsドライバーを機能させる見込みがない場合は、Cipricoドライバーの移植を予想よりも早く開始する必要があるかもしれません。

しかし、現時点では、動作するCiprico Rimfireを持っているのは私だけでしょう。これは冬まで待つことができます。あるいは次の冬、あるいはその次の冬まで...