So-net無料ブログ作成
検索選択
前の10件 | -

AXIの勉強(その2.2) [AXI]

書き込みの依存関係です。
3チャンネルあるので長くなりますが、読み込みと同じように分けてみます。

Write transaction dependencies
Image 066.png

1• the master must not wait for the slave to assert AWREADY or WREADY before asserting AWVALID or WVALID
2• the slave can wait for AWVALID or WVALID, or both before asserting AWREADY
3• the slave can assert AWREADY before AWVALID or WVALID, or both, are asserted
4• the slave can wait for AWVALID or WVALID, or both, before asserting WREADY
5• the slave can assert WREADY before AWVALID or WVALID, or both, are asserted

実はAWとWの2チャンネルの依存関係が絡んでるここが結構面倒です。

1 マスターのAWVALIDやWVALIDは、AWREADYとWREADYに依存してはならない。
2,3 スレーブのAWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。
4,5 スレーブのWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。

「1」の制約は
・AWシーケンサーはAW自身のREADYだけでなく、WのREADYも参照してはならない
・WシーケンサーはW自身のREADYだけでなく、AWのREADYも参照してはならない
という2つの制約になっています。

なぜか。
書き込みなのでマスターのAWとWはソースですが、AWとWの順番には特に決まりはなく、アドレスが先でそれからデータ、先にデータを出してからアドレスを送る、もしくは同時、でかまいません。
・ マスターはAWとW、どちらを先に出すか、自由に選べる
・ スレーブはAWとW、どちらを先に受け取るか、自由に選べる
という状況です。相手がどちらを先だと想定しているのかが不明です。

この状態で、
・ もしマスターのWVALIDがAWREADYに依存していて (これが違反)
・ マスターはAW→Wの順番で送る
・ スレーブはW→AWの順番で来ると思ってる
という場合、マスターがAWREADY待ち、スレーブがWVALID待ち、となりデッドロックします。

普通アドレスが先でデータが後でしょう、って事で
AWVALID <= '1';
if (AWREADY = '1') then
 AWVALID <= '0'; next_state;
WVALID <= '1';
if (WREADY = '1') then
 WVALID <= '0'; next_state;

こんなマスター回路が思いつきます。当たり前な回路に見えますが、 WVALIDがAWREADYに依存しているので、実はこれ違反です。ただ、世の中、アドレスが先だと想定してるスレーブがほとんどなので、大体問題なくつながっちゃいます。
データが来るまでアドレスは受け付けない、というひねくれた(けど仕様に反してはいない)スレーブが、この回路につながるとデッドロックします。例えばこんな回路。
if (WVALID = '1') then
 WREADY <= '1';
 AWREADY <= '1';  データが送られ始めてからアドレスを受け取る

AWVALIDかWVALIDを動作開始のトリガーと考えると、そんなにひねくれて見えませんよね。2,3,4,5の項目から、これは正しい動作です。


この制約は多分、アドレスとデータを同時に転送できるようにするために作られたんだと思います。データを先に転送するような回路は、もちろん作っても良いですけど、不自然ですよね。

2,3,4,5の制約は、今までと同じく、VALID側を制約して、READY側は自由にすし、デッドロックを回避する、という項目です。


6• the slave must wait for both WVALID and WREADY to be asserted before asserting BVALID the slave must also wait for WLAST to be asserted before asserting BVALID, because the write response, BRESP, must be signaled only after the last data transfer of a write transaction

ちょっと長めですが、要するに
・全てのデータ転送を終えてから、BVALIDをアサートすること。
という制約です。リードのAR→Rの制約と似ています。

注意点としてはWLASTも見ている所です。今まではペイロードの中身がタイミングに影響することはなかったのですが、「全ての」が関係してきます。AXIはバースト転送が基本なので、Wチャンネルの転送が何回あるかはペイロードの中身を見ないとわかりません(転送が1回でも1バーストです)。WREADY&WVALID&WLASTが揃ったのを確認してから、BVALIDをアサート、レスポンスのステートに入ります。


7• the slave must not wait for the master to assert BREADY before asserting BVALID
8• the master can wait for BVALID before asserting BREADY
9• the master can assert BREADY before BVALID is asserted.

これは単純。Bチャンネルのデッドロック防止です。


AXI4になると書き込みの依存関係の図に、矢印が2本増えます。
Image 067.png

項目はほとんど同じですが、、「6」だけ異なります。
• the slave must wait for AWVALID, AWREADY, WVALID, and WREADY to be asserted before asserting BVALID
the slave must also wait for WLAST to be asserted before asserting BVALID because the write response, BRESP must be signaled only after the last data transfer of a write transaction

