<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0">
<channel>
	<title>BSD小僧の日記</title>
	<link>http://www.tokuda.net/diary/</link>
	<language>ja</language>
	<description></description>
	<copyright>Copyright 2012</copyright>
	<pubDate>Wed, 16 May 2012 07:08:20 GMT</pubDate>
	<lastBuildDate>Wed, 16 May 2012 07:08:20 GMT</lastBuildDate>
	<generator>http://adiary.abk.nu/#2.21</generator>
	<docs>http://blogs.law.harvard.edu/tech/rss</docs> 
	<item>
		<title>NetBSDで3TBのHDDを扱う (gpt, dkctl)</title>
		<link>http://www.tokuda.net/diary/0787#tm1337152100</link>
		<guid>http://www.tokuda.net/diary/0787</guid>
		<category>NetBSD</category>
		<pubDate>Tue, 15 May 2012 16:36:44 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
3TBのHDDはNetBSDでどう扱えば良いのでしょうか？<br>
<br>
Linuxのときに少し手間取ったので、何かあるなと思ってはいましたが、やっぱりいくつか失敗しながらなんとか使えるようになりました。少しまとめておきます。<br>
<br>
まずは、こんな感じで見えてます。<br>
<pre>
root@zbox&gt;dmesg | grep sd0
sd0 at scsibus0 target 0 lun 0: &lt;I-O DATA, HDCA-U, 1337&gt; disk fixed
sd0: 2794 GB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 5860533168 sectors
</pre>
大きなHDDはfdiskが使えないのでLinuxではpartedを使いました。<br>
partedはpkgsrc/wipにあり、これを使おうとmakeするとLinuxだけだよと怒られます。<br>
<br>
じつはgptコマンドというそのものズバリのコマンドがあり、これを使えば良いというのを初めてしりました。<br>
<br>
まずは、ディスクの状態を見てみます。<br>
<pre>
root@zbox&gt;gpt show sd0
       start        size  index  contents
           0           1         PMBR
           1  5860533134         
  5860533135          32         Sec GPT table
  5860533167           1         Sec GPT header

</pre>
なんか、セカンダリGPT table, headerしかない変な状態に見えます。<br>
ということで一度クリアすることにしました。<br>
<br>
gpt destroyで情報を消します。<br>
<pre>
root@zbox&gt;gpt destroy sd0
root@zbox&gt;gpt show sd0
       start        size  index  contents
           0           1         PMBR
           1  5860533167         

</pre>
あらたにgpt createで区画を作ります。<br>
<pre>
root@zbox&gt;gpt create sd0
root@zbox&gt;gpt show sd0
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34  5860533101         
  5860533135          32         Sec GPT table
  5860533167           1         Sec GPT header
</pre>
ちゃんとプライマリの情報とセカンダリの情報ができてます。区画情報を冗長化してるんですかね。<br>
<br>
man gptのEXAMPLEに近い状態になったので、いざ、先に進みます。<br>
<br>
まずは区画を作ります。デフォルトだとFFSでディスク全体を区画にします。<br>
今回はでかい区画が欲しいのでこれでよしとします。<br>
<pre>
root@zbox&gt;gpt add sd0
Partition added, use:
        dkctl sd0 addwedge &lt;wedgename&gt; 34 5860533101 &lt;type&gt;
to create a wedge for it
root@zbox&gt;gpt show sd0
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34  5860533101      1  GPT part - NetBSD FFSv1/FFSv2
  5860533135          32         Sec GPT table
  5860533167           1         Sec GPT header
</pre>
区画にラベルをふってあげます。名前を付ける感じですね。<br>
ラベル名はgpt showに-lをつけると見えるようです。最初は空っぽ。<br>
<pre>
root@zbox&gt;gpt show -l sd0
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34  5860533101      1  GPT part - ""
  5860533135          32         Sec GPT table
  5860533167           1         Sec GPT header
</pre>
gpt labelに区画を指定する引数を与えて名前を付けます。今回はshareという名前にしました。<br>
<pre>
root@zbox&gt;gpt label -i 1 -l share sd0
partition 1 on rsd0d labeled share

root@zbox&gt;gpt show -l sd0
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34  5860533101      1  GPT part - "share"
  5860533135          32         Sec GPT table
  5860533167           1         Sec GPT header
</pre>
これで区画ができたので使えるようにしましょう。<br>
いつものようにdisklabelです。最初は空っぽ。<br>
<pre>
root@zbox&gt;disklabel -r sd0
disklabel: could not read existing label
</pre>
disklabel -i -I sd0あたりでそれっぽいラベルを作ります。<br>
<pre>
root@zbox&gt;disklabel sd0
# /dev/rsd0d:
type: SCSI
disk: HDCA-U          
label: fictitious
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 16383
total sectors: 1565565872
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0 

4 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a: 1565565872         0     4.2BSD      0     0     0  # (Cyl.      0 - 1553140*)
 d: 1565565872         0     unused      0     0        # (Cyl.      0 - 1553140*)
</pre>
作ったらnewfsしてマウントです。newfsではrawデバイスを指定しないといけなかったですね。<br>
<pre>
root@zbox&gt;newfs -O2 /dev/sd0a
newfs: /dev/sd0a is a block device. use raw device

root@zbox&gt;newfs -O2 /dev/rsd0a
/dev/rsd0a: 764436.5MB (1565565872 sectors) block size 16384, fragment size 2048
        using 4133 cylinder groups of 184.98MB, 11839 blks, 22976 inodes.
