基本的に落書き帳／メモ帳／備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。
sudo kldconfig -i "/boot/kernel.add;/boot/SMP;/boot/modules" sudo kldload if_wpi sudo kldload wpi_ucode sudo ifconfig wpi0 ssid hogehoge sudo ifconfig wpi0 weptxkey 1 wepkey 1:mogemoge sudo ifconfig wpi0 wepkey mogemoge sudo ifconfig wpi0 wepmode on sudo ifconfig wpi0 192.168.1.2 sudo route add default 192.168.1.1 netstat -rn ifconfig -a ping -c 1 192.168.192.1 arp -anで、ネットワークが通った。 ただし、有線側を止めるか別ネットワークにするかしないと、
kernel: arp: 192.168.1.1 is on rl0 but got reply from xx:xx:xx:xx:xx:xx on wpi0とか出て、ネットワークスタックが迷子になりかねないので注意。 それから、
sudo ifconfig wpi0 downした場合、一旦
sudo kldunload wpi_ucode sudo kldunload firmware sudo kldunload if_wpiしてから、もう一度 kldload から繰り返さないと、
wpi0: could not load firmware image 'wpi_ucode'とか出て、wpi0 が動かなくなる。 でも、やっぱり有線と比べると遅い。 と、思ったら、
rx tail flags error 702が、ちょくちょく出ている。 回線品質が悪くて、CRC エラーでパケット破棄、らしい。 基地局まで 3〜5m なんだが……。 ほそかわ氏の分解記事の写真を見る限り、 左右端にダイバーシティしているみたいだから、 アンテナ配置が悪いとは思えんのだが……。 Sat,05 May,2007、 Sun,20 May,2007、 Thu,09 Aug,2007に続く。
ここは da0 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 000001c0 2f 00 06 07 c7 dc eb 00 00 00 15 33 0f 00 00 00 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * ここから da0s1 0001d600 eb 00 90 20 20 20 20 20 20 20 20 00 02 20 01 00 0001d610 02 00 02 00 00 f8 7a 00 3f 00 10 00 eb 00 00 00 0001d620 15 33 0f 00 80 00 29 a9 3d 30 fc 4e 4f 20 4e 41 |.3....)ｩ=0.NO NA| 0001d630 4d 45 20 20 20 20 46 41 54 31 36 20 20 20 00 00 |ME FAT16 ..| 0001d640 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0001d7f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0001d800 f8 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 0001d810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0002cc00 f8 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 0002cc10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00040000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00040010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00040020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 00040030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 00040040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 00040050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 00040060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 00040070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 00040080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 00040090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f 000400a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af 000400b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf 000400c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf 000400d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df 000400e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef 000400f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe 00 00040100 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00040110 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 中略(0x1b9c00) 001477f0 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 00147800 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * (0xb2400) 001f9c00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 中略(0x216c00) 002017f0 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 00201800 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * (0x20f000) 00410800 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 中略(0x64c00) 004183f0 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 00418400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * (0x5d000) 00475400 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 中略(0x17bc00) 0047cff0 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 0047d000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * (0x174000) 005f1000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 以下ループ 1e6427f0 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 1e642800 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 1e680000512MB って言っても、 512*1024*1024B ではないのね。 510132224B らしい。 SmartMedia みたいなフラッシュの領域管理は、 中のコントローラでやっているみたいだから （未確認、 でも NAND Flash でやっていないとは考えにくい ……コンパクトフラッシュの安い奴は、やっていないんだっけ……）、 フラッシュ自体の管理領域や、 ローテーション用の領域や、 死亡時の代替領域など、 その辺も全部含めて 512MB なのかな？。 テストパターンに FF は無いらしい、フラッシュだから？。 周期も大きさもまちまちな 00 は何だろう？。 FAT16 のデータ構造、忘れたなぁ。 FC30-3DA9 がボリュームシリアルで、 NO NAME がボリュームラベルで。 転送速度が遅いと思ったら、1MB/sec しか出ていなかった。 試しに MS-Windows XP でベンチマークを取ったら、8〜9MB/sec 出た。 虎千の速度表記無しの SD 自体のスペックは 60倍速らしい。 FreeBSD の umass が遅いらしい。 Mon,21 May,2007 追記： powerd を有効にしたままだった事に気付き、 powerd を無効にして測定してみたら、 1.4MB/sec まで速くなった。 でもまだ遅い。
根(CA)の鍵と証明書を作成 % openssl req -new -x509 -keyout cakey.pem -out cacert.pem -days 365 根(CA)の証明書をブラウザやメーラで読み込む形式に変換 % openssl x509 -in cacert.pem -outform DER -out cacert.der 枝の証明書の鍵を設定 % openssl genrsa -aes256 -out server.key 1024 枝の証明書を使用するソフトが自動起動出来る様にパスワード認証を解除 % openssl rsa -in server.key -out server.nopass.key 枝の証明書を作成 % openssl req -new -key server.key -out mail.csr.pem -days 365 枝の証明書に根(CA)で署名 % openssl x509 -CA cacert.pem -CAkey cakey.pem -req -in mail.csr.pem -out mail.cert.pem -CAcreateserial -days 365 ブラウザやメーラで読み込む形式に変換 % openssl x509 -in mail.cert.pem -outform DER -out mail.cert.der courier用の証明書ファイルを作成 % cat server.nopass.key mail.cert.pem > courier.pem 証明書(cert)の内容は % openssl x509 -in cacert.pem -text % openssl x509 -in mail.cert.pem -text で確認できる。 クライアントの証明書を作成 % openssl genrsa -aes256 -out client.hoge.key 1024 % openssl req -new -key client.hoge.key -out client.hoge.csr.pem -days 365 クライアントの証明書に根(CA)で署名 % openssl x509 -CA cacert.pem -CAkey cakey.pem -req -in client.hoge.csr.pem -out client.hoge.cert.pem -CAcreateserial -days 365 クライアントの証明書をアーカイブにする % cat client.hoge.key client.hoge.cert.pem cacert.pem | openssl pkcs12 -export -out client.hoge.p12 -name "Client Key for hoge" クライアント（一般ユーザ）の証明書のサブジェクトを確認するには % openssl x509 -noout -subject -in client.hoge.cert.pem とする。apache1 で クライアント証明書による認証を有効にする場合、 httpd.conf か ssl.conf あたりに
SSLCACertificateFile /etc/httpd/conf/ca.cert.pem SSLCARevocationFile /etc/httpd/conf/client.hoge.cert.pem SSLVerifyClient optional SSLOptions +FakeBasicAuthを追加し、 該当の .htpasswd に証明書のサブジェクトとダミーのパスワード
/C=JP/ST=Tokyo/L=Chiyoda/O=Tokyo St., Marunouchi/OU=JR/CN=hoge/emailAddress=moge@poge.example:xxj31ZMTZzkVAを追加する。
$CC $CFLAGS -L/usr/local/lib memleak_cpp.cc -o memleak_cpp.ccmalloc -lccmalloc $CXX $CXXFLAGS -L/usr/local/lib /usr/local/lib/ccmalloc-c++.o memleak_cpp.cc -o memleak_cpp.ccmalloc -lccmalloc-lccmalloc を最後に付ける。 C++ の場合は、ccmalloc-c++.o もリンクする。 どちらかでも忘れると機能しない。
% ld -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib -L/usr/lib memleak_cpp.o -lmpatrol -lstdc++ -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o-pthread を付けた時の g++ のリンク処理
% ld -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib -L/usr/lib memleak_cpp.o -lmpatrol -lstdc++ -lm -lgcc -lpthread -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.oリンク処理の場合は -lpthread が付くだけらしい。 mpatrol の doc によれば、-lpthread を可能な限りあとの方にしろ、 と書いてある。
% $CXX $CXXFLAGS -L/usr/local/lib memleak_cpp.o -L/usr/local/lib -lmpatrol -Wl,-lc,/usr/lib/libpthread.aで
% ld -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib -L/usr/lib memleak_cpp.o -lmpatrol -lc /usr/lib/libpthread.a -lstdc++ -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.oになって、いけた。 ccmalloc なら、
% $CXX $CXXFLAGS /usr/local/lib/ccmalloc-c++.o memleak_cpp.o -L/usr/local/lib -lccmalloc -Wl,-lc,/usr/lib/libpthread.aになる。 但し、 $CXXFLAGS に -pthread が入っていると、
% ld -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib -L/usr/lib memleak_cpp.o -lmpatrol -lc /usr/lib/libpthread.a -lstdc++ -lm -lgcc -lpthread -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.oになってしまって、-lpthread が -lc よりも前になってしまうので駄目だった。
% $CXX -g3 -O0 memleak_cpp.o -L/usr/local/lib -lmpatrol -Wl,/usr/lib/libc.a -pthreadでも、いけた。 ccmalloc では、こちらのパターンをやると
*** wrapper can not open `/lib/libc.so.6'! *** dlerror() reports: Service unavailableでこけた。 但しこれは見てわかる通り、libc.a が静的リンクされてしまうので、 出来上がるバイナリが大きくなる副作用と、 pthread でのメモリリークまでいちいち報告される副作用がある。
% $CXX -g3 -O0 memleak_cpp.o -pthreadと普通にリンクしてしまい、 実行時に
% env LD_PRELOAD=/usr/lib/libc.so:/usr/local/lib/libmpatrol.so:/usr/lib/libpthread.so ./a.outとかしたら、全く問題無く、検査も実行も処理できた。 libc と libmpatrol と libpthread の３つ全部を、この順番で書かないと駄目。 これが一番楽だな……。 ccmalloc は静的リンクが必要なので駄目だけれど。
クレジット各社： 還元率色々。0.5％が多い。 最良は P-one の１％＋αか？、但し発行会社の親会社が皿？。 期限色々。２年が多い。 最良は P-one、スルガVISAデビット、無制限で確実に還元 セゾンの永久不滅 換金色々。通常は金券が限界。 P-oneだと下限金額無しで1.0％現金、その他ポイント付き。 スルガVISAデビットだと下限金額無しで0.2％現金。 NICOS-VIASOだと下限金額（20万円／１年）で0.5％現金。 三菱東京ＵＦＪだと（20万円／１年）単位で0.5％現金。 ネットマイル： 購入金額の１％分の金額（ポイント数では２％）？。 期限不明。 5000マイルでイーバンク・JNB・Edyの2500円。 へそクリック： 購入金額の１％？。 期限不明。 3000ポイントで3000円、手数料105円？。 ちょびリッチ： 購入金額の１％分の金額（ポイント数では２％）？。 期限１年（獲得・利用で延長）？。 1000ポイントでイーバンク・JNBの500円。 MyPoint： 1000円で５ポイント？。 期限不明。 750ポイントで金券500円？。 Ｇポイント： 購入金額の１％？。 期限不明。 換金不明。 キャッシュバックモール： 購入金額の１％が標準、一部店舗は0.5〜1.0〜1.5〜2.0〜％。 決済承認後にイーバンク宛送金で即時キャッシュバック。 マネックスポイントモール： 購入金額の１％がマネックスポイントで還元。 期限２年後の年度末。 50ポイントで永久不滅ポイント50ポイント。 400ポイントでANA 500マイル。 結論： 心底好きな店なら、その店の特売日を利用する。クレジットとかポイントとか使うと店の負担がそれより大きい。 還元率１％以上のクレジットカードを持っていれば、そこ。 それ以外の場合、どこか会員になっている所があれば、そこでいい。 還元条件ではキャッシュバックモールが一番良いらしい。 備考： ポイント還元やっている会社が信頼できるか否かは知らん。 ポイント還元やっている会社に登録したら個人情報を裏に売られるかどうかも知らん。 ポイント還元やっている会社に登録したらスパムが大量に来るかどうかも知らん。 マネックスって証券会社だよね？、なんかちょっと不思議な組み合わせ……。
Panasonic Let'snote CF-Y5
CoreDuo 1666MHz
FreeBSD 6.2-RELEASE-p4 SMP i386
・powerd 有効（CPU clock 125MHz〜1667MHz）
・バージョン：sdmmc-20070422a.tar.gz
・pciconf の結果（pci4:5:* のみ抜粋）
cbb0@pci4:5:0: class=0x060700 card=0x833810f7 chip=0x04761180 rev=0x8d hdr=0x02
vendor = 'Ricoh Co Ltd'
device = 'RL5c476 CardBus Controller'
class = bridge
subclass = PCI-CardBus
none4@pci4:5:1: class=0x080500 card=0x833810f7 chip=0x08221180 rev=0x13 hdr=0x00
vendor = 'Ricoh Co Ltd'
device = 'SD Bus Host Adapter'
class = base peripheral
・取り合えず kldload
kernel: sdshc0: mem 0xd0100400-0xd01004ff irq 20 at device 5.1 on pci4
kernel: sdshcbus0: on sdshc0
kernel: sdshcbus0: capability: 3.3V Suspend/Resume
・何もしないまま kldunload
kernel: sdshcbus0: detached
kernel: sdshc0: detached
・もう一度 kldload
kernel: sdshc0: mem 0xd0100400-0xd01004ff irq 20 at device 5.1 on pci4
kernel: sdshcbus0: on sdshc0
kernel: sdshcbus0: capability: 3.3V Suspend/Resume
・各種 SD の確認結果
(1) 東芝 miniSD 16MB (miniSD - SD アダプタ経由)
kernel: sdshcbus0: card inserted in slot #0
kernel: sd0: on sdshcbus0
kernel: sd0: Ver 1.x SD memory card
kernel: sd0: 14MB (29120 x 512-byte blocks)
kernel: sd0: access time: read 200.0us, write 6.4ms
kernel: sd0: speed class 0
kernel: sd0: max clock 25MHz, drive at 16.500MHz
kernel: sd0: 8.250MB/s transfers with 4-bit bus width
読出転送速度：521160B/s
（dd if=/dev/sd0 of=/dev/null bs=1024 count=16384 で計測）
kernel: sdshcbus0: card removed
kernel: sd0: detached
(2) Panasonic SD 16MB
kernel: sdshcbus0: card inserted in slot #0
kernel: sd0: on sdshcbus0
kernel: sd0: Ver 1.x SD memory card
kernel: sd0: 14MB (29120 x 512-byte blocks)
kernel: sd0: access time: read 500.0us, write 16.0ms
kernel: sd0: speed class 0
kernel: sd0: max clock 25MHz, drive at 16.500MHz
kernel: sd0: 8.250MB/s transfers with 4-bit bus width
読出転送速度：420422B/s
kernel: sdshcbus0: card removed
kernel: sd0: detached
(3) Panasonic SD 256MB
kernel: sdshcbus0: card inserted in slot #0
kernel: sd0: on sdshcbus0
kernel: sd0: Ver 1.x SD memory card
kernel: sd0: 244MB (499712 x 512-byte blocks)
kernel: sd0: access time: read 300.0us, write 9.6ms
kernel: sd0: speed class 0
kernel: sd0: max clock 25MHz, drive at 16.500MHz
kernel: sd0: 8.250MB/s transfers with 4-bit bus width
読出転送速度：507156B/s
kernel: sdshcbus0: card removed
kernel: sd0: detached
(4) HAGIWARA SYS-COM SD 512MB
kernel: sdshcbus0: card inserted in slot #0
kernel: sd0: on sdshcbus0
kernel: sd0: Ver 1.x SD memory card
kernel: sd0: 491MB (1006592 x 512-byte blocks)
kernel: sd0: access time: read 300.0us, write 9.6ms
kernel: sd0: speed class 0
kernel: sd0: max clock 25MHz, drive at 16.500MHz
kernel: sd0: 8.250MB/s transfers with 4-bit bus width
読出転送速度：500806B/s
kernel: sdshcbus0: card removed
kernel: sd0: detached
(5) BUFFALO SD (RSDC) 1GB
kernel: sdshcbus0: card inserted in slot #0
kernel: sd0: on sdshcbus0
kernel: sd0: Ver 1.x SD memory card
kernel: sd0: 973MB (1993728 x 512-byte blocks)
kernel: sd0: access time: read 80.0ms, write 2560.0ms
kernel: sd0: speed class 0
kernel: sd0: max clock 25MHz, drive at 16.500MHz
kernel: sd0: 8.250MB/s transfers with 4-bit bus width
読出転送速度：483194B/s
・ここで、umount せずにカードを抜いてみる
kernel: sdshcbus0: card removed
kernel: sd0: detached
・そのまま /mnt にアクセスしてみる
kernel: g_vfs_done():sd0s1[READ(offset=266752, length=16384)]error = 6
kernel: g_vfs_done():sd0s1[READ(offset=266752, length=16384)]error = 6
kernel: g_vfs_done():sd0s1[READ(offset=283136, length=16384)]error = 6
kernel: g_vfs_done():sd0s1[READ(offset=283136, length=16384)]error = 6
kernel: g_vfs_done():sd0s1[READ(offset=9638400, length=16384)]error = 6
kernel: g_vfs_done():sd0s1[READ(offset=9638400, length=16384)]error = 6
kernel: g_vfs_done():sd0s1[READ(offset=250368, length=16384)]error = 6
kernel: g_vfs_done():sd0s1[READ(offset=250368, length=16384)]error = 6
・umount すると、何事も無かったかの様に戻る
・再びカードを入れてみる
kernel: sdshcbus0: card inserted in slot #0
kernel: sd0: on sdshcbus0
kernel: sd0: Ver 1.x SD memory card
kernel: sd0: 14MB (29120 x 512-byte blocks)
kernel: sd0: access time: read 500.0us, write 16.0ms
kernel: sd0: speed class 0
kernel: sd0: max clock 25MHz, drive at 16.500MHz
kernel: sd0: 8.250MB/s transfers with 4-bit bus width
・問題無く使える
・カードを抜かないまま kldunload してみる
kernel: sd0: detached
kernel: sdshcbus0: detached
kernel: sdshc0: detached
・特に問題無し
○powerd を切って CPU clock 1667MHz 固定にした場合。
・kldload
kernel: sdshc0: mem 0xd0100400-0xd01004ff irq 20 at device 5.1 on pci4
kernel: sdshcbus0: on sdshc0
kernel: sdshcbus0: capability: 3.3V Suspend/Resume
・Transcend microSD 512MB （注：上記の中に同一の物がありません）
kernel: sdshcbus0: card inserted in slot #0
kernel: sd0: on sdshcbus0
kernel: sd0: Ver 1.x SD memory card
kernel: sd0: 486MB (996352 x 512-byte blocks)
kernel: sd0: access time: read 20.0ms, write 640.0ms
kernel: sd0: speed class 0
kernel: sd0: max clock 25MHz, drive at 16.500MHz
kernel: sd0: 8.250MB/s transfers with 4-bit bus width
読出転送速度：1227485B/s
May 22 03:13:03 <0.2> kitano kernel: sdshcbus0: card removed
May 22 03:13:03 <0.2> kitano kernel: sd0: detached
・東芝 miniSD 16MB (miniSD - SD アダプタ経由) （注：上記の１番目と同一の物）
読出転送速度：1045977B/s
・Panasonic SD 16MB （注：上記の２番目と同一の物）
読出転送速度：824377B/s
・Panasonic SD 256MB （注：上記の３番目と同一の物）
読出転送速度：992837B/s
・HAGIWARA SYS-COM SD 512MB （注：上記の４番目と同一の物）
読出転送速度：992378B/s
・BUFFALO SD (RSDC) 1GB （注：上記の５番目と同一の物）
読出転送速度：903169B/s
読込は mp3 とか jpg とかがエラー無しで再生できる事だけ確認、
面倒なので diff での確認は、していない、
と言うよりデータがカードの中だけなので比較しようが無い……、
別のリーダ使って読み出せば良かったのだ、今更気付いた（泣。
チキンなので、書込は試していない。
……、USB2.0 なアダプタの半分の速度しか出ていない……、
今回も、USBなアダプタの時も、
powerd で普段は CPU クロックが 125MHz にしているのを忘れていた、
影響あるかな？。
人柱報告募集中らしいので、後で送っておこう、
今回は、acpi_ppc の時の様に、
動作確認と安定動作を確認した時には、
もうプロジェクト？が次の段階に移っていた
（acpi_ppc → powerd になってコミット済み）、
とか言う事は無いらしい。
証明書失効リスト (CRL) をインポートできませんでした。 ローカルデータベースへの CRL のインポートに失敗しました。エラーコード:ffffe009 システム管理者に問い合わせてください。とか出てこける。 crl.verisign.com だから、あちらの設定ミスは、まず考えられない。 エラーコードの意味は、
SEC_ERROR_BAD_DER -8183 Security library: improperly formatted DER-encoded message.らしい。 １時間くらい、設定を試行錯誤した挙げ句、 キャッシュを全消去してやり直したら通った。 あぁ……（脱力）。
通常の二段組。
\begin{figure*}[htb]
\begin{center}
\begin{minipage}[htb]{1.0\textwidth}
一段組みにしたい中身。
\end{minipage}
\end{center}
\end{figure*}
通常の二段組。
で、できた。
三段組みとかそれ以上の多段組みを混ぜる場合なら、
通常の二段組。
\begin{figure*}[htb]
\begin{center}
\begin{tabular}{ccc}
\begin{minipage}[htb]{0.3\textwidth}
一段目の一列目。
\end{minipage}
&
\begin{minipage}[htb]{0.3\textwidth}
二段目の一列目。
\end{minipage}
&
\begin{minipage}[htb]{0.3\textwidth}
三段目の一列目。
\end{minipage}
\\
\begin{minipage}[htb]{0.3\textwidth}
一段目の二列目。
\end{minipage}
&
\begin{minipage}[htb]{0.3\textwidth}
二段目の二列目。
\end{minipage}
&
\begin{minipage}[htb]{0.3\textwidth}
三段目の二列目。
\end{minipage}
\\
\end{tabular}
\end{center}
\end{figure*}
通常の二段組。
で、できた。
段の中に図や表を入れないならば、minipage は不要だと思う。
もっとも、途中で段組みを変えるなんて、
図か表が多くて一列にたくさん入れる場合くらいだとは思う。
問題は、
figure 環境なので場所が特定しにくい事と、
手動で段毎に分けて書かなければならない事。
Style "スタイルと書式" Layer 9とでもしてやれば、取り敢えずは対処できるものの、気分的に悪い。 FvwmIconMan だと、Transient Window が一覧に出ないので、 行方不明になっていても気付く事が出来ないし。 FvwmTaskBar だと、Transient Window も一覧に出せるが、 タスクバーは好みじゃないし。
Style "OpenOffice*" NoFuncHint, Layer 5らしい。 OpenOffice の出力するヒンティングが間違っているっぽい。
cd /var/db/pkg pkg_delete -f xorg*で xorg*6.9 パッケージを全削除して、
portupgrade -p -N -R xorgしてみた。
bitstream-vera fontconfig driで更新が刺さった、 この３つは事前に消しておいた方が良さそう。 と、思ったら、
dri libdrm libXftでも依存関係の解決を間違えていた……、 もしかして portupgrade か pkg_tools 辺りに、 バグでもあるの？。
imake ja-ipa-ttfonts ja-kochi-ttfonts ja-mikachan-ttfonts ja-monafonts-ttf ja-sazanami-ttf ja-marumoji-fonts urwfonts synaptics辺りは、xorg に対する上方再帰更新（-R）だけでは更新されないので、 別途指定。 特に imake の更新を忘れると痛い事になる （imake を使う ports のビルドができなくなる）。 xorg 7.2 は、上から２階層目では、
xorg-docs xorg-fonts xorg-libraries xorg-server xorg-protos xorg-drivers xorg-appsになるらしい。 環境設定では、/etc/xorg.conf の
RgbPath "/usr/X11R6/lib/X11/rgb" ModulePath "/usr/X11R6/lib/modules" FontPath "/usr/X11R6/lib/X11/fonts/ほげほげ/"を
RgbPath "/usr/local/lib/X11/rgb" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/ほげほげ/"に書き換えないと X を起動できなくなる。 フォントの置き場所が変わるので、
ghostscript xpdf OpenOffice辺りのフォント指定も、場合によっては書き換えないといけない。 ここまでで、Athlon64 3500+ (2200MHz)(amd64) で５時間。 GTK とか Qt とか gnome とか KDE は、 取り敢えずそのままでも動いた。
ja-acroread7 xlockmore xtrlock xautolock kinput2辺りは、更新しておかないと、不都合が起きる場合がある、 xorg に対する上方再帰更新（-R）では更新されない。 特に ja-acroread7 は、更新しておかないと pdf の閲覧に支障が出る （ghostscript系では閲覧できない pdf が、閲覧できなくなる）。
AUDIT: *** *** ** **:**:** ****: ***** X: client 1 rejected from local host (uid *****) Xlib: connection to ":0.0" refused by server Xlib: No protocol specifiedとか出て、X が動かない。 .Xauthority を消したら問題無く動く様になった。
img:after { content: attr(alt) }
しても、何も表示されない。
img { border: 2px solid Red !important; }
は、表示される。
img:before { content: "foo"; border: 2px solid Red !important; }
は何も表示されない。
……。
http://d.hatena.ne.jp/amachang/20070510/1178797821#c
とか
http://forum.mozilla.gr.jp/?mode=al2&namber=12421&rev=&&KLOG=81
とか
https://bugzilla.mozilla.org/show_bug.cgi?id=245633
とかに書かれている様に、
「img:after とか img:before とかは、表示される方が間違っている」
らしい。
……、
末端ユーザとしては、表示して欲しいが……。