これは
・アドレス転送と、全てのデータ転送を終えてから、BVALIDをアサートすること。
という内容になります。アドレス転送が条件に入ってます。

実はAXI3だと、アドレス転送を完了させないままレスポンスを返せるようになってます。制約がありませんので。AWREADYをずっと返さずにデータ転送を終えて、レスポンスを返して、それからアドレス転送を完了する、という順番でも良かったわけです。
まぁ、普通に考えればおかしな動作ですが。制約されてない以上、あり得る動作です。

AXI4ではこれが制約され、マスターがアドレスとデータ全ての転送を完了するまで、スレーブはレスポンスを返せなくなってます。

スレーブ側の制約です。AXI3のスレーブをAXI4のマスターに接続するときに注意が必要で、ペイロードの内容を変換する以外に、この書き込みの依存関係を満足させる必要があります。

AXIの勉強(その2.1) [AXI]

続いてリードの依存関係。

Read transaction dependencies

1• the master must not wait for the slave to assert ARREADY before asserting ARVALID
2• the slave can wait for ARVALID to be asserted before it asserts ARREADY
3• the slave can assert ARREADY before ARVALID is asserted

4• the slave must wait for both ARVALID and ARREADY to be asserted before it asserts RVALID to indicate that valid data is available

5• the slave must not wait for the master to assert RREADY before asserting RVALID
6• the master can wait for RVALID to be asserted before it asserts RREADY
7• the master can assert RREADY before RVALID is asserted.
Image 065.png
なんかいっぱいありますが、分けてみるとわかりやすいかと思います。

まず上3つ。1,2,3。
・マスターのARVALIDは、ARREADYに依存してはならない
・スレーブはARVALIDを待ってからARREADYをアサートしても良い
・スレーブはARVALIDより前にARREADYをアサートしても良い
前の記事のソース・シンクの関係と同じです。ARチャンネルのデッドロックを防止する制約です。

下3つ。5,6,7。
・スレーブのRVALIDは、RREADYに依存してはならない
・マスターはRVALIDを待ってからRREADYをアサートしても良い
・マスターはRVALIDより前にRREADYをアサートしても良い
Rチャンネルのデッドロック防止です。

真ん中の一つ。4。
・スレーブはARREADYとARVALID両方がアサートされるのを待ってからRVALIDをアサートすること

ARREADYとARVALID両方がアサートされるということは、ARの転送が完了したということです。
ARVALIDはマスターがドライブしているので、スレーブ側のRのソースシーケンサーの制約になります。つまり、
・スレーブはARVALIDが来ないうちにRVALIDをアサートしてはならない
・スレーブはARREADYを先に返してからRVALIDをアサートすること
という制約です。

要は
・アドレス情報が与えられてもいないのに余計な情報を勝手に送るな
・アドレス情報を受け取ったことを、まずマスターに知らせてから、データを返せ
という制約です。1つ目はまあ良いですよね。

2つ目、例えばスレーブがARREADYを返さずに、ARの情報をゆっくり解析する回路にしたとします。これ自体は正しい動作です。
if (ARVALID) then
 1クロック目:AR.addr評価
 2クロック目:AR.length評価
 3クロック目:
 ・・・・
 nクロック目:ARREADY <= '1';

この途中でデータを返すのを違反としています。
if (ARVALID) then
 1クロック目:AR.addr評価
 2クロック目:AR.length評価
 3クロック目:RVALID <= '1';   違反
 4クロック目:if (RREADY) then ここでデッドロック
 ・・・・
 nクロック目:ARREADY <= '1';

なぜか。
例えばこれにつながるマスターがこんな風に順番に処理する回路の場合です。あり得る回路です。
アドレス処理ステート
 ARVALID <= '1';
 ↑クロック
 if (ARREADY = '1') then ここでデッドロック
  ARVALID <= '0';
データ処理ステート
 if (ARVALID = '1') then
  RREADY <= '1'

・マスターのARシーケンサーがARREADYを確認してからデータの受信処理を行う
・スレーブのRシーケンサーがARREADYをアサートする前にRREADYの評価を行う
この2つがつながるとデッドロックします。

実際の犯人はRREADYを評価していることで、RVALIDをアサートしたこと自体ではないですが。RVALIDを操作したということは、スレーブがデータ処理ステートに入ったことを意味します。けどマスターがアドレス処理のステートのままだと、RREADYが返ってこないかも知れません。

