Category Archives: Windows

Monster X2とSTBで録画

Monster X2がふいに手に入ったのでCATVのSTBからの録画環境を作ってみた。
接続は、D端子でやってます。

TVRock + hunuaa + MxCapture という組合せでやりました。

TVRock は、PT2 でつかっていたのでそのまま流用。

いい感じですが、録画コーデックが huffyuv を使うことが推奨されているので、ファイルサイズがとにかく巨大。2時間番組で250GBほど食ってくれますw

このあと、Aviutil等で圧縮して視聴できるようにします~。
これはいつものPT2と一緒ですね。

でも、やっぱりHDDがー(笑)

SRWare Iron(Chromiumベース)を入れてみた。

Google Chromeと同じ、ChromiumベースのSRWare Ironを入れてみた。
きっかけは、Windows版Safariが脆弱性で厳しくなったため。

●Safari においてリモートからローカルファイルを読み取り可能な脆弱性
http://jvn.jp/jp/JVN42676559/

で、Google Chromeを検討したのですが、やっぱり個人情報が気になるということで、SRWare Ironを選択。

ちなみに普段、WindowsとMacOSXとubuntuを使っているので、共通項で使えるという点も重要でした。

で、インストールした結果は下記のとおり。

●WindowsXP + SRWare Iron(custom.cssとメイリオフォント)
WinXPだとフォントが汚いという問題があったので、メイリオフォントをインストールし、Custom.cssでフォントの設定を変えました。

●MacOSX Lion

●ubuntu 12.04 LTS

なんだろなー、Windows以外のOSはフォントがきれいに表示されましたが、Windowsは少々修正が必要でした。^^;
様子を見てみたいと思います。

パソ通ホスト「Midnight Driving」へ98エミュレータからアクセス。

PC98エミュレータ「Anex86」をつかって、Midnight Drivingへアクセスを試みた。

が、DOS版KTXが標準でtelnetに対応しているわけもなく(厳密に言うと、TEENで対応可能らしいけど、Anex86がLANに対応していない)、一般的な方法を使えない。

で、仮想comポートでTCP/IPへリダイレクトするソフトを使い、パソ通ホストのtelnetへ強引につなげてみた。

つながったことはつながったのだが、断検出ができない・バイナリ送受信不能、となかなか問題あり。
とりあえず、見るにはいいかもしれないが。

断検出できない点は、ちょっと致命的かも。クロスケーブルで接続している状態になってしまうので、当然と言えば当然だが・・・。
NELOなどオフ書きツールが当時のまま使えるのは、便利なのだけど。

Anex86がLAN対応になってくれんだろうか・・・。