super-block backups (for fsck_ffs -b #) at:
160, 379008, 757856, 1136704, 1515552, 1894400, 2273248, 2652096, 3030944, 3409792, 3788640, 4167488, 4546336, 4925184, 5304032, 5682880, 6061728, 6440576, 6819424, 7198272,
..................................................................................................................................................................................

root@zbox&gt;mount /dev/sd0a /mnt
root@zbox&gt;df -k
Filesystem    1K-blocks       Used      Avail %Cap Mounted on
/dev/wd0a      77398560   20353514   53175118  27% /
kernfs                1          1          0 100% /kern
ptyfs                 1          1          0 100% /dev/pts
procfs                4          4          0 100% /proc
/dev/sd0a     758910582          2  720965052   0% /mnt
</pre>
見事に使えるようになりました。<br>
<br>
でも、おかしいですね。3TBにしては小さすぎます。<br>
もしかしたらdisklabelでは3TBは扱えないのかも、とおもってmanを読むと、BUGSに<br>
<pre>
The disklabel structure stored on disk cannot support partitions/disks
     greater than 2TB.  Please use gpt(8) and dkctl(8) to manage partitions
     and disks larger than 2TB.
</pre>
ありゃ、やっぱりそうでしたか。ここにあるgptは使ったけど、dkctlって何でしょう。<br>
<br>
そういえば、gpt addしたときのコマンドの応答にそういうのがあったような...<br>
<pre>
root@zbox&gt;gpt add sd0
Partition added, use:
        dkctl sd0 addwedge &lt;wedgename&gt; 34 5860533101 &lt;type&gt;
to create a wedge for it
</pre>
おぉ、これです。もしかしたら、このコマンドで区画を有効化しなさいということなのかも。<br>
<br>
まずは、umountします。<br>
<pre>
root@zbox&gt;umount /mnt
</pre>
さっきのコマンドに引数をいくつか与えて実行してみます。<br>
wedgenameはsd0a, typeはffsにしました。wedgenameは、少し考えて、ださいけどこうしました。<br>
<pre>
root@zbox&gt;dkctl sd0 addwedge sd0a 34 5860533101 ffs
dk0 created successfully.
</pre>
どうやらdk0というのがfdiskでいうsd0aに相当するみたいですね。<br>
情報を見てみます。<br>
<pre>
root@zbox&gt;dkctl sd0 listwedges
/dev/rsd0d: 1 wedge:
dk0: sd0a, 5860533101 blocks at 34, type: ffs
</pre>
やっぱりwedgenameはshareとかにすべきでしたねー。<br>
<br>
まぁ、それほど見る機会もないだろうからnewfsしちゃいましょう。<br>
<pre>
root@zbox&gt;newfs -O2 dk0
/dev/rdk0: 2861588.4MB (5860533100 sectors) block size 16384, fragment size 2048
        using 15470 cylinder groups of 184.98MB, 11839 blks, 22976 inodes.
super-block backups (for fsck_ffs -b #) at:
160, 379008, 757856, 1136704, 1515552, 1894400, 2273248, 2652096, 3030944, 3409792, 3788640, 4167488, 4546336, 4925184, 5304032, 5682880, 6061728, 6440576, 6819424, 7198272,
..................................................................................................................................................................................
</pre>
いざ、mountです<br>
<pre>
root@zbox&gt;mount /dev/dk0 /mnt
root@zbox&gt;df -g
ilesystem    1G-blocks       Used      Avail %Cap Mounted on
/dev/wd0a            73         19         50  27% /
kernfs                0          0          0 100% /kern
ptyfs                 0          0          0 100% /dev/pts
procfs                0          0          0 100% /proc
/dev/dk0           2709          0       2573   0% /mnt
</pre>
きましたね。ちゃんと2TB以上の領域として認識したみたいです。<br>

</div>

<hr>
<h4><a href="/diary/0787#c">■コメント（1件）</a></h4>
<div style="margin-left: 1em;">
sage『gptパーティションの開始セクタは8の倍数にしたほうが良いかと(4kセクタ問題対策)』(2012/05/16 16:08)</span><br>
</div>
<h4><a href="/diary/0787#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>ZBOX nano VD01でBluetoothを使う (2)</title>
		<link>http://www.tokuda.net/diary/0786#tm1335854061</link>
		<guid>http://www.tokuda.net/diary/0786</guid>
		<category>NetBSD</category>
		<pubDate>Tue, 01 May 2012 06:19:13 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
前回、長々と書いた割には<a href="http://www.netbsd.org/docs/guide/en/chap-bluetooth.html">The NetBSD Guide Chapter 21 Bluetooth on NetBSD</a>の最初の所までしか進んでいませんでした。<br>
<br>
やっと内蔵のBluetoothモジュールが認識されたので、今回はマウスとキーボードを使えるところまで進めたいと思います。<br>
<br>
今回の内容はZBOX固有というよりNetBSDでのbluetooth利用の一般的な手順になりますかね。<br>
</div>

<div>
<h3><a href="http://www.tokuda.net/diary/0786#k786p1"><span>■</span></a>準備</h3>
まずは/etc/rc.confに<br>
<pre>
bluetooth=YES
</pre>
と書いてbluetooth関連の有効化を行い、再起動もしくは<br>
<pre>
/etc/rc.d/bluetooth start
</pre>
と入力してサービスを有効にします。<br>
<br>
bluetoothの設定で触るファイルはたったの二つです。一つは/etc/bluetooth/hosts、二つ目は/etc/bluetooth/btdevctl.confです。<br>
<br>
/etc/bluetooth/hostsは/etc/hostsのbluetooth版と思えば良く、bluetoothデバイスの一つ一つに与えられている固有のID (MACアドレスみたいなもの) に名前を付けるものです。<br>
<br>
/etc/bluetooth/btdevctl.confはシステムの起動時に登録しておきたい (動くようにしておきたい) 各種bluetoothデバイスを書いておくものです。たとえばキーボードなんかは起動時に自動的に登録されていないと困りますからね。<br>
<br>
まず/etc/bluetooth/hostsを作りましょう。<br>
<br>
bluetoothデバイスは必ずデバイス登録モードのようなものをもっていて、ボタンの長押しであったりbluetoothロゴが書かれたボタンを押したりするとそのモードに入ります。たいていはLEDが点滅したりして「登録モードですよ」って言う感じになります。先の文書ではdiscoverable modeと書かれています。発見可能モードと呼ぶべきかな。<br>
<br>
デバイスをそのモードにしておいて、btconfigコマンドを次のように入力すると、お目当てのデバイスがレスポンスを返してくれます。<br>
<pre>
# btconfig ubt0 inquiry
Device Discovery from device: ubt0 ... 1 response
  1: bdaddr XX:XX:XX:XX:XX:XX
   : name "Bluetooth Keyboard"
   : class [0x002540] Peripheral Keyboard &lt;Limited Discoverable&gt;
   : page scan rep mode 0x01
   : clock offset 15398
   : rssi 0
</pre>
上記の例だと一つしか見つかっていませんが、複数のデバイスが見つかることもあります。どうせなら一気にやってしまった方が楽なので片っ端からbluetoothデバイスをピカピカと点滅させてやるといいかもしれません。<br>
<br>
ここで大切なのはbdaddrという部分に書かれたコロンで区切られたアドレスです。/etc/bluetooth/hostsにはこのアドレスとそれを表す名前を付けてあげます。名前は自由に決めることができます。<br>
<br>
今回はノーブランドのbluetoothキーボードとAppleのMightyMouseを使いました。/etc/bluetooth/hostsには以下のように書きました (bdaddrは潰してあります)。<br>
<pre>
XX:XX:XX:XX:XX:XX keyboard
YY:YY:YY:YY:YY:YY mightymouse
</pre>
これを書くことで長くて覚えにくいbdaddrを使うことなくキーボードはkeyboard、マウスはmightymouseと呼ぶことができるようになります。<br>
</div>

<div>
<h3><a href="http://www.tokuda.net/diary/0786#k786p2"><span>■</span></a>キーボード</h3>
それでは実際にキーボードを使えるようにしてみましょう。<br>
<br>
キーボードを使えるようにするためには、いくつかの手順を実行する必要があります。<br>
<ol>
	<li> キーボード側をdiscoverable modeにする (LED点滅ですね)</li>
	<li> PC側でPINを発行する (5分間有効)</li>
	<li> PC側でデバイスをアタッチするコマンドを発行する</li>
	<li> キーボード側で先ほど発行されたPINを入力する(最後にEnterキー)</li>
</ol>
まずキーボード側をdiscoverable modeにします。<br>
<br>
次にはbtpinを使ってPINを発行します。<br>
<pre>
# btpin -d ubt0 -a keyboard -r -l 8
PIN: 82526229
</pre>
btpinのマニュアルによると、このPINは5分間有効なのだそうです。なので、この後の手順はテキパキと行う必要があります。<br>
<br>
次に、btdevctlを-Aオプションをつけて (つまりAttachをさせるようにして) 実行します。<br>
<pre>
# btdevctl -d ubt0 -a keyboard -s HID -A
</pre>
このコマンドは実行後すぐにプロンプトに戻ってくるためAttachしていないような気になりますが、実はキーボード側からPINが入力されるのを待って、それが正しければAttachを完了させるような立て付けになっているみたいです。ここで表示されるメッセージはあまり気にしなくてよいです。<br>
<br>
ということで、キーボード側で先ほどbtpinで表示された8桁のPINを入力し、Enterキーを押します。<br>
<br>
するとPC側にデバイスが認識された旨が表示されます。キーボードから文字が入力できるようになっているはずです。<br>
<br>
PINコード発行から5分経過するなどのタイムアウトに引っかかったりPINを打ち間違えたときにはAttachが中途半端な状態になっているため、次のコマンドでDetachしてAttach前に戻してあげる必要があります。<br>
<pre>
# btdevctl -d ubt0 -a keyboard -s HID -D
</pre>
PINの発行やAttachのタイミングなどで、わりと失敗するので何度かこのコマンドにお世話になりました。<br>
<br>
個人的にうまく動かなくて困ったのは、先の文書でPINをいつ打ち込めば良いのかわからなかったことです。btpinを入力した後すぐにキーボードからPINを打ち込んで、うまくいかないなー、と思っていたのですがbtdevctlコマンドがしばらくしてからデバイスをdetachしていたので、実はbtdevctl -AのあとにPINを入れるんじゃないかと気づいたのです。<br>
</div>

<div>
<h3><a href="http://www.tokuda.net/diary/0786#k786p3"><span>■</span></a>マウス</h3>
さて、次はマウスをつないでみましょう。<br>
<br>
すでに/etc/bluetooth/hostsに登録されていますから、あとはキーボードとほぼ同じくbtpinによるPIN発行とbtdevctlによるAttachだけです。<br>
<br>
キーボードとの違いはPINが固定ということでしょうか。キーボードのようにPINを入力する方法がないのだから当たり前ですね。<br>
<br>
キーボードの場合はPC側でPINを発行して、それをキーボードで打ち込むことによって接続が確立できましたが、マウスの場合は逆のイメージで、マウスが期待しているPINコード (0000らしいですね) を逆にbtpinに指定して実行してからマウス側をアタッチするみたいな感じです。<br>
<br>
まず、マウスをdiscoverable modeにします。MightyMouseの場合はマウス受講部のシャッター開閉ですね。<br>
<br>
次にbtpinコマンドをPINコード0000に指定して実行し、btdevctl -Aを実行します。<br>
<pre>
# btpin -d ubt0 -a mightymouse -p 0000
# btdevctl -d ubt0 -a mightymouse  -s HID -A
</pre>
マウスはPC側と勝手におしゃべりして接続を確立してくれるみたいで簡単ですね。<br>
</div>

<div>
<h3><a href="http://www.tokuda.net/diary/0786#k786p4"><span>■</span></a>自動起動</h3>
これでマウスとキーボードがどちらも使えるようになりました。再起動時にもデバイスを使えるようにするために/etc/bluetooth/btdevctl.confに次のように記述します。<br>
<pre>
HID    keyboard        ubt0
HID    mightymouse     ubt0
</pre>
これで再起動時に先ほどのbtdevctl -Aをシステム側で自動実行してくれます。<br>
<br>
さて、再起動時にはPINコードが必要でしょうか?　必要だととっても面倒です。<br>
<br>
実はこの情報は/var/db/bthcid.keysに保存されているようですね。これを使って再起動時にはPINコードの入力を必要とせずにデバイスが利用可能になっています。<br>

</div>

<hr>
<h4><a href="/diary/0786#c">■コメント（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
<h4><a href="/diary/0786#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>GW-USValue-EZをNetBSDで使う</title>
		<link>http://www.tokuda.net/diary/0785#tm1335108201</link>
		<guid>http://www.tokuda.net/diary/0785</guid>
		<category>NetBSD</category>
		<pubDate>Sun, 22 Apr 2012 15:23:21 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
11n/g/b対応の小型の無線LANアダプタGW-USValue-EZが届いたのでNetBSDで使えるかどうか試してみました。<br>
<br>
まず、何も考えずに挿してみるとugenです。あーそうかー。<br>
<br>
ということで、型番で検索するとどうやらRTL8192というチップを使っている代物のようです。チップ名とNetBSDで検索するとOpenBSDからの移植がされているとの情報が。twitterでつぶやくと-currentには入っていると教えてもらいました。<br>
<br>
2012/4/21のkernelに入れ替えてみると、見事にurtwnで認識です。<br>
<pre>
urtwn0 at uhub4 port 1
urtwn0: GW-USValue-EZ GW-USValue-EZ, rev 2.00/2.00, addr 4
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address XX:XX:XX:XX:XX:XX
urtwn0: 1 rx pipe, 2 tx pipes
urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
</pre>
ところがいざ使おうとすると、<br>
<pre>
urtwn0: failed loadfirmware of file urtwn-rtl8192cfwT (error 2)
urtwn0: cannot assign link-local address
urtwn0: failed loadfirmware of file urtwn-rtl8192cfwT (error 2)
urtwn0: failed loadfirmware of file urtwn-rtl8192cfwT (error 2)
urtwn0: cannot assign link-local address
</pre>
ということで使えません。どうやらファームウェアがないようです。<br>
<br>
<a href="http://netbsd.gw.com/cgi-bin/man-cgi?urtwn++NetBSD-current">urtwn (4)</a>をみると<a href="http://firmware.openbsd.org/firmware/urtwn-firmware-1.1p0.tgz">http://firmware.openbsd.org/firmware/urtwn-firmware-1.1p0.tgz</a>にfirmwareがあるということでダウンロードしてきます。<br>
<br>
その中にあるファイルを/libdata/firmware/urtwnというディレクトリを作ってコピーしておきます。いやー、ubtのときにディレクトリ名で苦労しただけに、今回はさくっと<a href="http://nxr.netbsd.org/xref/src/sys/dev/usb/if_urtwn.c#urtwn_load_firmware" title="NetBSD">sys/dev/usb/if_urtwn.c#urtwn_load_firmware</a>を確認できました。<br>
<br>
以上で準備完了。ちゃんと通信できています。すばらしい！<br>

</div>

<hr>
<h4><a href="/diary/0785#c">■コメント（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
<h4><a href="/diary/0785#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>OpenGrokをローカルで動かしてソースコードを読むために</title>
		<link>http://www.tokuda.net/diary/0784#tm1333849193</link>
		<guid>http://www.tokuda.net/diary/0784</guid>
		<category>NetBSD</category>
		<pubDate>Sun, 08 Apr 2012 01:39:53 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
ソースコードを追っかけるときに大変お世話になっている<a href="http://nxr.netbsd.org">http://nxr.netbsd.org</a>ですが、ここで使われているのはOpenGrokというツールです。<br>
<br>
手元で動くとうれしいなぁということでpkgsrcを探すとdevel/opengrokがありました。<br>
<br>
ここではNetBSDのsrc, xsrcを対象にOpenGrokをWebブラウザで使えるところまでの記録をしておきたいと思います。<br>
<br>
まず、devel/opengrok, www/apache-tomcat7をpkgsrcからインストールします。<br>
OpenJDKのインストールに結構時間がかかりました。<br>
<br>
次に、NetBSDのソースを用意します。/export/s/HEADに置くことにしました。<br>
ここでcvs -d /cvsroot/NetBSD srcなどとしてsrcやxsrcをチェックアウトしておきます。<br>
<br>
/usr/pkg/share/opengrokに移動して、run.shに次のようなパッチをあてます。<br>
<pre>
--- run.sh.orig	2012-04-04 00:38:41.000000000 +0000
+++ run.sh	2012-04-05 11:18:37.000000000 +0000
@@ -3,7 +3,7 @@
 PROGDIR=/usr/pkg/share/opengrok
 
 # REQUIRED The root of your source tree
-SRC_ROOT=/your/src/tree/
+SRC_ROOT=/export/s/HEAD
 
 # REQUIRED  The directory where the data files like
 # Lucene index and hypertext cross-references are stored
@@ -18,13 +18,14 @@
 EXUB_CTAGS=/usr/pkg/bin/exctags
 
 # If you need to set properties (Ex. override the mercurial binary)
-#PROPERTIES=-Dorg.opensolaris.opengrok.history.Mercurial=/home/trond/bin/hg
+PROPERTIES=-Dorg.opensolaris.opengrok.history.cvs=/usr/bin/cvs
 
 # Uncomment the following line if your source contains Mercurial repositories.
 # SCAN_FOR_REPOS="-S"
+SCAN_FOR_REPOS="-S -H -v -r on -W ./configuration.xml"
 
 # You might want to add more available memory, and perhaps use a server jvm?
-#JAVA_OPTS="-server -Xmx1024m"
+JAVA_OPTS="-server -Xmx1024m"
 
 LOGGER="-D/usr/pkg/java/openjdk7/bin/java.util.logging.config.file=conf/logging.properties"
</pre>
ポイントはSCAN_FOR_REPORSに与えた引数ですかね。あ、あとJAVA_OPTSはどっちでもいいのかなと思っていたら、今回のような大きなソースを食わせる時にはこのオプションをつけておかないと解析が全然終わらないことがわかったので有効にしています。<br>
<br>
次に、source.warを/usr/pkg/share/tomcat/webappsにコピーします。このsource.warはconfiguration.xmlが/var/opengrok/etcにあることを期待しているので、生成されたconfuguration.xmlを/var/opengrok/etcに置きます。ディレクトリは自分で作ってあげないといけません。<br>
<br>
<br>
次に/usr/pkg/share/tomcat/bin/startup.shを実行してTomcatを起動します。これで準備完了です。<br>
<br>
Webブラウザでhttp://localhost:8080/sourceにアクセスすれば<a href="http://nxr.netbsd.org">http://nxr.netbsd.org</a>とほぼ同じことが手元のマシンで可能になります。やった！<br>

</div>

<hr>
<h4><a href="/diary/0784#c">■コメント（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
<h4><a href="/diary/0784#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>USBディスプレイ LCD-8000Uをudl(4)で使う (X Window System編)</title>
		<link>http://www.tokuda.net/diary/0783#tm1332572813</link>
		<guid>http://www.tokuda.net/diary/0783</guid>
		<category>NetBSD</category>
		<pubDate>Sat, 24 Mar 2012 07:06:53 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
<p>ZBOXを持ち出すときに小さなディスプレイがあると便利そうなのでCenturyのLCD-8000Uを購入しました。こいつはudl(4)で動くことが報告されているので安心です。</p>
<p>udlはすでにNetBSDに取り込まれているのでテキストコンソールであれば何もしなくても動くのだそうです。</p>
<p>ところが、i386では内臓のVGAがwsdisplay0で先に使われてしまい、あれこれ試してみたのですが、やり方がまずいらしく動かすことができませんでした。</p>
<p>ずいぶん前にudlを試したときにはうまく動いて満足したと記憶しているのですが、その時も確かテキストコンソールは試さず、Xが動いて喜んでいた気がします。</p>
<p>今回も、いっそのことX Window Systemを動かした方が楽なんじゃないかと思い、そっちに方針変更することにしました。</p>
<p>Xを動かすためには標準のNetBSDにいくつか修正が必要になります。基本的には、ふかうみさんの<a href="http://www.naobsd.org/udl/">http://www.naobsd.org/udl/</a>にあるものを使えば良いだけです。</p>
<p>修正点は大きく、kernelに対する修正とudl用のディスプレイドライバの追加になります。</p>
<p>kernelについては圧縮・展開を司るmicrocodeの追加とudlに対するioctlの追加です。</p>
<table>
<tbody>
	<tr><th>追加・修正</th><th>説明</th></tr>
	<tr><td>src/sys/dev/microcode/Makefile</td><td>udlのmicrocodeを追加</td></tr>
	<tr><td>src/sys/dev/microcode/udl</td><td>新規追加するディレクトリ</td></tr>
	<tr><td>src/sys/dev/microcode/udl/*</td><td>ふかうみさんのkern.diffからそのまま</td></tr>
	<tr><td>src/sys/dev/usb/Makefile</td><td>ioctlを定義したudlio.hの追加</td></tr>
	<tr><td>src/sys/dev/usb/udl.c</td><td>無効化されているioctlを有効化する定義を追加 (#define notyet 1)</td></tr>
	<tr><td>src/sys/dev/usb/udlio.h</td><td>ioctlを定義したudlio.hの実体 (kern.diffより)</td></tr>
</tbody></table>
<p>Xのドライバに関する修正はsrcとxsrcの両方に必要になります。</p>
<table>
<tbody>
	<tr><th>追加・修正</th><th>説明</th></tr>
	<tr><td>src/external/mit/xorg/server/drivers/Makefile</td><td>xf86-video-wsudlの記述を追加</td></tr>
	<tr><td>src/external/mit/xorg/server/drivers/xf86-video-wsudl</td><td>新規作成</td></tr>
	<tr><td>src/external/mit/xorg/server/drivers/xf86-video-wsudl/Makefile</td><td>ふかうみさんのsrc.diffそのまま</td></tr>
	<tr><td>src/share/mk/bsd.own.mk</td><td>wsudlの記述を追加</td></tr>
</tbody></table>
<p>xsrc</p>
<table>
<tbody>
	<tr><th>追加・修正</th><th>説明</th></tr>
	<tr><td>xsrc/external/mit/xf86-video-wsudl</td><td>新規追加</td></tr>
	<tr><td>xsrc/external/mit/xf86-video-wsudl/*</td><td>ふかうみさんのxsrc.diffをベースにwsudl_driver.cを少し修正</td></tr>
	<tr><td>xsrc/external/mit/xorg-server/dist/hw/xfree86/os-support/bsd/bsd_init.c</td><td>ふかうみさんのxsrc.diffに含まれるパッチそのまま</td></tr>
</tbody></table>
<p>基本はふかうみパッチベースで良いのですが、wsudl_driver.cについては最新のxsrcへの追従が必要でした。</p>
<pre>
--- wsudl_driver.c	2012-03-24 05:47:46.000000000 +0000
+++ wsudl_driver.c.new	2012-03-21 19:36:45.000000000 +0000
@@ -67,6 +67,7 @@
 
 #include "xf86.h"
 #include "xf86_OSproc.h"
+#include "xf86_OSlib.h"
 
 #include "mipointer.h"
 #include "mibstore.h"
@@ -76,8 +77,10 @@
 
 #include "fb.h"
 
+#if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) &lt; 6
 #include "xf86Resources.h"
 #include "xf86RAC.h"
+#endif
 
 #include "damage.h"
 
@@ -354,8 +357,10 @@
 
 	fPtr-&gt;pEnt = xf86GetEntityInfo(pScrn-&gt;entityList[0]);
 
+#if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) &lt; 6
 	pScrn-&gt;racMemFlags = RAC_FB | RAC_COLORMAP | RAC_CURSOR | RAC_VIEWPORT;
 	pScrn-&gt;racIoFlags = pScrn-&gt;racMemFlags;
+#endif
 
 	/* open wsdisplay device */
 	dev = xf86FindOptionValue(fPtr-&gt;pEnt-&gt;device-&gt;options, "device");
</pre>
<p>上記の修正を<a href="http://www.tokuda.net/NetBSD/udl/6.99.3/">http://www.tokuda.net/NetBSD/udl/6.99.3/</a>にとりあえず置きました。パッチはバラバラでいまいちですけど。</p>
<p>アドホックに作業していたので、src/share/mk/bsd.own.mkの修正を入れ忘れて、ドライバ単体のコンパイル時に/configureなんて実行できねぇ、とか怒られたりしながらなんとかkernelとwsudl_drv.soを作ることができました。</p>
<p>openchromeドライバでの教訓をいかして、OBJディレクトリではlibwsudl_drv.soになっているのをwsudl_drv.soに忘れずリネームして/usr/X11R7/lib/modules/driversに置きます。</p>
<p>次のようなxorg.confを書いてstartxします。</p>
<pre>
Section "ServerLayout"
	Identifier     "X.org Configured"
	Screen      0  "Screen0" 0 0
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
	ModulePath   "/usr/X11R7/lib/modules"
	FontPath     "/usr/X11R7/lib/X11/fonts/misc/"
	FontPath     "/usr/X11R7/lib/X11/fonts/TTF/"
	FontPath     "/usr/X11R7/lib/X11/fonts/Type1/"
	FontPath     "/usr/X11R7/lib/X11/fonts/100dpi/"
	FontPath     "/usr/X11R7/lib/X11/fonts/75dpi/"
EndSection

Section "Module"
	Load  "dbe"
	Load  "dri"
	Load  "dri2"
	Load  "extmod"
	Load  "glx"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "Protocol" "wskbd"
	Option	    "Device" "/dev/wskbd"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option	    "Protocol" "wsmouse"
	Option	    "Device" "/dev/wsmouse"
EndSection

Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
EndSection

Section "Device"
	Identifier  "Card0"
	Driver      "wsudl"
	Option      "device" "/dev/wsdisplay1"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Card0"
	Monitor    "Monitor0"
	DefaultDepth 16
	SubSection "Display"
		Viewport   0 0
		Depth     16
	EndSubSection
EndSection
</pre>
<p>あれぇ、起動しません。</p>
<pre>
[    52.840] (EE) wsudl(0): We are not attached to the udl driver
</pre>
<p>こんなエラーを吐いてモジュールをアンロードするメッセージに続いています。</p>
<p>不思議に思いながらこのエラーメッセージでソースを追いかけてみます。</p>
<pre>
        /* open wsdisplay device */
        dev = xf86FindOptionValue(fPtr-&gt;pEnt-&gt;device-&gt;options, "device");
        fPtr-&gt;fd = wsudl_open(dev);
        if (fPtr-&gt;fd == -1)
                return (FALSE);

        /* check if we are attached to the right device driver */
        r = ioctl(fPtr-&gt;fd, WSDISPLAYIO_GTYPE, &amp;wstype);
        if (r == -1) {
                xf86DrvMsg(pScrn-&gt;scrnIndex, X_ERROR,
                    "ioctl WSDISPLAYIO_GTYPE: %s\n", strerror(errno));
                return (FALSE);
        }
        if (wstype != WSDISPLAY_TYPE_DL) {
                xf86DrvMsg(pScrn-&gt;scrnIndex, X_ERROR,
                    "We are not attached to the udl driver\n");
                return (FALSE);
        }
</pre>
<p>うーん、なんだかなー、と思いながら上の方を見ると"device"という文字列が。</p>
<p>あー、そういえばxorg.confのOptionでdeviceを/dev/wsdisplay1に設定していたなー。</p>
<p>ん?! そういえば、<a href="http://www.naobsd.org/udl/README.txt">http://www.naobsd.org/udl/README.txt</a>に</p>
<pre>
# cd /dev
# mknod -m 600 wsdisplay1 c wsdisplay 256
# mknod -m 600 wsdisplay1cfg c wsdisplay 511
# wsconscfg -f /dev/wsdisplay1cfg 0
</pre>
<p>って書いてあったけど、作ったっけ? ていうか、前に作ったけど起動するたびに消えちゃうんで困ってたんだったよなー。もしかしてデバイスをopenできないんじゃないの?</p>
<p>っていうことで、wsdisplay1とwsdisplay1cfgをmknodして、いざ、startx!</p>
<p>おー、ちゃんと動きましたぞ。</p>
<p><a title="IMG_20120324_001517.jpg" href="http://www.tokuda.net/diary/public/image/tokuda/201203/IMG_20120324_001517.jpg"><img alt="IMG_20120324_001517.jpg" src="http://www.tokuda.net/diary/public/image/tokuda/201203/.thumbnail/IMG_20120324_001517.jpg.jpg"></a></p>
<p>残された課題としては、テキストコンソールはどうやるのか、/devにいつもwsdisplay1関連のデバイスが追加されるようにするにはどうするのか、があるので、少しづつ解決していきたいと思います。</p>

</div>

<hr>
<h4><a href="/diary/0783#c">■コメント（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
<h4><a href="/diary/0783#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>ZBOX nano VD01でBluetoothを使う</title>
		<link>http://www.tokuda.net/diary/0782#tm1332100226</link>
		<guid>http://www.tokuda.net/diary/0782</guid>
		<category>NetBSD</category>
		<pubDate>Sun, 18 Mar 2012 19:50:26 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
ZBOX nano VD01にはBluetoothが装備されているらしく、せっかくだから使ってみましょうと思い立ちました。<br>
<br>
<a href="http://www.netbsd.org/docs/guide/en/chap-bluetooth.html">The NetBSD Guide Chapter 21 Bluetooth on NetBSD</a>という文書を発見。<br>
<br>
ほー、これは助かる。と思いつつ読みはじめて、まずデバイスを認識してなきゃ話になりませんなー、ということでubtがあるのか確認です。<br>
<br>
...<br>
<br>
ubtはありませんでした。なんだかな。うーんと思いつつbtで検索すると次のようなメッセージが。<br>
<pre>
aubtfwl0 at uhub3 port 1
aubtfwl0: ath3k-1.fw open fail 2
</pre>
man aubtfwlしても何も出てきません。とはいえ、これまで見たこともないデバイス名ですし、なんだか気になるので調べてみるとどうやらAtherosのBluetoothのためのドライバのようです。おぉ、なんとかとっかかりを見つけることができたようです。<br>
<br>
しかし、Atherosといえば無線LANとばかり思っていましたが、いわれてみればBluetoothも同じ無線ですからAtherosの製品があったとしても不思議ではないですね。<br>
<br>
さて、どうやらaubtfwlはath3k-1.fwをファームウェアとして必要としているらしく、そのopenに失敗しているようです。<br>
<br>
fail 2の2って何かといえば<a href="http://nxr.netbsd.org/xref/src/sys/sys/errno.h#43" title="NetBSD">ENOENT</a>ですからNo such file or directoryということのようです。確かにath3k-1.fwなんてファイルはシステムのどこにも存在しません。<br>
<br>
じゃぁ、ath3k-1.fwはどこにあるのさ、と思って探してみると<a href="http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git">http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git</a>にあるようです。ここにあるLICENCE.atheros_firmwareを見て、今回の用途においては問題がないと判断したので、ここのath3k-1.fwを使わせてもらうことにしました。<br>
<br>
では、どこにファームウェアを置けば良いのでしょう。<br>
ファームウェアを開いている <a href="http://nxr.netbsd.org/xref/src/sys/dev/firmload.c#firmware_open" title="NetBSD">firmware_open</a> -&gt; <a href="http://nxr.netbsd.org/xref/src/sys/dev/firmload.c#firmware_path_first" title="NetBSD">firmware_path_first</a> -&gt; <a href="http://nxr.netbsd.org/xref/src/sys/dev/firmload.c#firmware_paths" title="NetBSD">firmware_paths</a> -&gt; <a href="http://nxr.netbsd.org/xref/src/sys/dev/firmload.c#FIRMWARE_PATHS" title="NetBSD">FIRMWARE_PATHS</a> と追っかけていくと、<br>
<pre>
     75 #define	FIRMWARE_PATHS		\
     76 	"/libdata/firmware:/usr/libdata/firmware:/usr/pkg/libdata/firmware:/usr/pkg/libdata"
     77 #endif
</pre>
という記述にたどり着きました。どうやらsysctlのhw.firmware.pathで見ればわかったようですね。しらんがな。<br>
<br>
じゃぁ、/libdata/firmwareに置くことにしましょう。といって、どう置けば良いのでしょう。先のfirmware_path_firstから<a href="http://nxr.netbsd.org/xref/src/sys/dev/firmload.c#firmware_path_next" title="NetBSD">firmware_path_next</a>に読み進めると、drvnameつまりドライバ名をディレクトリとしてファームウェアファイルを読み込むわけです。<br>
<br>
今回だとdrvnameはaubtfwlですから/libdata/firmware/aubtfwl/ath3k-1.fwというファイルの置き方をすれば良いということになります。<br>
<br>
あれ?<br>
<br>
あいかわらず、<br>
<pre>
aubtfwl0: ath3k-1.fw open fail 2
</pre>
のようです。<br>
<br>
おっかしーな、と思ってもう一度<a href="http://nxr.netbsd.org/xref/src/sys/dev/usb/aubtfwl.c#104" title="NetBSD">aubtfwl.c</a>を見てみると、<br>
<pre>
    104 	error = firmware_open("ubt", "ath3k-1.fw", &amp;fwh); /* XXX revisit name */
</pre>
なんと、ubtって書いてあるじゃないですか!!! 直接書くなよ。<br>
<br>
あらためて、/libdata/firmware/ubt/ath3k-1.fwで起動してみると、<br>
<pre>
aubtfwl0 at uhub3 port 1
aubtfwl0: beginning firmware load
aubtfwl0: firmware load complete
aubtfwl0: detached
aubtfwl0: at uhub3 port 1 (addr 2) disconnected
aubtfwl0 at uhub3 port 1
aubtfwl0: beginning firmware load
aubtfwl0: firmware load complete
aubtfwl0: detached
aubtfwl0: at uhub3 port 1 (addr 2) disconnected
ubt0 at uhub3 port 1
ubt0: vendor 0x0cf3 product 0x3005, rev 1.10/0.01, addr 2
</pre>
何度かaubtfwlがattachとdetachを繰り返して、見事ubt0が生えてきたのでありました。<br>
<br>
やっとスタートラインに立てたようです。まずは、ここまで。<br>

</div>

<hr>
<h4><a href="/diary/0782#c">■コメント（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
<h4><a href="/diary/0782#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>KOZOSの書き込みに使うkz_h8writeをNetBSDで動作させる</title>
		<link>http://www.tokuda.net/diary/0781#tm1332067854</link>
		<guid>http://www.tokuda.net/diary/0781</guid>
		<category>未分類</category>
		<pubDate>Sun, 18 Mar 2012 10:50:54 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
昨日、OSC2012 Tokyo springにてkozosのブースで作者の坂井さんとお話させていただきました。<br>
<br>
リンカ・ローダ実践開発テクニックを2FのCQ出版社のブースで購入したので、サインをもらったりしました。例の魚の絵を描いてもらってうれしい。<br>
<br>
それはそれとして、例のOS自作本を読み進める中でつまづくのは7章、8章と1章なのだそうです。7章、8章は内容的な難しさで1章は物理的なトラブルに起因する難しさだそうです。<br>
<br>
つまり、シリアルをつかったボードとの通信ということですね。<br>
<br>
坂井さんも秋月のUSBシリアルを貸し出したり、あれこれ工夫されているということですが、いざ自身のUSBシリアルでうまくいかなかったりと、作者すら巻き込んだ状態で困ったチャンということのようです。坂井さんの場合だとボードがヘタっているのかも疑わなければならないそうですから大変です。<br>
<br>
このあたりのトラブルに巻き込まれて1章で挫折している人がたくさんいるのではないかとお話されていました。<br>
<br>
ということで、例に漏れず、シリアル経由でボードに書き込めないトラブルに遭遇していたので、すこしその辺を記録しておきます。<br>
<br>
まず、そもそもNetBSDで動かそうというところからして、想定環境とは違うのですが、まぁ、そこもふくめて楽しむのがホビーというものだろうと思いまして、あえてNetBSDで挑戦です。<br>
<br>
自作本ではh8writeを使っていますが、イマドキはWebページも合わせて読み進めるのが常識でして、その辺の情報を見るかぎり、h8writeがだめだったらkz_h8writeを試してみてねという話になっていて、実装の確かさからkz_h8writeでがんばろうとしたようです。<br>
<br>
したようです、と書いたのは理由があって、ずいぶん昔にはkz_h8writeでうまくいっていたのですが、長いブランクのあと試してみると、なぜかうまくいかないという事象にぶつかったからなのです。<br>
<br>
で、技術がなければ根性で、をモットーにfprintfデバッグをしていたところ、どうやらシリアルポートを開いているところで止まっているみたいだなということがわかったので、man openして、待ってるんだから待たなきゃいいじゃん、ということでO_NONBLOCKを加え、NetBSDでは意味ないよとかかれているO_NOCTTYを削ってみると、うまく書き込みができるようになりました。<br>
<pre>
--- serial_linux.c.orig	2012-01-02 06:06:36.000000000 +0000
+++ serial_linux.c	2012-03-18 09:21:24.000000000 +0000
@@ -89,7 +89,7 @@
      * ポートを開く.
      */
     strcpy(s-&gt;devfile, devfile);
-    s-&gt;fd = open(devfile, O_RDWR | O_NOCTTY);
+    s-&gt;fd = open(devfile, O_RDWR | O_NONBLOCK);
     if (s-&gt;fd &lt; 0) {
         free(s);
         return NULL;
</pre>
という修正をしたのがkz_h8write 0.0.3です。<br>
<br>
で、さっきWebをみるとgitリポジトリが公開されていることを発見しました。いまどきはgitなんですねぇ。<br>
<br>
最新の<a href="http://git.sourceforge.jp/view?p=kz-h8write/kz_h8write.git;a=blob;f=serial_linux.c">serial_linux.c</a>ソースを見るとopenの引数にO_RDWR, O_NOCTTY, O_NDELAYが与えられています。<br>
<br>
0.0.3には存在しなかったO_NDELAYがどうやら先ほどのO_NONBLOCKに相当するもののようですね。lxrで検索してちょろっと見るかぎり、x86ではO_NDELAYはO_NONBLOCKはまったく同じ定義、HP-UXでは別物として扱っていて、alphaはO_NONBLOCKしかなくて(なんでだろ)、sparcでも微妙に扱いを変えているみたいです。<br>
<br>
ちなみにPOSIX.1-2008の<a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html">open</a>をみるとO_NONBLOCKしか見当たらないので、ポータビリティの観点とx86の実装の観点からもO_NONBLOCKのほうが無難かなと思ったりする次第。<br>
<br>
NetBSDではO_NOCTTYは無視されてO_NONBLOCKが有効に動くので上のようなパッチもいらないですね。<br>

</div>

<hr>
<h4><a href="/diary/0781#c">■コメント（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
<h4><a href="/diary/0781#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>ZBOX nano VD01のHDDが遅い (4)</title>
		<link>http://www.tokuda.net/diary/0780#tm1331384979</link>
		<guid>http://www.tokuda.net/diary/0780</guid>
		<category>NetBSD</category>
		<pubDate>Sat, 10 Mar 2012 13:09:39 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
さらにtsutsuiさんからdmesgのwd0が表示する内容でUDMAに関する表示が出ているはずなので確認してみてはどうか、というアドバイスを頂いたので早速確認。<br>
<br>
まずは、UDMA 0 (sc-&gt;sc_wdcdev.sc_atac.atac_udma_cap = 0) です。<br>
<pre>
wd0 at atabus0 drive 0
wd0: &lt;WDC WD1600BEVT-24A23T0&gt;
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 149 GB, 310101 cyl, 16 head, 63 sec, 512 bytes/sect x 312581808 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(viaide0:0:0): using PIO mode 4, DMA mode 2 (using DMA)
</pre>
次はUDMA 6 (sc-&gt;sc_wdcdev.sc_atac.atac_udma_cap = 6) の場合です。<br>
<pre>
wd0 at atabus0 drive 0
wd0: &lt;WDC WD1600BEVT-24A23T0&gt;
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 149 GB, 310101 cyl, 16 head, 63 sec, 512 bytes/sect x 312581808 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
</pre>
ほとんど同じですが、最後の行が違いますね。比べてみましょう。<br>
<table>
<tbody>
	<tr><th>UDMA</th><th>メッセージ</th></tr>
	<tr><td>0</td><td>wd0(viaide0:0:0): using PIO mode 4, DMA mode 2 (using DMA)</td></tr>
	<tr><td>6</td><td>wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)</td></tr>
</tbody></table>
なるほど。たしかに、変わっていますね。<br>
<br>
これで<a href="http://nxr.netbsd.org/xref/src//sys/dev/pci/viaide.c#604" title="NetBSD">/sys/dev/pci/viaide.c#604</a><br>
<pre>
    602 	sc-&gt;sc_wdcdev.sc_atac.atac_pio_cap = 4;
    603 	sc-&gt;sc_wdcdev.sc_atac.atac_dma_cap = 2;
    604 	sc-&gt;sc_wdcdev.sc_atac.atac_set_modes = via_setup_channel;
    605 	sc-&gt;sc_wdcdev.sc_atac.atac_channels = sc-&gt;wdc_chanarray;
    606 	sc-&gt;sc_wdcdev.sc_atac.atac_nchannels = PCIIDE_NUM_CHANNELS;
</pre>
から<a href="http://nxr.netbsd.org/xref/src//sys/dev/pci/viaide.c#via_setup_channel" title="NetBSD">/sys/dev/pci/viaide.c#via_setup_channel</a>が呼ばれ、759行目でUDMA 6としての設定をレジスタにセットしているようですね。<br>
<pre>
    753 			case PCI_VENDOR_VIATECH:
    754 				if (sc-&gt;sc_wdcdev.sc_atac.atac_udma_cap == 6) {
    755 					/* 8233a */
    756 					udmatim_reg |= APO_UDMA_TIME(
    757 					    chp-&gt;ch_channel,
    758 					    drive,
    759 					    via_udma133_tim[drvp-&gt;UDMA_mode]);
    760 				} else if (sc-&gt;sc_wdcdev.sc_atac.atac_udma_cap == 5) {
</pre>
via_udma133_timって何かと見てみると<a href="http://nxr.netbsd.org/xref/src//sys/dev/pci/pciide_apollo_reg.h#149" title="NetBSD">/sys/dev/pci/pciide_apollo_reg.h#149</a>に次のように書かれています。<br>
<pre>
    149 static const int8_t via_udma133_tim[] __unused =
    150     {0x07, 0x07, 0x06, 0x04, 0x02, 0x01, 0x00};
</pre>
先のdmesgのとおりdrvp-&gt;UDMA_modeは6ですから、えーと、0x00が設定されるってことですね。<br>
<br>
うーん、この辺までくると、さっぱり中身がわからなくなってきしたが、何となくUDMAが6での転送に失敗したらUDMA 5に落とされて0x01が使われて... といったfall backに使われるんでしょうかねぇ。<br>
<br>
ということで、ドライバとしてもUDMAのモードを意識した実装だということがわかった (ような気がする) ので、すっきりしました。<br>
<br>
話は変わりますが、<a href="http://nxr.netbsd.org">http://nxr.netbsd.org</a>ってほんと便利ですよね。<br>

</div>

<hr>
<h4><a href="/diary/0780#c">■コメント（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
<h4><a href="/diary/0780#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>ZBOX nano VD01のHDDが遅い (3)</title>
		<link>http://www.tokuda.net/diary/0779#tm1331363776</link>
		<guid>http://www.tokuda.net/diary/0779</guid>
		<category>NetBSD</category>
		<pubDate>Sat, 10 Mar 2012 06:00:07 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
前回の日記を書いて、さらにtsutsuiさんからコメントを頂きました。<br>
<br>
どうやら、昔のVIAチップの設計がイマイチで、それを回避するコードが入っていたそうです。<br>
<br>
最近のVIAチップはそういう回避コードは不要になっているにもかかわらず、回避コードの下に慣習的に各々のVIA IDE個別の設定が追加されていったようです。<br>
<br>
今回のケースではその回避コードが逆に悪さをしてうまく動いていないということですね。むしろ、最近のチップがちゃんと動いているのか心配になってしまいます。<br>
<br>
じゃぁ、回避コードのルートに乗っかる前に、さっさと処理をしてしまえばよいということで、次のような修正を加えることにしました。<br>
<pre>
--- ./sys/dev/pci/viaide.c.orig 2011-12-29 05:25:40.000000000 +0000
+++ ./sys/dev/pci/viaide.c      2012-03-10 12:43:07.00000000
@@ -464,6 +469,11 @@
                        interface = PCIIDE_INTERFACE_BUS_MASTER_DMA |
                            PCIIDE_INTERFACE_PCI(0) | PCIIDE_INTERFACE_PCI(1);
                        break;
+               case PCI_PRODUCT_VIATECH_VX900_IDE:
+                       aprint_normal_dev(sc-&gt;sc_wdcdev.sc_atac.atac_dev,
+                           "VIA Technologies VX900 ATA133 controller\n");
+                       sc-&gt;sc_wdcdev.sc_atac.atac_udma_cap = 6;
+                       break;
                default:
                        /*
                         * get a PCI tag for the ISA bridge.
</pre>
起動すると期待どおりのメッセージが表示されました。<br>
<pre>
viaide0 at pci0 dev 15 function 0
viaide0: VIA Technologies VX900 ATA133 controller
viaide0: bus-master DMA support present
viaide0: primary channel configured to native-PCI mode
viaide0: using ioapic0 pin 21 for native-PCI interrupt
atabus0 at viaide0 channel 0
viaide0: secondary channel configured to native-PCI mode
atabus1 at viaide0 channel 1
</pre>
やりましたね!<br>
<br>
それでは、dbenchしてみましょう!<br>
<pre>
Throughput 60.1017 MB/sec 5 procs
</pre>
あれ?! おかしいな。もう一回。<br>
<pre>
Throughput 62.8053 MB/sec 5 procs
</pre>
おっ! 先ほどよりは良くなりましたね。って言っても前回の不完全パッチでも<br>
<pre>
Throughput 63.8846 MB/sec 5 procs
</pre>
ということで、数値的にはほとんど変わらないという結果になりました。<br>
<br>
dbehcnの数字が60MB/s程度だとして、これが何を意味するのかは他の結果と比較してみなければなりませんが、とても乱暴にUDMA 4 (66MB/s) 相当の速度と仮置きしておくことにしましょう。<br>
<br>
せっかくUDMAを0から6にしたのに効果は得られていないようです。おかしいですね。<br>
<br>
仮説としては三つくらいでしょうか。<br>
<ul>
	<li>不完全パッチでもUDMA 0ではなくUDMA 4相当が使われていた</li>
	<li>今回の修正でもまだ不十分でUDMA 4相当で動いている</li>
	<li>実はちゃんと動いているけどdbenchがかけるワークロードではUDMAの差が数字として現れない</li>
</ul>
仮説の最初の二つを考える上で気になっているのは、VX900のSATAコントローラを使っているにもかかわらず、viaideドライバ上ではPATAとして処理されているっぽいというところです。OpenBSDでもPATAとして扱われているので、そういうもの、なのかもしれませんが気になってしまいます。<br>
<br>
SATAコントローラがPATAコンパチモードで動くとUDMAの指定はともかく、そこそこの速度で動いてくれるという動作なのかもしれません。<br>
<br>
じゃぁ、SATAで動かせばいいじゃないかという話になるのですが、実は試行錯誤をしていた段階で<br>
<pre>
        { PCI_PRODUCT_VIATECH_VX900_IDE,
          0,
          NULL,
          via_chip_map,
        },
</pre>
のところを<br>
<pre>
          via_sata_chip_map_7,
</pre>
にして動かしてみたのですが、起動時にpanicしてそれ以降深く追っかけていなかったのです。せっかくのSATAコントローラなのですからSATAで動かしたいものですね。<br>
<br>
三つ目の仮説であるdbenchどうなの、という話は確かにあって、ベンチマークプログラムの選択はなかなか奥が深いですね。<br>
<br>
このようなディスクの話であればiozoneが良いのではないかとお勧めされたりしているのですが、iozoneのオプションを見て、そっと閉じる、という情けない状態だったりします。<br>
<br>
いくつか宿題は残っていますが、一定の結論がでたのでsend-prに向けて準備を進めたいと思います。<br>

</div>

<hr>
<h4><a href="/diary/0779#c">■コメント（1件）</a></h4>
<div style="margin-left: 1em;">
tsutsui『dmesgのドライブ側の行で wd0: drive supports PIO mode 4, DMA mode 2, Ultra...』(2012/03/10 15:53)</span><br>
</div>
<h4><a href="/diary/0779#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>ZBOX nano VD01のHDDが遅い (2)</title>
		<link>http://www.tokuda.net/diary/0778#tm1331115845</link>
		<guid>http://www.tokuda.net/diary/0778</guid>
		<category>NetBSD</category>
		<pubDate>Tue, 06 Mar 2012 17:27:42 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
tsutsuiさんから「UDMA が使われているかどうかが気になる」とのコメントとパッチいただきました。<br>
<br>
たしかに前回の<br>
<pre>
viaide0 at pci0 dev 15 function 0: VIA Technologies VX900 SATA Controller (rev. 0x00)
viaide0: VIA Technologies unknown VIA ATA controller
viaide0: bus-master DMA support present
viaide0: primary channel configured to native-PCI mode
viaide0: using ioapic0 pin 21 for native-PCI interrupt
</pre>
というメッセージをよく見てみるとunknown VIA ATA controllerという表示になっています。<br>
<br>
unknownというメッセージを表示しているのは<a href="http://nxr.netbsd.org/xref/src/sys/dev/pci/viaide.c#via_chip_map" title="NetBSD">sys/dev/pci/viaide.c#via_chip_map</a>の<br>
<pre>
    540 			default:
    541 		unknown:
    542 				aprint_normal("unknown VIA ATA controller\n");
    543 				sc-&gt;sc_wdcdev.sc_atac.atac_udma_cap = 0;
    544 			}
    545 			break;
    546 
</pre>
という部分です。なるほど、自分でVX900とわかっているわりにはunknownというのはおかしな話です。それもそのはず、tsutsuiさんのパッチではそれをフォローすべく、<br>
<pre>
@@ -533,6 +538,10 @@ via_chip_map(struct pciide_softc *sc, co
 				aprint_normal("CX700 ATA133 controller\n");
 				sc-&gt;sc_wdcdev.sc_atac.atac_udma_cap = 6;
 				break;
+			case PCI_PRODUCT_VIATECH_VX900_IDE:
+				aprint_normal("VX900 ATA133 controller\n");
+				sc-&gt;sc_wdcdev.sc_atac.atac_udma_cap = 6;
+				break;
 			case PCI_PRODUCT_VIATECH_VT8251:
 				aprint_normal("VT8251 ATA133 controller\n");
 				sc-&gt;sc_wdcdev.sc_atac.atac_udma_cap = 6;
</pre>
といった具合にVX900であればUDMAを使う、つまりsc-&gt;sc_wdcdev.sc_atac.atac_udma_cap = 0ではなくsc-&gt;sc_wdcdev.sc_atac.atac_udma_cap = 6という処理をしています。<br>
<table>
<tbody>
	<tr><td colspan="2"></td></tr>
</tbody></table>
なるほど。VX900のエントリを追加して動いたと思い込んでいた、ということで、さっそくパッチをあてて動かしてみることにしました。<br>
<br>
ところが、認識時のメッセージではあいかわらずunknown VIA ATAといわれてしまいます。<br>
<br>
あれれ？　と思ってソースを見たところ、unknownが表示されるケースは、<br>
<pre>
    540 			default:
    541 		unknown:
    542 				aprint_normal("unknown VIA ATA controller\n");
    543 				sc-&gt;sc_wdcdev.sc_atac.atac_udma_cap = 0;
    544 			}
    545 			break;
</pre>
ですから、ラベルがdefaultもしくはunknownということになります。<br>
<br>
もし、ラベルがunknownだった場合には、<br>
<pre>
    471 			if (pci_find_device(&amp;pcib_pa, via_pcib_match) == 0)
    472 				goto unknown;
    473 			pcib_id = pcib_pa.pa_id;
    474 			pcib_class = pcib_pa.pa_class;
    475 			aprint_normal_dev(sc-&gt;sc_wdcdev.sc_atac.atac_dev,
    476 			    "VIA Technologies ");
</pre>
から飛んでくるので、475行目のVIA Technologiesという文字列は表示されないことになります。ところが、起動時にはVIA Technologiesという表示がされていることから、unknownのラベルからgotoで飛んできているわけではなく、475行目を経由したdefaultの処理としてunknownが表示されていると推測されます。<br>
<br>
であれば、switch文の評価でdefaultになっていると判断できるので (caseほげで必ずbreakしているので)、switchの<br>
<pre>
    477 			switch (PCI_PRODUCT(pcib_id)) {
</pre>
でVX900にマッチしていないということになります。<br>
<br>
意味がどうこう考える前に、PCI_PRODUCT(pcib_id)がどういう値なのか、それを表示させるべく、<br>
<pre>
    aprint_normal_dev(sc-&gt;sc_wdcdev.sc_atac.atac_dev,
        "VIA Technologies %d, %d", PCI_PRODUCT(pa-&gt;pa_id), PCI_PRODUCT(pcib_id));
</pre>
というデバッグ表示をさせることにしました。今思うと、なんで%dなんかにしたのかと思いますが、<br>
<pre>
viaide0: VIA Technologies 36865, 33808VX900 ATA133 controller
</pre>
という表示になりました。<br>
<br>
36865は0x9001でVX900のSATAコントローラのIDで、想定どおりです。一方33808は0x8410でPCI_PRODUCT(pcib_id)の値がそれであることがわかりました。<br>
<br>
ということでPCI_PRODUCT(pcib_id)が0x8410だからVX900として定義していた0x9001と違うことから結果としてdefaultの処理に飛んでいることがわかり、想定どおり動いていないという理由のつじつまがあいました。<br>
<br>
動かない理由を探るべく0x8410という数字が何を意味しているのかを調べるためにVX900のSystem Programming Manualを確認してみたところ、Bus Control And Power ManagementのデバイスIDのようだということがわかりました。<br>
<br>
うーん、なんだか変ですねぇ。<br>
<br>
ちょっと長くなってきたので、まずはここまで。<br>

</div>

<hr>
<h4><a href="/diary/0778#c">■コメント（1件）</a></h4>
<div style="margin-left: 1em;">
tsutusi『PCI-ISA bridgeのIDを見なければいけない理由がなんかあったような気がする、 と遠い昔の記憶を掘り起こすためにcvs...』(2012/03/07 19:24)</span><br>
</div>
<h4><a href="/diary/0778#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>ZBOX nano VD01でX.orgがopenchromeドライバで動いたよ</title>
		<link>http://www.tokuda.net/diary/0777#tm1329028852</link>
		<guid>http://www.tokuda.net/diary/0777</guid>
		<category>NetBSD</category>
		<pubDate>Sun, 12 Feb 2012 06:40:52 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
ここまで、起動させる、正しいディスクドライバを使う、までたどり着きました。<br>
<br>
さて、そろそろX.orgを動かしてみたいところです。<br>
<br>
Xorg -configureを実行してxorg.confのひな形をつくってXorg -config xorg.conf.newってな感じで動かしていくことになるわけですが、まずvesaドライバだと動くには動くのですが解像度が低くて常用するには残念な感じです。<br>
<br>
せっかくのVX900チップセットに統合されたChrome9 HCMが泣いているぜ、ということで、さてどうするかなと思ったところで大した選択肢はなく、<a href="http://www.openchrome.org/">openChromeプロジェクト</a>で作られているopenchromeドライバを使うことで良さそうです。<br>
<br>
おもむろにDeviceセクションにある<br>
<pre>
        Driver "vesa"
</pre>
を<br>
<pre>
        Driver "openchrome"
</pre>
に変更して、神に祈ってからstartxです。結果は「そんなデバイスはない」といわれてしまいます。<br>
<br>
いやいや、openChromeプロジェクトでは動くって書いてあるし、デバイスがないとは失礼な。なんかの間違いじゃないですかね。<br>
<br>
うーんと思って、/usr/X11R7/lib/modules/drivers/openchrome_drv.so.0をstringsしてみるとどうやらVXシリーズは800番台までしか対応してくれていないみたいです。<br>
<br>
はー、なるほど。これは例によってVX900の定義を書いて、ちょこちょこっとパッチを当てれば動くんでしょ。きっとそうでしょ。<br>
<br>
そんな淡い期待は<a href="http://cgit.freedesktop.org/openchrome/xf86-video-openchrome/tree/src">openChromeの最新ソース</a>を見て打ち砕かれたのでした。<br>
<br>
結構差分があるのです。ここで、標準配布のxsrcではなくてpkgsrcのmodularなX.orgを使うことも考えたのですが、どうせなら最新を動かしたいなぁと。<br>
<br>
xsrcに最新openChromeソースのVX900対応部分を取り出してパッチする方法よりもごっそりと*.c, *.hを入れ替えたほうが早そうです。<br>
<br>
build.sh -x -X ../xsrc buildって感じで動かしてみると予想どおり止まります。エラーは、<br>
<ol>
	<li>そんなヘッダファイルないよ</li>
	<li>宣言されてないよ</li>
</ol>
の二種類だったのでxsrcのソースを参照したり、宣言部分を泥縄で追記していくことでコンパイルができるようになりました。<br>
<br>
こまったのはbuild.shを毎回走らせていると遅くて仕方がないということです。どこかでMakefileが実行されているに違いないのですが、build.shのオートメーション化にすっかり堕落してしまい、xsrcにもないしsrc/objにもないし、とうろうろと探しまわってしまいました。<br>
<br>
答えはsrc/external/mit/xorg/server/drivers/xf86-video-openchromeでした。ここでmakeを実行すればobjディレクトリにお目当てのものが生成されます。<br>
<br>
一つ注意しなければならないのは、生成されたドライバモジュールの名前です。libopenchrome_drv.so.0という名前で生成されたドライバはopenchrome_drv.so.oとして/usr/X11R7/modules/driversにコピーされている必要があります。最初は名前が違うことに気づかず、同名でコピーして、事象が変わらず悩んでしまいました。<br>
<br>
いざ、新しいドライバでstartxするとパチッと画面が暗転し...<br>
<br>
暗転したままです。<br>
<br>
リモートからマシンの状態を覗いてみるとXorgは動いていてpkill Xorgとかすると起動しているつもりで表示できていないxterm３匹を終了した旨のメッセージが出ます。<br>
<br>
設定に不備があるのかと思い、Modelineを足してみたりしましたが、事態は進展しません。Option "PanelSize" "1280x1024"してみたりしても変わりません。<br>
<br>
ふとディスプレイ装置からは信号がきてません的なメッセージが出ています。ZBOX nano VD01にはDisplayPortとHDMIが出ています。もしかしたら変なところに向かって表示をしているのかもしれません。<br>
<br>
Option "ActiveDevice"というのがあってCRT, LCD, DFP, TVという値が設定できます。もしかしたら、これかなと思って順番に試すことにしました。<br>
<br>
CRTだと事象に変化なし、LCDだとなにやらシマシマの模様が表示されます。信号すらきていなかった状況からすると一歩進展。DFP, TVと試してみるとシマシマ模様が表示されます。うーん、とおもって最初に試したCRTを設定してみると、あれ？　シマシマ模様です。もう何が何やら。<br>
<br>
もうこれは一つ一つオプションを試すしかないのかと思い、manやWebなどを参考に<br>
<pre>
        Option "VBEModes" "true"
</pre>
を足して起動したところ、びしっと1280x1024でxtermが3枚表示されました!<br>
<br>
記念にxorg.confを張っておきます。あと、openChromeの最新ソースをxsrcでコンパイルするための稚拙なパッチも張っておこう。<br>
<pre>
Section "ServerLayout"
        Identifier     "ZOTAC ZBOX nano VD01"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
        ModulePath   "/usr/X11R7/lib/modules"
        FontPath     "/usr/X11R7/lib/X11/fonts/misc/"
        FontPath     "/usr/X11R7/lib/X11/fonts/TTF/"
        FontPath     "/usr/X11R7/lib/X11/fonts/Type1/"
        FontPath     "/usr/X11R7/lib/X11/fonts/75dpi/"
        FontPath     "/usr/X11R7/lib/X11/fonts/100dpi/"
EndSection

Section "Module"
        Load  "dbe"
        Load  "dri"
        Load  "dri2"
        Load  "extmod"
        Load  "glx"
        Load  "record"
        Load  "shadow"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "wsmouse"
        Option      "Device" "/dev/wsmouse"
        Option      "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "IO DATA"
        ModelName    "Monitor Model"
EndSection

Section "Device"
        Identifier  "VX900"
        Driver      "openchrome"
        Option "VBEModes" "true"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "VX900"
        Monitor    "Monitor0"
EndSection
</pre>
<pre>
diff -ur src.openchrome-orig/via_dga.c src/via_dga.c
--- src.openchrome-orig/via_dga.c       2012-02-12 13:23:10.000000000 +0000
+++ src/via_dga.c       2012-02-10 01:43:42.000000000 +0000
@@ -30,6 +30,8 @@
 #include "via_driver.h"
 #include "dgaproc.h"
 
+extern void viaShowCursor(ScrnInfoPtr pScrn);
+extern void viaHideCursor(ScrnInfoPtr pScrn);
 
 static Bool VIADGAOpenFramebuffer(ScrnInfoPtr, char **, unsigned char **,
                                   int *, int *, int *);
diff -ur src.openchrome-orig/via_driver.c src/via_driver.c
--- src.openchrome-orig/via_driver.c    2012-02-12 13:23:10.000000000 +0000
+++ src/via_driver.c    2012-02-10 06:50:44.000000000 +0000
@@ -39,7 +39,7 @@
 #include &lt;X11/extensions/dpms.h&gt;
 #endif
 
-#include "version.h"
+#include "svnversion.h"
 
 #include "via_driver.h"
 #include "via_video.h"
@@ -58,6 +58,9 @@
 /* RandR support */
 #include "xf86RandR12.h"
 
+extern Bool viaHWCursorInit(ScreenPtr pScreen);
+extern void viaHideCursor(ScrnInfoPtr pScrn);
+
 /* Prototypes. */
 static void VIAIdentify(int flags);
 
diff -ur src.openchrome-orig/via_mode.c src/via_mode.c
--- src.openchrome-orig/via_mode.c      2012-02-12 13:23:10.000000000 +0000
+++ src/via_mode.c      2012-02-11 17:50:00.000000000 +0000
@@ -41,6 +41,11 @@
 #include "via_id.h"
 #include &lt;unistd.h&gt;
 
+extern void ViaDisplaySetStreamOnCRT(ScrnInfoPtr pScrn, Bool primary);
+extern void ViaDisplaySetStreamOnDFP(ScrnInfoPtr pScrn, Bool primary);
+extern void ViaDisplaySetStreamOnDVO(ScrnInfoPtr pScrn, int port, Bool primary);
+extern void ViaDisplayEnableDVO(ScrnInfoPtr pScrn, int port);
+
 /*
  * Modetable nonsense.
  *
diff -ur src.openchrome-orig/via_video.c src/via_video.c
--- src.openchrome-orig/via_video.c     2012-02-12 13:23:10.000000000 +0000
+++ src/via_video.c     2012-02-11 17:57:58.000000000 +0000
@@ -51,6 +51,7 @@
 #include &lt;X11/extensions/Xv.h&gt;
 #include "xaa.h"
 #include "xaalocal.h"
+#include "damage.h"
 #include "dixstruct.h"
 #include "via_xvpriv.h"
 #include "via_swov.h"
</pre>

</div>

<hr>
<h4><a href="/diary/0777#c">■コメント（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
<h4><a href="/diary/0777#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
	<item>
		<title>ZBOX nano VD01のHDDが遅い</title>
		<link>http://www.tokuda.net/diary/0776#tm1329320215</link>
		<guid>http://www.tokuda.net/diary/0776</guid>
		<category>NetBSD</category>
		<pubDate>Wed, 08 Feb 2012 16:38:09 GMT</pubDate>
		<author>tokuda</author>
		<description><![CDATA[<div>
めでたく起動したZBOXですが、使っていてどうもディスクが遅い気がしてなりません。<br>
<br>
で、ひとつ覚えのdbenchを走らせてみたところ、<br>
<br>
Throughput 13.9741 MB/sec 5 procs<br>
<br>
という結果。なんだこれ、KVM上のNetBSDより遅いじゃないか！<br>
<br>
よく見ると、ディスクのドライバがpciideというgenericなドライバが使われていて、しかもPIOで動いているっぽいメッセージ。<br>
<br>
一方で、本来使われるべきviaideドライバは認識されていないということで、viaideのソースを見たところ、どうやらチップセットを登録してあげないといけないようです。<br>
<br>
ということで、以下のような修正を加えました。<br>
<pre>
--- sys/dev/pci/viaide.c.orig	2012-02-07 01:08:45.000000000 +0000
+++ sys/dev/pci/viaide.c	2012-02-07 08:01:25.000000000 +0000
@@ -345,6 +345,11 @@
 	  "VIA Technologies VT8237S SATA Controller",
 	  via_sata_chip_map_7,
 	},
+	{ PCI_PRODUCT_VIATECH_VX900_SATA,
+	  0,
+	  "VIA Technologies VX900 SATA Controller",
+	  via_chip_map,
+	},
 	{ 0,
 	  0,
 	  NULL,
--- sys/dev/pci/pcidevs.orig	2011-10-19 00:21:35.000000000 +0000
+++ sys/dev/pci/pcidevs	2012-02-07 01:08:04.000000000 +0000
@@ -4676,6 +4677,7 @@
 product VIATECH VT82C597AGP	0x8597	VT82C597 (Apollo VP3) CPU-AGP Bridge
 product VIATECH VT82C598AGP	0x8598	VT82C598 (Apollo MVP3) CPU-AGP Bridge
 product VIATECH VT8605AGP	0x8605	VT8605 (Apollo ProMedia 133) Host-AGP Bridge
+product VIATECH VX900_SATA	0x9001	VX900 SATA Controller
 product VIATECH K8T890_PPB_A238	0xa238	K8T890 PCI-PCI Bridge
 product VIATECH VT8633AGP	0xb091	VT8633 (Apollo Pro 266) CPU-AGP Bridge
 product VIATECH VT8366AGP	0xb099	VT8366 (Apollo KT266) CPU-AGP Bridge
</pre>
すると、<br>
<pre>
viaide0 at pci0 dev 15 function 0: VIA Technologies VX900 SATA Controller (rev. 0x00)
viaide0: VIA Technologies unknown VIA ATA controller
viaide0: bus-master DMA support present
viaide0: primary channel configured to native-PCI mode
viaide0: using ioapic0 pin 21 for native-PCI interrupt
</pre>
てな感じで認識され、dbenchも<br>
<br>
Throughput 63.8846 MB/sec 5 procs<br>
<br>
ということで4.5倍程度高速になりました！<br>

</div>

<hr>
<h4><a href="/diary/0776#c">■コメント（1件）</a></h4>
<div style="margin-left: 1em;">
tsutsui『wd0 の attach message で UDMA が使われているかどうかが気になるんですが、 http://www.cer...』(2012/02/15 24:36)</span><br>
</div>
<h4><a href="/diary/0776#tb">■トラックバック（0件）</a></h4>
<div style="margin-left: 1em;">
</div>
]]></description>
	</item>
</channel>
</rss>