この、スレーブがデータ処理ステートに入ったのに、マスターがアドレス処理ステートのところで止まったまま、となるのを防ぐための制約で、マスター・スレーブともアドレス処理ステートを完了させてからデータ処理ステートに移行しましょう、そのために、スレーブはARREADYを先に返してからRVALIDをアサートすること、という決まり事です。

下のような違反の回路、AXIに慣れてないうちだと、意外と作りがちな回路です。
ARVALIDをアドレスストローブ信号、ARREADYをウェイト制御信号、と認識してるとこんな回路になります。パケット式じゃない、普通のタイミング方式のバスに慣れてる人がはまりやすいパターンです。


AXIはただのインターフェースの仕様で、どんなコーディングしてるのかわからない相手が接続されます。デッドロックのパターンを決めておかないとエラいことになります。なので、こんな制約が存在します。

AXIの勉強(その2) [AXI]

何年ぶりでしょう(笑)

簡単にタイミングの依存関係について書いてみます。
元になる資料はARMからダウンロードできる「IHI0022E_amba_axi_and_ace_protocol_spec.pdf」です。Issue Eが多分最新版。

AXIは、
axt_read_channel.pngaxi_write_channel.png
という5チャンネルでパケットのやりとりをしている感じなのですが、それぞれのチャネルがREADYとVALIDを持っていて個別にハンドシェイクを行う、という仕組みになっています。
けど、ハンドシェイクは個別ですけど、ちょっとは相手のことも考えないとダメよ、勝手に動くとデッドロックしますよという項目です。これが依存関係で、資料に書いてあります。A.3.3のRelationships between the channelsから始まる内容です。

A3.3.1 Dependencies between channel handshake signals
一番基本になる依存関係です。5系統それぞれにある、READYとVALIDの関係です。AXI Streamにも同じ制約がかかります。こんなことが書かれてます。
• the VALID signal of the AXI interface sending information must not be dependent on the READY signal of the AXI interface receiving that information
• an AXI interface that is receiving information can wait until it detects a VALID signal before it asserts its corresponding READY signal.
掻い摘まむと
・VALIDはREADYに依存してはならない(ソース側の制約)
・READYはVALIDに依存しても良い(シンク側の制約)
と言う事になります。
(マスター・スレーブと呼ぶとと5チャンネルを束ねたインターフェースを指します。だから英語の方ではちょっと持って回った言い方になってます。間際らしいので、ここでは個々のチャンネルのインターフェースをソース・シンクと呼んでます。ソースからシンクへデータが流れます。マスターは3つのソースと2つのシンク、スレーブは3つのシンクと2つのソースを持ちます。)

要するに、ソース側のシーケンサーを作るとき、
if (READY = '1') then
  VALID <= '1';
みたいな回路は作っちゃダメですよ、という制約になります。

シンク側は
if (VALID = '1') then
  READY <= '1';
という回路を作っても大丈夫です。

ソース側の制約な訳ですが、ダメな回路例と大丈夫な回路例をつないでみれば一目瞭然かと。ソースがREADY待ちで、シンクがVALID待ちとなり、デッドロックします。どちらかに制約をかける必要があり、AXIではVALID側を制約しています。

ちなみにシンク側ですが、この回路にしなければなりません、という’訳ではありません。VALIDに依存しない、
if (Im_free) then
  READY <= '1';
という回路にしても良いです。
VALIDに関係なく、自分の都合でREADYをアサートしてもかまいません。READY側の方が自由になっています。


こんなのがAXIの依存関係です。他のチャンネルとの依存関係も読んでいきましょう。

Dartが来た [PC]

Kickstarterでやってた、小型ACアダプタのFinsix、Dartが到着しました。
・・・来ると思ってませんでした(笑)。すっかり忘れてました。

履歴を見るとKSキャンペーンが2014年の5月ぐらいですかね。約2年前です。
遅れた理由の一つにLenovoへのライセンシングがあるんだと思います。人的リソースに限りがあるスタートアップで大企業へのサポートに手を出せばそっちでいっぱいいっぱいになるでしょう。一方ライセンス収入でキャッシュフローが潤沢になり、資金切れを起こすことなく製品化に持ち込めたわけで、結果的には良かったんだとは思います。