やっぱり、Midnight DrivingのWEB化が待たれます・・・。(^^;

自宅のサーバを修理

自宅のサーバを修理しました。
どうも、最近、突然電源が落ちるので、なぜかな〜?
とみてみたら、CPUクーラーが死亡していて、Core温度が85度を超えてましたw

てことで、CPUクーラーを新調して、修理。
クーラーはちょっと奮発してみました。

修理の結果、40度前後まで落ちましたので、良さそうです。
しばらく様子を見てみます・・・。

20120807-104536.jpg

20120807-104545.jpg

20120807-104610.jpg

20120807-104620.jpg

20120807-104632.jpg

20120807-104641.jpg

Win7の自動ウインドウ拡大機能(エアロスナップ)を切る方法

あーようやく解決を見た(笑)。
うっとうしくてねーこの機能(^^;

●エアロスナップを無効にする設定-Win7
http://windows7faq.net/2009/11/post_9.html

[スタート]-[コントロールパネル]-[コンピューターの簡単操作]-「コンピューターの簡単操作センター」から[マウスの動作の変更]

[ウィンドウが画面の端に移動されたとき自動的に整列されないようにします]

をチェックする。

いやーすっきりした(笑)。

テレビつけたら、風の谷のナウシカ、がやってたw

今日は、仕事という腐海にのまれてましたw

左のMacでXcodeをいじりながら、右のWinでLinuxとルータをいじりながら…。

ふと前をみると、中央のテレビで風の谷のナウシカがやってる…。

もう9時だな。もう還ろうw

滅びてしまいそうです(笑)

20120511-211832.jpg

(続)Linux KVMでPCIパススルー。・・・残念(斬りっ!)

あれから、進展(後退?)したので、ご報告します。
えー、まだうまくいってません。というか、今現在対応不能になってます。

ここで、ホストマシンの接続構成をあげて起きます。

# lspci -vt
-+-[0000:ff]-+-00.0  Intel Corporation Xeon 5500/Core i7 QuickPath Architecture Generic Non-Core Registers
 |           +-00.1  Intel Corporation Xeon 5500/Core i7 QuickPath Architecture System Address Decoder
 |           +-02.0  Intel Corporation Xeon 5500/Core i7 QPI Link 0
 |           +-02.1  Intel Corporation Xeon 5500/Core i7 QPI Physical 0
 |           +-03.0  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller
 |           +-03.1  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Target Address Decoder
 |           +-03.4  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Test Registers
 |           +-04.0  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Control Registers
 |           +-04.1  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Address Registers
 |           +-04.2  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Rank Registers
 |           +-04.3  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Thermal Control Registers
 |           +-05.0  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Control Registers
 |           +-05.1  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Address Registers
 |           +-05.2  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Rank Registers
 |           +-05.3  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Thermal Control Registers
 |           +-06.0  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Control Registers
 |           +-06.1  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Address Registers
 |           +-06.2  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Rank Registers
 |           \-06.3  Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Thermal Control Registers
 \-[0000:00]-+-00.0  Intel Corporation 5520/5500/X58 I/O Hub to ESI Port
             +-01.0-[01]--
             +-02.0-[02]----00.0  NEC Corporation uPD720200 USB 3.0 Host Controller
             +-03.0-[03]----00.0  NVIDIA Corporation G86 [GeForce 8400 GS]
             +-07.0-[04]--
             +-14.0  Intel Corporation 5520/5500/X58 I/O Hub System Management Registers
             +-14.1  Intel Corporation 5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers
             +-14.2  Intel Corporation 5520/5500/X58 I/O Hub Control Status and RAS Registers
             +-14.3  Intel Corporation 5520/5500/X58 I/O Hub Throttle Registers
             +-1a.0  Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4
             +-1a.1  Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5
             +-1a.2  Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6
             +-1a.7  Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2
             +-1c.0-[06]--
             +-1c.2-[05]----00.0  Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller
             +-1d.0  Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1
             +-1d.1  Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2
             +-1d.2  Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3
             +-1d.7  Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1
             +-1e.0-[07]--+-00.0  Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart)
             |            +-00.1  Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (Disabled)
             |            +-01.0  Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart)
             |            \-01.1  Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (Disabled)
             +-1f.0  Intel Corporation 82801JIR (ICH10R) LPC Interface Controller
             +-1f.2  Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller
             \-1f.3  Intel Corporation 82801JI (ICH10 Family) SMBus Controller

こんな感じでつながっているわけです。マザーボードは、「ASUS P6X58D-E」です。

ポイントなのが、07:00.0と07:01.0の「Oxford Semiconductor Ltd OX16PCI954」というやつ。
これは、PCI版のRS232C 4ポートカードです。2枚入ってます。I/O DATAの「RSA-PCI2/P4」です。
最近のマザーボードなので、PCIバスがPCIe to PCIブリッジ下にいるわけです。

で、これを2枚をPCIパススルーしたいわけなので、

# qemu-kvm -device pci-assign,host=07:00.0 -device pci-assign,host=07:01.0

と、QEMUに pci-assign オプションを加えて起動すると、

Failed to assign irq for "????": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to initialize assigned device host=07:00.0

とQEMUに起こられてそもそも起動しない、という状況でした。
もんもんとすごしていたのですが、ふと

# qemu-kvm -device pci-assign,host=07:01.0

としたところ、なぜか起動(笑)。
WindowsXPが起動できました。もしかすると、2枚挿すと調子が悪いかもしれません(未検証)。

が、しかし起動後、ハードウェアウイザードで、RSA-PCI2/P4のドライバをインストールすると、

落ちた!!!

そう、QEMUが落ちてしまいます。で、logには、

Apr 16 01:01:05 eve kernel: device tap0 entered promiscuous mode
Apr 16 01:01:05 eve kernel: br0: new device tap0 does not support netpoll (disabling)
Apr 16 01:01:05 eve kernel: br0: port 2(tap0) entering learning state
Apr 16 01:01:05 eve kernel: br0: port 2(tap0) entering learning state
Apr 16 01:01:05 eve kernel: pci-stub 0000:07:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ
 17
Apr 16 01:01:20 eve kernel: br0: port 2(tap0) entering forwarding state
Apr 16 01:01:55 eve kernel: qemu-kvm[13433] general protection ip:7ffee654f659 sp:4085dd80
 error:0 in qemu-system-x86_64_1_0[7ffee63b4000+2ff000]

