Serial connection
先月だったか、福岡で道路陥没事故が有った。あれだけの陥没であそこに有った土砂は 何処に行ってしまったのだろう？ 数々の報道がされていたけど、言及してるのは無かった ような。まあ、井戸端会議っぽい報道なんで、すごいですねぇで済ませちゃったんか。
オイラーが感心したのは、あれだけの事故にも関わらず、穴に落っこちる車なり人が いなかった事。工事をやってた人がいち早く異変に気付き、周囲の道路を封鎖したから 二次事故は防げたと報道されてた。まだまだ、日本は棄てたものじゃないね。
きっと、某外国だと、工事人が我先にと逃げ出し、交通規制なんて思いもよらなかったろうと 思うぞ。
オイラーの住むこの田舎で、道路整備の工事が行われている。道路を通行止めにしての 大がかりなもの。公共予算のばらまきだな。
何日か前から、工事予告の看板があちこちに出ていたにも関わらず、初日は、 大渋滞。こちらに帰ってきてから遭遇する最大の渋滞で、一瞬、ここは東京みたいだなと 思っちゃったぞ。翌日からは、学習効果が働いて、渋滞は緩和された。その分の渋滞は 野道に分散されたんだと思うけど、そこまで調査するいわれはない。
道路封鎖の始点と終点が、丁度散歩コースの区間に入っている。始点、終点には、 交通誘導員が日夜詰めていて、交通整理をしてる。封鎖と言っても、閉鎖区間内に 出入りする住民と言うか住車がいるわけで、その車の安全通行を確保してるようだ。
バリケードが設置され、夜間は、提灯みたいなライトが灯っている。発発で電気を 得て点灯。結構明るく照らされている。
ある夜、そこを通りかかると、そのライトが消えていた。いつも点けているライト 今日はお休みなんですかって、誘導員に聞いてみた。今朝まで点いていたんだけど 夕方につけようとしたらつかないとの事。
地元の土建屋が担当なんで、夜間工事なんて無いと思い、そのライトはレンタルで しょって聞いてみたら、ビンゴ。それを頼りに、どこのメーカーか割り出してみる。 （探偵業ですな）
レンタルのニッケンだろうと当たりを 付ける。トップページに照明機器ってカテゴリーが有った。やっぱり需要は有るのね。
バルーンナイター(発電機搭載タイプ)の中のヤンマーのものと思われる。 ２種類あるな。軽油タイプとガソリンタイプか。周囲にまき散らす臭いが軽油エンジン のそれなんで、 機器を同定出来た。１KWとは、結構豪華なランプだな。安全に気を使ってくれる事は いい事だな。
そうそう、安全と言えば、そろそろ除雪車の出番だな。出陣式の模様をニュースでやってた。 国道、県道、市町村道でそれぞれ担当が違い、あちこちに基地が有る。道路なんてみんな 繋がっているんだから、一本化すれば経費節減になると思うけど、どうだろう？
除雪費は土建屋の冬の収入源になるんで、利権が有るんだろうな。去年は雪が少なくて、 オイラー達は助かったけど、土建屋さんには辛い冬だったらしい。
今年は既に初雪に見舞われちゃったけど、去年同様小雪さんでありますように、大雪山はごめんこうむりたい。
かしこみ、かしこみ申しまする ＞ 天の神様、アナと雪の女王姉妹、他関係御一同様
qemu serial connection
qemuに入れたOpenBSDにホスト側からシリアル接続をやってみたくて（ddbを起動したい） 調べていたんだ。結果、下記の設定で、vgaなコンソールを出さずに、シリアル接続 が出来そうとなった。これ、シリアルラインのフォワーディングに相当するな。
[ob: expl]$ cat com #!/bin/sh qemu-system-x86_64 -m 192M -net user,hostfwd=tcp::2022-:22 \ -smp 1 -nographic -serial pty \ -net nic -s disk
ゲストの/etc/ttysを編集して、COM1でもloginを受け付けるように設定。面倒な事に、 Winddows上で言うCOM1はUnix上では、com0になる。
tty00 "/usr/libexec/getty std.9600" vt220 on secure tty01 "/usr/libexec/getty std.9600" unknown off
これで、qemuを起動すると、シリアルラインをttyp4にリダイレクトしたからね、、とか 言ってくる。
[ob: expl]$ ./com QEMU 2.6.0 monitor - type 'help' for more information (qemu) char device redirected to /dev/ttyp4 (label serial0) (qemu)
仰せに従って、接続すると、確かにシリアルっぽい画面が出てきて、login出来た。
[ob: ~]$ cu -l /dev/ttyp4 Connected to /dev/ttyp4 (speed 9600) OpenBSD/amd64 (expl.my.domain) (tty00) login: root Password: Last login: Fri Nov 25 14:41:14 on ttyC0 OpenBSD 6.0 (EXPL) #1: Thu Nov 10 15:16:51 JST 2016 Welcome to OpenBSD: The proactively secure Unix-like operating system. # sysctl ddb.trigger=1 sysctl: ddb.trigger: Operation not supported by device
が、お目当てのddb起動は、拒否されたぞ。ウィンドウズのCOM1なんて端末は、 コンソールに成れない、格下なやつなのね。ttyCn系がコンソール対応って事かな。
まてまて、一番最初から、com0をコンソールにするよって宣言しておけば、 ウィンドウズで言うCOM1も、コンソールとして認めてくれるのではなかろうか。
取り合えず、/etc/boot.confに下記の設定を入れた。
set tty com0
これで起動したら、見事、com0がコンソールって認められました。 下記は、dmesgからの抜粋。
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0
psで確認すると、tty00(com0相当）で、ちゃんと待ち受けしてましたよ。
# ps PID TT STAT TIME COMMAND 29140 p0 Sp 0:00.18 -ksh (ksh) 68773 p0 R+p 0:00.00 ps 27682 00 Is+p 0:00.10 /usr/libexec/getty std.9600 tty00 21181 C0 Is+p 0:00.12 /usr/libexec/getty std.9600 ttyC0
前回失敗した、ddbの起動が出来るか、確認します。
[ob: ~]$ cu -l /dev/ttyp4 Connected to /dev/ttyp4 (speed 9600) OpenBSD/amd64 (expl.my.domain) (tty00) login: root Password: Last login: Sat Nov 26 05:43:19 on tty00 OpenBSD 6.0 (EXPL) #1: Thu Nov 10 15:16:51 JST 2016 Welcome to OpenBSD: The proactively secure Unix-like operating system. # sysctl ddb.trigger=1 Stopped at breakpoint+0x9: leave ddb> c ddb.trigger: 0 -> 1 #
やったね。これで、ddbのセッションも簡単に、コピペ出来るぞ。粘り勝ちだな。
実例
こうして準備が整って、いざ使おうとloginしたら、いきなり団子の代わりに、 ddbがお待ちかね してた。（女房が通販で、熊本名物、いきなりだんごを頼んだけど、まだ来ない）
焦ってｃしちゃったけど、余計だった。しかも、traceすらしていないというお粗末君ですよ。
ddb> c uvm_fault(0xffffff000b708800, 0x24, 0, 1) -> e kernel: page fault trap, code=0 Stopped at bufq_wait+0x10: movl clean_idt+0x4(%rax),%eax ddb> boot dump syncing disks... . panic: init died (signal 11, exit 0) Stopped at breakpoint+0x9: leave TID PID UID PRFLAGS PFLAGS CPU COMMAND * 1 1 0 0x802 0x2000 0 init breakpoint() at breakpoint+0x9 Debugger() at Debugger+0xd panic() at panic+0x154 exit1() at exit1+0xc3 sigexit() at sigexit+0xbc trapsignal() at trapsignal+0x325 trap() at trap+0x8ab --- trap (number 6) --- end of kernel end trace frame: 0x86bb, count: 8 0x158cde7035b0: http://www.openbsd.org/ddb.html describes the minimum info required in bug reports. Insufficient info makes it difficult to find and fix bugs. ddb>
以前見た、URLが晒されているな。これって、親分からの叱責だな。謙虚に受け止めよう。 現場を歩き回って、証拠を消しちゃったんだから。 そんなひよっこの狼狽える行動もしっかり、ログ出来るので便利です。
ttyの事
上で、COM1がコンソールに昇格してた。このあたりの機構はどうなってるの？ 多分、init(8)の中でやってるのかも。昔はどうなってたのか、調べていた方の 解析結果を参照しておこう。
UNIX 6th システムプログラミング - init その1
UNIX 6th システムプログラミング - init その2
UNIX 6th システムプログラミング - init その3
UNIX 6th システムプログラミング - init その4
上記のURLは、unix v6を読んでいた方のページ。そして、下記は、それだけでは飽き足らず 本物のUNIXとしてOpenBSDに着目されて、色々と画策されている。
やっぱり、流れて行く所は一緒だね。OpenBSDは、カーネルが一枚板（モジュールなんて ややこしい仕組みを使っていない）、ドキュメントとコードがsyncしてる。無駄に機能を 増やしていないってんで、勉強するにはうってつけのOSです。
その点、LinuxやFreeBSDは、上記の特徴をことごとく破っているので、手を出すと痛い目に合います。
How to build OpenBSD from source code and add system call on QEMU
MP
マルチプロセッサーのOS上だと、ddbで使えるコマンドが拡張されるらしいので、やってみる。 OSのconfigをちょっと拡張して、元々あったNTFSとかはdisableにした。
#option NTFS # NTFS support #option HIBERNATE # Hibernate support option MULTIPROCESSOR cpu* at mainbus?
これでOSを作り直し
[ob: EXPL]$ sudo COPTS="-O0 -gdwarf-2 -g3" make
:
ld -T ../../../../arch/amd64/conf/ld.script -X --warn-common -nopie -o bsd ${SYSTEM_HEAD} vers.o ${OBJS}
text data bss dec hex
11958560 283608 663552 12905720 c4ecf8
mv bsd bsd.gdb
strip -S -o bsd bsd.gdb
出来上がったものを使って、起動。勿論今までと同じqemuで、-smp 2 を指定。
bios0: QEMU Standard PC (i440FX + PIIX, 1996) acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat cpu1 at mainbus0: apid 0 (boot processor) cpu1: QEMU Virtual CPU version 2.5+, 2401.49 MHz cpu1: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,HV,NXE,LONG,LAHF,SVM cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu1: apic clock running at 999MHz cpu2 at mainbus0
見事にハングしましたよ。ddbを呼んでみたけど、応答無し。なんかメッセージがVMWAREと 時と違うな。ひょっとしてqemuがちゃんとsmpをサポートしてない？
もはや残骸となってしまったdiskは、再インストールの運命にあるんで、元からMPな環境を 用意して、一歩づつやってみよう。
インストールの仕方をよく忘れるので、メモ。
[ob: old]$ qemu-img create -f qcow2 disk 2G [ob: old]$ qemu-system-x86_64 -cdrom install60.iso disk
で、分かった事は、configの設定ファイルを１本にするとダメみたい。多分書く順番が あると思う。GENERICにddbの設定を書く。それをincludeしてるGENERIC.MPを指定して configしたら、上手く行った。
machine ddbcpu というコマンドで、ddbがcpuを渡り歩くとな。その時、相方は停止 してるんか。そりゃそうだ。ちょろまかされたら困りますよ。
# sysctl ddb.trigger=1
Stopped at breakpoint+0x9: leave
ddb{1}> mac cpuinfo
0: stopped
* 1: ddb
ddb{1}> mac ddbcpu 0
Stopped at breakpoint+0x9: leave
ddb{0}> mac cpuinfo
* 0: ddb
1: stopped
レジスタの確認も、cpuを切り替えて行えとな。メモリーは、両CPUが共有してる（はず）んで 切り替え不要。なんか、嘘を書いてる気がする。きっと、メモリーのある領域は CPU毎に専有になっているに違いない。レジスタだけでは、賄いきれないはずだから。
ddb{0}> show registers
rdi 0xffffffff81ba3080 cpu_info_primary
rsi 0
rbp 0xffff8000055b8ca8
rbx 0
rdx 0
rcx 0x7
rax 0xffffffff814a01dd x86_ipi_db
r8 0
r9 0x1
r10 0xffffff0005f9d000
r11 0xffff800005600ce8
r12 0xffffffff8122c8fe sched_idle
r13 0xffffffff81ba3080 cpu_info_primary
r14 0
r15 0
rip 0xffffffff814a025a breakpoint+0x9
cs 0x8
rflags 0x282 mptramp_gdt32_desc+0x260
rsp 0xffff8000055b8c98
ss 0x10
breakpoint+0x9: leave
ddb{0}> mac ddbcpu 1
Stopped at breakpoint+0x9: leave
ddb{1}> show registers
rdi 0xffff800005626d64
rsi 0x1
rbp 0xffff800005626c90
rbx 0x3912 __ALIGN_SIZE+0x2912
rdx 0x800 hib_hlt_real+0x4fe
rcx 0xffff800005626d98
rax 0x800 hib_hlt_real+0x4fe
r8 0x7f7ffffd9064
r9 0x4
r10 0x7f7ffffd9070
r11 0x1
r12 0
r13 0x1
r14 0xffff8000ffffad28
r15 0x2
rip 0xffffffff814a025a breakpoint+0x9
cs 0x8
rflags 0x282 mptramp_gdt32_desc+0x260
rsp 0xffff800005626c80
ss 0x10
breakpoint+0x9: leave
親切な事に、それぞれのregが保持してる値が、text領域を指しているようなら、その エリアの関数名を調べて、表示してくれている。これを見ると大事そうなポイントが 分かるな。
Connect PuTTY to VirtualVox
直交性の無い石を使わされている身としては、石以外の所で直交性を保っておきたい。 (本音はARMの石のパソコン希望）
で、直交性は何かと考えてみたら、Windowsに入れているVMWARE以外の仮想PCである VBOXに思いが至った。上でやったようにqemuでは仮想シリアルが出来ているんだから、 それと親戚なVBOXでもシリアル接続が出来るに違いない。 例によってぐぐってみる。
Connect PuTTY to VirtualBox VM Serial Port using Named Pipe
ぴったりなのが、出てきた。翻訳を兼ねて、追試してみる。対象は、VBOX上に入れた OpenBSDです。（Linuxはよく知らないのさ）
vboxの設定でシリアルポートを開く。ポート１のタブで、シリアルポートを有効化に チェックを入れる。COM1、 IRQ 4、I/Oポート 0x3F8になってるはず。これがPC/ATの 威力だ。標準化素晴らしい。
ポートモードを ホストのパイプにする。存在するパイプ/ソケットに接続はOFF。 （動的に作るって訳だ）パス/アドレスに
\\.\pipe\6475
を設定する。6475ってのがパイプの名前。ムシナイと呼んでくれ。まあ、神田明神の マシン安全のお守りみたいなものだ。
PuTTYの方は、セッションの基本設定で、Serialを選び、シリアルポートの所に、上記の お守りを貼っておく。
後は、一度OpenBSDを立ち上げて、/etc/ttysのtty00を、
tty00 "/usr/libexec/getty std.9600" vt220 on secure
に、設定し、kill -HUP 1 すれば、tty00からlogin出来るようになってるはず。 secureに設定してるんで、rootもログイン出来る端末だ。ps -a すれば、
70934 C0 Is+p 0:00.01 /usr/libexec/getty std.9600 tty00
こんなのが見えるはず。
PuTTYで接続。一度リターンを叩くと、待ち構えていたtty00が起き上がってくる。 後は普通にloginすればよい。
OpenBSD/amd64 (ob60.my.domain) (tty00) login: root Password: Last login: Sun Nov 27 05:38:20 on ttyC0 OpenBSD 6.0 (SEE) #0: Fri Nov 4 14:52:25 JST 2016 ===== FOR SEE FOR SEE ======================== #
/etc/motd を変更すると、起動時のメッセージを変えられるぞ。
おまけで、他の人のシリアル接続方法