ということで、箱。
01.jpg02.jpg
見開き状態に開く。ちなみに小口部分に磁石が入っていて、小気味よくパコンと閉まる。それほど品質の良い箱でもないのに無駄な(笑)
03.jpg
内容物。本体、ケーブル、各種チップ、チップのリスト、袋、取説
04.jpg
チップは9種類
09.jpg05.jpg
コネクタは2ピン。チップ側も同じ形で、切り欠きの付いた円形。特にセンスピンなどはなく、テスタで当たってもツーツー。ACが入ると単純に20Vが出力される仕様。途中で5Vに落とすDCDCなどが入っていて、USBに供給してるようだ。ちなみにUSBにはLEDのインジケーターが付いてて、負荷がかかると明るくなる。
11.jpg10.jpg
つないだところ。ケーブルの両端は同じ形なので、USBを本体側にしてもチップ側にしてもOKのようだ。
06.jpg
先にFinsixのライセンスを元に製造されたらしい、Lenovoの65W トラベルACアダプターと比較。半分ぐらい。量産する数が全然違うのはずなので、部品や組み立てのコストが大きさより優先されたのだろうと想像される。Lenovoは筐体もプラスチックだし、プラグが交換可能だし。Finsixは金属筐体。
07.jpg
オレンジと青を入手。
08.jpg

ここしばらくもって歩いてますが、普通のACアダプタとして使えてます。やっぱり小さくて便利。PCの負荷をかけると結構熱くなります。非接触温度センサーで50度ぐらい。ちょっとした小型カイロ。
Lenovoは元々20Vだから問題ないけど、他のPCはどうなんでしょ?18~21Vらしいんで、大体合ってればOKってことかな?

ML110 G7 ESXi+OpenIndiana 追記 [PC]

前の記事では、ESXi 5.1.0U2+oi151a8で構成しましたが、問題が出てました。Windowsでファイル共有させ、大きめのファイルを転送すると止まる事がある、というものです。ネットワーク周りな感じです。

現在はESXi 5.0.0U3にしています。上記の問題も無く、PCIパススルーもちゃんと動いてます。やっぱりこの辺が一番安定しているようです。
導入方法は大体同じですが、ローカルストレージで追加したSATAカードを認識させるところで、ファイル名が異なります。
5.1では「/bootbank/sata_ahc.v00」ですが、
5.0では「/bootbank/sata-ahc.v00」です。
_と-が違います。

ESXiの外部データストアとしてRaspberryPiにNFSやらせ、ついでにファン制御もさせていましたが、データストアがローカルになったのでRaspberryPiも外しました。ファン制御は結局PICマイコンに任せてます。なんかず~っと遠回りしてスタート地点に戻ってきた感じですな(笑)NE555まで立ち戻ってはいないけど。
8ピンの12F683でデューティー比2~30%のPWM波形をソフトループで作ってるだけです。PWMの周波数が可聴域まで落ちてきましたが、コイル鳴きなどは無さそうです。
今後は温度センサとUSB-UART付けて回転数制御するかな~ぐらいは考えてますが、このままでも良いかも…(って思った時点で負けてるんですがw)

nwamdの大量エラーはVNCサーバー止めたらやみました。セキュリティがらみかその辺な感じですかね。ヒントは出たのでそのうち直せそうです。今はOIのVNCを止めてます。

Windowsのファイル共有をzfsのsharesmbにしていますが、ちょっと問題あるんですね。AndroidのESファイルエクスプローラーなどから見えないなど。SUNWsmbaでは普通に使えていたのでそっちに戻すかな~でもスナップショットが以前のバージョンから見えるのは便利だしな~で悩みどころ。

OpenIndiana設定メモ改 [PC]

改と言うほどでも無いですが、ESXi更新ついでにこちらも。
ちょっと変わったのでメモし直しです。

・「OpenIndiana 151a8 Desktop」にした(Xアプリが使いたくなった)。
・IP固定をnwamのままで行う(defaultにはしない)。
・zfsのsharesmbを使用(ACLがらみで敬遠してた)。
辺りが変更点です。

インストールは通常通り。isoをマウントしてブートすれば導入されます。DesktopにしてXが入ったことでサイズは増えてます。pkgなどのアップデート後は7~8GBほど消費します。ESXiの仮想ディスクをちょっと多めに作ります。

IPv4アドレスを固定にします。
# nwamcfg
nwamcfg> list
NCPs:
        Automatic
Locations:
        Automatic
        NoNet
        User
nwamcfg> select ncp Automatic		Automaticを選択
nwamcfg:ncp:Automatic> list
NCUs:
        phys    e1000g0
        ip      e1000g0
nwamcfg:ncp:Automatic> select ncu ip e1000g0	e1000g0のIPを選択
nwamcfg:ncp:Automatic:ncu:e1000g0> list
ncu:e1000g0
        type                    interface
        class                   ip
        parent                  "Automatic"
        enabled                 true
        ip-version              ipv4,ipv6
        ipv4-addrsrc            dhcp
        ipv6-addrsrc            dhcp,autoconf