Apr 16 01:01:55 eve kernel: qemu-kvm[13433] general protection

ってなんだー(泣)。

qemu-kvm 1.0が出ていたので、こっちも試しましたがまったくダメ(T_T)。
なんとなく、マザーボードのIOMMU対応に問題があるような気がしてきた・・・。
「ASUS P6X58D-E」の問題なのかも。IOMMUとMarvell 9128問題もあるし、RTCが認識できないとか、結構問題あり。

もうドツボデス(T_T)。

で、じつはなぜPCIパススルーをやることになった経緯は?というと、tel2comホストとパソ通ホストをRS-232Cでクロス接続したとき、XMODEM/YMODEMなどのバイナリ送受信がうまくいかなかったこと、がそもそもの原因です。仮想化によるデバイスのカプセル化による影響かと。
PCIパススルーすれば、仮想化の影響から開放されるかと思ったのですが、あまかった(笑)。
これはしばらくお預けです。

で、本当に問題なのかということで、下記の検証をしてみました。

仮想環境下のWindowsXP+tel2com < -> パソ通ホスト(物理マシン)

としてみました。パソ通ホストは物理的にあるマシンです。
で、やってみたところ、なんとXMODEM/YMODEMが使えるのです!!!。

え?どういうこと?

どうやら、パソ通ホストがMS-DOSで動いているわけですが、RS232CドライバにMCDPC.EXEを使っています。
QEMUのシリアルが、ISAで16550A互換ということなのですが、どうやら完全互換ではないようです。
FIFOの関係かなーとか考えていますが、まだよくわかりません。

hw/serial.c のソースプログラムと格闘中です(泣)。

夜寝られるかな・・・ww。

PC98エミュレータ、いつの間にかLGY-98がサポートしていた件。

QEMUもいろいろあるのですが、普段仕事では使わない方面のQEMUとしては、PC9821エミュレータがあります。
がんばれ国産機(笑)。

数年ぶりにサイトを見てみたのですが、

QEMU/9821 on Windows Snapshot (3/20/2011)

NIC:
	LGY-98 #1	I/O=0x00D0, IRQ=6

Options:
	-M pc98		NEC PC-9821 CBUS-only
	-M pc98pci	NEC PC-9821 with PCI

なんと、いつの間にかに待望のLGY-98が対応している!!!(要は、PC98用のLANカードね)。
PC98エミュレータって、各種あったのですがLAN対応はお初ですね。

あとで試してみよう。(^^)

KTX on Windows32 を使ってみる。

パソ通やる上で重要なのは通信ソフトでしょうか。
ただ当時と違い、TELNET機能を備えているソフトはなかなかありません。
Windowsで使えるソフトでは、KTX on Windows32が唯一でしょうか。
MS-DOSのころは、DOS版のKTXはよくお世話になりました。

ということでインストールしましたが、telnet接続すると固まる(笑)。
よく見たら、ドキュメントに書いてあるじゃん(笑)

> - 追加説明 -
> GC のファイル入れ換え
> ※Telnet接続を利用される方はβGCでお使いください

ということで、βGCで使いました。

下記からダウンロードできます。

●KTX on Windows32 (Vector)
http://www.vector.co.jp/soft/win95/net/se023625.html

あとは、KTXmmmなどのマクロかな?
しかし、バイナリのダウンロードとアップロードができない。
これはどうも、ホスト側に影響があるようです。仮想化が原因かなぁ・・・。

要検証です。

Linux KVM環境におけるシリアル増設カードの件

前回記事の、検証を実際にやってみた。

1)ゲストマシン環境下では実質、シリアルは最大4ポートが限界
QEMUが440BXをベースとしているせいかIRQが足りない(笑)。
IRQが15までしかないようで空き状況を考えると、4ポートが限界です。

※ゲストOSが対応しているPCIシリアルカードをPCIパススルーとかすれば、これはこれでできるかもしれない。
 今回はターゲットOSがMS-DOSだったため、これは難しかった。MCDPC.EXEが対応している必要があったので。

シリアルポートは、マッピングでQEMU側でも4ポートをサポートしている。
例えば、ホストマシンの/dev/ttyS4~S7をゲストマシンのCOM1~4に割り当てるためには、QEMUの起動オプションに、

-parallel none -serial /dev/ttyS4 -serial /dev/ttyS5 -serial /dev/ttyS6 -serial /dev/ttyS7