nwamcfg:ncp:Automatic:ncu:e1000g0> walkprop	変更開始
enabled (true) [true|false]>
ip-version (ipv4,ipv6) [ipv4|ipv6]>
ipv4-addrsrc (dhcp) [dhcp|static]> static	固定
ipv4-addr> 192.168.0.11				自機アドレス
ipv4-default-route> 192.168.0.1			デフォルトルート
ipv6-addrsrc (dhcp,autoconf) [dhcp|autoconf|static]>
ipv6-default-route>
nwamcfg:ncp:Automatic:ncu:e1000g0> list
ncu:e1000g0
        type                    interface
        class                   ip
        parent                  "Automatic"
        enabled                 true
        ip-version              ipv4,ipv6
        ipv4-addrsrc            static
        ipv4-addr               "192.168.0.11"
        ipv4-default-route      "192.168.0.1"
        ipv6-addrsrc            dhcp,autoconf
nwamcfg:ncp:Automatic:ncu:e1000g0> commit	変更を反映
「walkprop」で編集する時は変更が必要な項目だけ入力します。「commit」すると即アドレスが変更されるので、SSHなどで入っていた時は切断されます。再度接続してDNSを編集します。
# nwamcfg
nwamcfg> list
NCPs:
        Automatic
Locations:
        Automatic
        NoNet
        User
nwamcfg> select loc Automatic		Automaticを選択
nwamcfg:loc:Automatic> list
loc:Automatic
        activation-mode                 system
        enabled                         false
        nameservices                    dns
        nameservices-config-file        "/etc/nsswitch.dns"
        dns-nameservice-configsrc       dhcp
nwamcfg:loc:Automatic> walkprop		変更開始
activation-mode (system) [manual|conditional-any|conditional-all]>
enabled (false) [true|false]>
nameservices (dns) [dns|files|nis|ldap]>
nameservices-config-file ("/etc/nsswitch.dns")>
dns-nameservice-configsrc (dhcp) [manual|dhcp]> manual	マニュアルに
dns-nameservice-domain>
dns-nameservice-servers> 192.168.0.1		DNSサーバーアドレス(ルーター)
dns-nameservice-search>
nfsv4-domain>
ipfilter-config-file>
ipfilter-v6-config-file>
ipnat-config-file>
ippool-config-file>
ike-config-file>
ipsecpolicy-config-file>
nwamcfg:loc:Automatic> list
loc:Automatic
        activation-mode                 system
        enabled                         false
        nameservices                    dns
        nameservices-config-file        "/etc/nsswitch.dns"
        dns-nameservice-configsrc       manual
        dns-nameservice-servers         "192.168.0.1"
nwamcfg:loc:Automatic> commit	変更を反映
Committed changes
同じく「walkprop」で変更していきます。
終わったらpingやpkgを動かして設定が正しいか試します。
※現時点でpkg update, pkg image-updateを行うと、GNOMEのデスクトップがおかしくなります。私は元に戻しました。

追記:nwamdで大量エラー
nwamdで以下のエラーが大量に出てました。
nwamd[75]: [ID 234669 daemon.error] 3: nwamd_door_switch
: need solaris.network.autoconf.read for request type 1
検索してもいまいち意味がわかりませんでした。仕方ないので保留、physical:nwamを止めてphysical:defaultを使います。
前の設定方法

vncを有効にする。151a8デスクトップ版ではインストール済みなので設定だけです。
# vi /etc/gdm/custom.conf

[security]
DisallowTCP=false

[xdmcp]
Enable=true

# svcadm enable xvnc-inetd
# svcadm restart gdm

# svcs | grep xvnc
online         12:01:50 svc:/application/x11/xvnc-inetd:default
これでつながりますが、vncクライアントを終了させるとログインセッション以下、全て終了されてしまいます。
# svccfg -s xvnc-inetd
svc:/application/x11/xvnc-inetd> editprop
viが立ち上がるので、以下を編集、保存。
setprop inetd/wait = boolean: true

svc:/application/x11/xvnc-inetd> exit
# svcadm restart xvnc-inetd
この設定でvncを閉じてもログインセッションが維持されます。ただし、立ち上げっぱなしだとパスワード無しでいきなりつながるので、セキュリティ上は大問題でしょう。なにか設定はあると思いますが、今のところこのまま。

ユーザーの追加。
# useradd -u 1001 -g family -d /export/home/daresore -s /bin/bash -m daresore
# usermod -R root daresore		su可能にする場合

smb/cifsの設定。smbとcifsの違いとか、認証のルールとか正直よくわからんが動いてます。
pamの設定。
vi /etc/pam.conf
other password required pam_smb_passwd.so.1 nowarn
パスワードを与える。ユーザー毎に繰り返します。
# passwd daresore
New Password:
Re-enter new Password:
passwd: password successfully changed for daresore
ワークグループへ参加。
# smbadm join -w workgroup
After joining workgroupthe smb service will be restarted automatically.
Would you like to continue? [no]: yes
Successfully joined workgroup
zfsのプロパティを変更して公開。
# zfs sharesmb=name=daresore rpool/export/home/daresore
これでまずは公開され、Windowsから見えます。

アクセス権限のところでACLが出てきて、自分には高度すぎて面倒なんですが、とりあえず
# chmod -R A=owner@:rwxpdDaARWcCos:fd:allow daresore
# ls -V
drwx------+  9 daresore family        11 3月 18 02:47 daresore
                 owner@:rwxpdDaARWcCos:fd-----:allow

$ ls -l
./daresore : Permission denied	← 所有者とroot以外からは見えない。
と所有者に全権限継承有りを与えておくという手があります。まっ乱暴(笑)
ファイルに標準で実行権限が付くのが…という場合は
# chmod A=\
owner@:rw-pdDaARWcCos:f:allow,\
owner@:rwxpdDaARWcCos:d:allow \
daresore
とするとファイルから実行権限だけ落ちます。
共有フォルダとかに、所有者以外に権限を与える場合、
user:family1:rwxpdDaARWcCos:fd:allow,\
user:family2:rwxpdDaARWcCos:fd:allow
のようにユーザ指定で個別に権限付けるとか。
もちろん普通にowner,group,everyoneで権限切り分けることもできます。
けど家族数人とかなら個別に権限を管理してもそんなに手間では無いと思います。単純でわかりやすい気がするので自分はこちらでやってます。

NFSの場合はsharenfsをonにすればOKです。簡単。
iscsiはちょっと作業が必要です。

まずはファイル共有サーバーとしては動き出しました。sharesmbで共有してると、zfsで取ったスナップショットが、Windowsからはファイルのプロパティ、以前のバージョン、でアクセスできて便利です。

# cp /usr/lib/vmware-tools/configurator/X
Free86-3/XF86Config /usr/lib/vmware-tools/configurator/XFree86-3/XF86_VMware

ML110 G7 ESXi導入改 [PC]

しばらく安定してましたが、機械の中の掃除(物理)を行うついでにちょっと構成変えてみます。

ESXi 5.5(U1含む)へのバージョンアップも試してみたのですが、SATAコントローラー(Intel Cougar)のPCIパススルーで問題が起きました。ESXiの設定からは一見パススルーできているように見えるのですが、ゲストからは謎のI/Oとされてしまいます。
Image 001.pngゲストのOIから見るとこんな感じ。
どうやらIOMMU周りに問題があるようで、VMwareでは「HPの最新ファームウェアを使うこと」的な記述が見えます。最新がどのバージョンなのかはわかりませんが。
現在の自機のファームウェアは
・System ROMが「07/01/2013」
・iLO3が「Jan 09 2014、1.70 」
で、これは現在HPのダウンロードから入手可能なものと同じです。しかし、HPはファームウェアなどの無償公開を止めてしまったので(個人の安サーバーで年間保守契約は無いよ…)これからの更新は期待できません。

これで動くESXiを選ぶことになります。全部は面倒なので一部だけ。パッチには手を出してません。
2014-03-11 | 5.5.0 U1 ×
2013-09-22 | 5.5.0 ×
2014-01-16 | 5.1.0 U2 ○
2013-04-25 | 5.1.0 U1 ×
上から試していってここまでです。ネットの情報を見ると、PCIパススルーは5.0の方がうまく動くという報告が多いみたいです。今回はとりあえず動いた5.1.0U2で行ってみます。インストール先はUSBメモリです。
※iLOが1.5の時は5.1.0U1が動いていた、ような気がする(笑)

Raspberry piのNFSサーバーをやめて、SATAボードを追加し、ローカルストレージに変更します。こちらの方が速くて安定するので…追加したSATAボードはこちら。


Asmediaチップです。wiki見るとMarvellとかの動作報告もありますね。
IntelのSATAコントローラーをパススルーさせるとSATAのドライバーが消えて、このボードもESXiから見えなくなります。ドライバとチップの対応テーブルを編集してSATAボードとして認識させます。手順はこちらのページの通りです。感謝。
クソゲ〜製作所
作業は全てESXiのSSHコンソールです。
デバイスのIDを調べます。
# lspci -v
0000:0d:00.0 SATA controller Mass storage controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller
         Class 0106: 1b21:0612