を追加する。IRQ消費を防ぐためにパラレルポートは削っておく。
すると、ゲストマシン環境下では、下記のようにI/OaddrとIRQが割り当てられる。

COM1 = 3F8, IRQ = 4 < ---- COM1
COM2 = 2F8, IRQ = 3 <---- COM2
COM3 = 3E8, IRQ = 4 <---- COM3
COM4 = 2E8, IRQ = 3 <---- COM4
しかしこの状況のゲストマシン環境下ではゲストOSにもよるのだが、上記の手法では、IRQの4と3が競合して問題が発生してしまった。 MS-DOSはもちろんWindowsXPでも競合問題が解決できなかった。 つまり、このままでは2ポートまでしか認識できない。ISAとして認識してるようである。 今回どうしたかというと、競合を回避するためにIRQを変更してみた。 変更方法としては、QEMUのオプションで変更方法がないようなので、QEMUをソースインストールしパッチを当てる。I/OaddrとIRQは、
COM1 = 3F8, IRQ = 4 < ---- COM1
COM2 = 2F8, IRQ = 3 <---- COM2
COM3 = 3E8, IRQ = 5 <---- COM3
COM4 = 2E8, IRQ = 7 <---- COM4
となるようにすることとする。最新版をダウンロード。
# tar zxvf qemu-kvm-0.14.0.tar.gz
# cd qemu-kvm-0.14.0

# vi hw/serial.c (下記部分を修正)
-----
static const int isa_serial_io[MAX_SERIAL_PORTS] = { 0x3f8, 0x2f8, 0x3e8, 0x2e8 };
static const int isa_serial_irq[MAX_SERIAL_PORTS] = { 4, 3, 4, 3 };
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
static const int isa_serial_io[MAX_SERIAL_PORTS] = { 0x3f8, 0x2f8, 0x3e8, 0x2e8 };
static const int isa_serial_irq[MAX_SERIAL_PORTS] = { 4, 3, 5, 7 };
-----

# make clean
# ./configure \
--disable-spice \
--disable-sdl \
--disable-xen \
--enable-mixemu \
--enable-vnc-thread \
--enable-kvm

# make
# make install

とすることで、回避できた。

ちなみにMS-DOSだとCOM4がMCDPC.EXEは認識するのだが、WindowsXP環境のDOS窓環境でMCDPC.EXEを動かすとCOM4が認識しなかった(謎)。
ということで、MS-DOSを使うことになりました。

ちなみにゲストOSがCentOSの場合で、ゲスト側のIRQを変更する場合は、こうするとできそうだが未検証。

Linuxカーネルのソースを修正(下記部分を修正)

# vi linux/arch/x86/include/asm/serial.h
-----
#define SERIAL_PORT_DFNS                        \
        /* UART CLK   PORT IRQ     FLAGS        */                      \
        { 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS },      /* ttyS0 */     \
        { 0, BASE_BAUD, 0x2F8, 3, STD_COM_FLAGS },      /* ttyS1 */     \
        { 0, BASE_BAUD, 0x3E8, 4, STD_COM_FLAGS },      /* ttyS2 */     \
        { 0, BASE_BAUD, 0x2E8, 3, STD_COM4_FLAGS },     /* ttyS3 */

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

#define SERIAL_PORT_DFNS                        \
        /* UART CLK   PORT IRQ     FLAGS        */                      \
        { 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS },      /* ttyS0 */     \
        { 0, BASE_BAUD, 0x2F8, 3, STD_COM_FLAGS },      /* ttyS1 */     \
        { 0, BASE_BAUD, 0x3E8, 5, STD_COM_FLAGS },      /* ttyS2 */     \
        { 0, BASE_BAUD, 0x2E8, 7, STD_COM4_FLAGS },     /* ttyS3 */
-----

2)MS-DOSのCPU1コア100%の件
ゲストマシンのOSがMS-DOSの場合、アイドル状態(コマンドプロンプトによる入力待ち等)になると、アプリケーションによってはCPUを占領されてしまう。何にもしない無限ループでCPUを占領(笑)。
VMwareで公開されていた、DOSIDLE.EXEを常駐させてみると、コマンドプロンプト等ではCPU負荷は下げられたが、アプリケーションによってはCPUが占領された(アプリの作り方によるもの。当時はこれが主流だった)。
これはもうどうしようもない(笑)。結局、MS-DOSにCPU1コア分を割当てるような状況になってます。^^;

とりあえず、仮想環境で5マシンをVM化してみた。相変わらず1コアだけが100%。(T_T)。

まぁ、これでしばらく使ってみたいと思います。