「1b21:0612」が必要な値です。
SATAのテーブルがあるファイルを展開します。
/tmp # mkdir work
/tmp # cd work/
/tmp/work # vmtar -x /bootbank/sata_ahc.v00 -o sata-ahc.tar
/tmp/work # tar xvf sata-ahc.tar
/tmp/work # rm sata-ahc.tar
マップに1行追加。
/tmp/work # vi etc/vmware/driver.map.d/ahci.map

regtype=linux,bus=pci,id=1b21:0612 0000:0000,driver=ahci,class=storage
名前も追加。インデントはtabでした。
/tmp/work # vi usr/share/hwdata/driver.pciids.d/ahci.ids

1b21 ASMedia Technology Inc.
	0612  ASM1062 Serial ATA Controller
再アーカイブして保存。
/tmp/work # tar cvf sata-ahc.tar etc usr
/tmp/work # vmtar -c sata-ahc.tar -o sata-ahc.vgz
/tmp/work # mv sata-ahc.vgz /bootbank/sata_ahc.v00

再起動でデータストアが使えます。Intel CougarはパススルーしてOpenIndianaに渡します。
ちなみに、OIネイティブから、上記SATAボード+ちょっと古い64GB SSD(データストア)を追加して仮想化した事による消費電力のオーバーヘッドは+8Wぐらいでした。追加したハードウェア以上に増えているのは若干の処理増加分があるんでしょう。でも+8WでPCが複数台まとめられた、と考えるとお得だと思います。

FlashAir + FAX (小ネタ)

久々ですがちょっとした小ネタなど。
FlashAir買いました。


本来の目的のデジカメに使うためですが、その前にちょっとSDHCカード対応のFAXに差し込んでみました。機種はPanasonicのおたくっすシリーズ。
事前に、こちらのページ(東芝)に従い、自分のSSIDの他、家のSSIDとパスワードを設定しておきました。FlashAirにワイヤレスで接続せずに、家のアクセスポイント経由でアクセスするとどうなるのかちと不明だったんですが、結論から言うと家のネットワークからアクセス可能でした。変なアクセス制限とかはかけてないみたいです。
FlashAir差し込んで、しばらくすると家のアクセスポイントにつながり、DHCPでアドレスもらってきます。同じネットワークの機器(有線でもOK)からブラウザでそのアドレスにアクセスすると、通常通りFlashAirの中身が見えます。このFAXではJPGで保存されてました。

これでFAXをネットワーク経由のPCで見られるようになりました。便利♪
インクリボンもったいないし、毎回印刷するほどの必要性もないし、あまり頻度は高くないのでFAXをネットワーク対応のものに買い換えるほどじゃないし、どうするかな~って思ってたんですが、これでも良いかな?小容量の買ってFAX専用にしてしまうのも。
ちょっと気になったのは消費電力が+2~3W増えたこと。このカードサイズで常に2W喰ってたら熱々になりそうなので、本体側が増えたんだとは思いますが。

最後のSONY製品

オーディオでちょっと思い出したので…

昔はSONY製品好きで、何かと買っていました。Walkmanシリーズはもちろん、MD関連とかグラストロンとか。VAIOも使ってたな~
SONY「だから」買ってみるか、みたいな所もありました。そしてこの製品。
MDR-DS5100
ホームシアターとかワイヤレスヘッドフォンなんてのが盛り上がった頃の高機能機種として出てきた製品です。気になってやっぱり入手してみました。

ところが

とりあえず光ケーブルでCDをつないでみたところ、アタックの入るところやsやthなどの摩擦音が入るとAGC(自動ゲイン調整)が強烈に入り、音量がばたばたしてとても聴いてて気持ち悪い製品でした。AGCが効くとサッと音量が下がり、数秒かけてゆっくり上がるというのを繰り返します。
これ現象をSONYのサービスに質問したところ「最近のCDは音量を高めに録音しているのでそういった現象が出る」という回答。「ダイナミックレンジと録音レベルは違う話なのでは?また、CD初期の1985年頃の頃の録音でも出るので時期は関係ないのでは?」と返したら「すぐに対策品を送るので元の本体を送り返して欲しい」と来ました。こちらから送り返す前に「対策品」が到着します。
到着した「対策品」にはアッテネータースイッチが付いていて、D/A変換後のレベルを下げるという物でした。結果再生側の音量を上げることになり、ヒスノイズが酷いことになります。

これは色々な意味で残念でした。
・まずは適当な対応(録音レベルの話)で反応を見る
・納得すればそれまで
・食い下がってきた人には素直に「対策品」を送る
というマニュアルができていたと考えられます。
私が購入したのはほぼ製品発売直後だったので、「対策品」は最初から用意されていたと考えるのが自然です。リアパネルのプリント自体はシールでしたが、綺麗に穴は空いてるし、アッテネーターのスイッチは基板に付いてて、パターンも引かれてます。手半田でリワークした跡はあり、アッテネータを有効にする作業を行ったのが「対策品」のようです。
つまり最初からこの製品はダメだとわかっており、クレームが来た顧客向けに回答と「対策品」を用意しておき、製品発売に踏み込んだ、と想像されます。

ダメだとわかった時点で製品化を見送れなかったのか、ユーザはこの程度か、好きだっただけに結構ショックで(今でも覚えてるぐらいですしw)、これ以降SONYの製品に興味が無くなってしまいます。嫌いになるならまだ救いがあったんでしょうが、好き・嫌いとは真逆の感情、無関心、になってしまったわけです。

PlayStationとかSONYの製品を持ってないわけではありません。けど、SONY「だから」買った、のはこの製品が最後となってしまいました。ちょっとしか使いませんでしたが、なんか捨てられず、15年目になった今も手元にあります。

オーディオ環境

あけましておめでとうございます。
今年はちょっとは役立つ内容も書きたいですね~

といいつついきなりなんの役にも立たない書き込みです。
事の発端はこちら。TU-879S最終生産
初心者向け真空管アンプの定番キットという認識で、そのうち買いたいな~なんて思ってたら生産終了とのこと。


ついポチってしまいました。で、買ったは良いけど作る暇無くそのままほったらかし…
ちょっとずつ作ってようやく音出しとか、そんな状態です。
ちなみに当方、耳が良いとかそんなこととても言えません。目隠しされてストラトヴァリウスとヤマハを聴かされても言い当てられないでしょう。ましてや光ケーブルの種類とか記録媒体のHDDとかで音が変わるという、そんなオカルティックな聴力はありません。というかそんなの聞き分けられたら鬱陶しいので欲しくもありませんが。
その程度の耳でも真空管アンプは聴いてて面白く、CDとかiPodから音を流してます。
で、もうちょっと便利にしよう、ってことで

audio-technica USBヘッドホンアンプ 24bit/96kHZ対応 AT-HA40USB

audio-technica USBヘッドホンアンプ 24bit/96kHZ対応 AT-HA40USB

  • 出版社/メーカー: オーディオテクニカ
  • メディア: エレクトロニクス

こちらとRaspberryPiを追加購入。RaspyFiを導入してネットワークプレーヤーに仕立て上げます。
といっても特にやること無し。RaspyFiのイメージをダウンロードしてSDカードに書き込み、RaspberryPiとAT-HA40USBをつないで電源入れるだけ。やったことと言えばIPアドレスを固定した事ぐらいでしょうか。これもブラウザ経由のGUIで済みます。
Image 016.png
NASの音源フォルダをNFSで公開してRaspyFiにマウントさせたら完了。ADD NEW MOUNTを押してNASを指定します。USBにFlashか余ってるHDDをつないだ方が手軽で良いかもしれませんね。
Image 014.png
そのままでAT-HA40USBから音が出てくれました。ハードウェア音量制御もOK。MPD Configurationから下の方のMixer TypeをHardwareにするとAT-HA40USB側の音量制御が使われるようです。
Image 015.png
ほとんどCDからのFLACやMP3でハイレゾ音源では無いですが音も十分綺麗。こちらはWEBラジオの再生中。
Image 019.png
選曲、選局、音量をタブレット端末やPCのブラウザで操作します。専用アプリじゃ無くてもこれが便利。安定度も高く、うっかり止め忘れたWEBラジオが数日流れてても平気な顔してます。日本のラジオ局も登録しようかな~
安いので良いんだけど、さすがに自分でノイズ対策するの面倒だしある程度の物を、ってことで選んだAT-HA40USBでしたが、これまた便利。出力が3系統あり、ライン出力で真空管アンプ、光出力でミニコンポ、ヘッドホンと使い分けてます。真空管アンプ良いんですが消費電力が高いので、普段はミニコンポからBGM出してます。大体70W対10Wぐらい。D級アンプは効率よいですね~ほとんど熱くならないし、夏場は真空管アンプはお休みでしょうか。大体この省電力時代に70Wも喰って出力数Wってのが間違えてるんですが(笑)
前の10件 | -