相方が携帯紛失

Ext2fsdをWindows7で利用するとBAD_POOL_HEADERエラーを引き起こしてブルースクリーンが発生する。
これは解放されたメモリを参照していることによって発生するらしい。
で、これを解消したパッチがあげられている。
このパッチの使い方は、freフォルダの、OSが32bitならi386の、64bitならamd64のext2fsd.sysを、Windows\system32\driversフォルダに放り込む。
ただし、このドライバは署名されていないため、64bitで利用するにはWindowsの起動時にF8でドライバの署名を強制しないオプションを指定しなければならない。

Linuxをインストールしたいと思ったとき、毎回CD-Rにやくのも面倒。
USBメモリからインストールできたら楽なことがある。
で、いいものをみつけた。

UNetbootinというもの。

これがかなりの優れもの。
LinuxではもちろんWindowsでもブータブルUSBドライブを作成でき、ビルトインで対応しているディストリビューション・バージョンのものは自動でイメージをダウンロードしてくれたりし、もちろん事前に用意したCDイメージやFDD/HDDイメージ、ISOイメージからkernel/initrdファイルまでもう何でもござれ状態。

使い方は起動してみればわかるレベルなので、USBメモリブートディスクを作りたい人はとりあえずダウンロードして起動してみるといい。

Western Digitalから4KiBセクタのHDDが出ている。

WD20EARS

現在2Tで11000円切るくらいの価格。

容量単価の安さからだろう、現在一番人気のHDDとなっているのだが、こいつがなかなかの曲者のようだ。

WDは4KiBセクタのHDDをadvance format technology採用とかいって売り出している。
AFTとかいってなんか新しい技術ですごそうみたいな感じに見えるが、かなり地雷というかやっかいなところがあるので、理解しないで手を出すと痛い目を見る可能性が高い。
実際価格.comでのレビューをみてると、データの転送が遅すぎてまともに使えないとか文句をいってるものが見える。
ちゃんとパフォーマンスを発揮するようにいじってやればなかなかいいものなんだけども、何も考えずとりあえず接続してパーティション切ってフォーマットして、とかやって使ってみたら、どうしようもない転送速度で涙目になってもおかしくはないくらいの変革なのだ。

HDDの最小記録単位であるセクタであるが、業界慣例というかなんというかでHDDでは512Bっていうのがもう通例となっている。
で、WDの出した4KiBセクタのHDDは、内部的には4KiBセクタなんだけども、外向きには512Bセクタであるかのように振る舞うようになっている。
つまり、物理セクタは4KiBで構成され、論理セクタは512Bのままということだ。
で、最近のOSはLBA（Logical Block Addressing）方式をとっており、ディスクアクセスの際、セクタ単位ではアクセスせず、複数のセクタをひとまとめにしたブロック（クラスタ、アロケーションユニット）単位でアクセスする。
んで、これが通常8論理セクタであり、つまり4KiBなわけである。（まあフォーマットオプションで変更もできるが）
HDDなんてどうせファイルシステム経由でアクセスされるわけで、最小単位を512Bじゃなくて4KiBにしたほうがちょうどで都合がいいじゃない、っていうわけだ。

だけど、なんで論理セクタなんてわざわざ間にかませているかというと、1セクタ512Bの法則はもうかれこれ20年以上もATA/ATAPIの世界で常識になっており、ドライバはおろかチップセットやらBIOSなんかでももう512Bだと仮定しているものが夥しく存在しているからだ。
ここでいきなり「ぼく1セクタ4KiBです＾－＾」とかいっても絶対とんでもないことが起きることはわかりきっているので、物理セクタと論理セクタを分離したわけだ。
ちなみにここの部分はハードディスクのファームウェアがそういうお仕事をしている。

でもって、ここからが問題をはらむ。
HDDは1トラック63セクタという業界慣例の法則がある。
で、最初の1トラックはMBRとして予約され、第一パーティションは2トラック目から開始する。
そして、通常、1シリンダ255トラックで構成され、CHSアドレッシングの名残を受け継いでいるパーティション（DOSパーティション。WindowsXPまでのWindowsとたいていのLinuxで採用されている）は、その後のパーティション境界はシリンダ境界と一致しなければならないという法則がある。
するってーとなにが起きるかというと、論理8セクタが物理1セクタと等価でなくなるという現象が発生する。

論理8セクタが物理1セクタと等価であるためには、パーティションがLBA 8*xなアドレスで開始していなければならない。
たとえば、パーティションがLBA63から開始しており、その先頭4KiBへのアクセスを考えてみる。

request                       |<--------------------->|
logical  |56|57|58|59|60|61|62|63|64|65|66|67|68|69|70|71|
phyisical|          7            |            8          |

このように、アクセスが二つの物理アドレスに常にまたがるようになる。
このとき、読み込みでは別に（大きな）問題はないんだけども、書き込みを行う際に、read modify writeという問題が発生する。
一応、読み込みでも読み込みたいブロック数+1を読み込まなければならなくなるので、影響はある。
たとえばこのLBA63-70への書き込みを行うとき、物理アドレスと論理アドレスが異なるため、書き込み命令であるにもかかわらず、論理アドレス56-62および71の情報を保持するため、いったん物理アドレス7,8を読み込み、書き込み内容をその命令にあわせて編集し、物理アドレス7, 8へ書き込む、という手順を踏まなくてはならない。
これは、非常に大きなパフォーマンスダウンを引き起こす。

で、この問題の解決方法の一つに、アラインメントオフセットという方法が用意されている。
これは、論理セクタの開始位置をずらし、物理セクタの最初を7論理セクタにする方法だ。
図で書くとこうなる。

logical  |  |00|01|02|03|04|05|06|07|08|09|10|11|12|13|14|
phyisical|          1            |            2          |

こうすると、一つ目のパーティションは論理セクタの63から開始するため、ちょうど物理セクタの8の開始と等しくなる。
そのため、read modify write問題は回避できる。
が。
これはあくまでも一つ目のパーティション限定の回避策だ。
しかも、一つ目のパーティションの開始位置が論理セクタ63ってわかってるときに限って有効。
二つ目以降のパーティションの開始論理セクタが物理セクタの開始位置と一致するかどうかは単純に1/8であり、全く使えない。

で、まともな解決方法＠Linux。

   physical sector size	: /sys/block/sdX/queue/physical_block_size
   logical sector size	: /sys/block/sdX/queue/logical_block_size
   alignment offset	: /sys/block/sdX/alignment_offset

に定義する。
phyisical_block_sizeは4096, logical_block_sizeは512, alinment_offsetにはずらすオフセット値を入れる。
パーティションの開始論理セクタが(PBS*n+AOFF)/LBSとなるようにする。
一つ目のパーティションの開始位置はLBA63なので、その場合AOFFは3584とする。
(4096*7+3584)/512=63といった具合。

ただ、この方法はこの方法でパーティションごとに計算して指定しないといけなく、なかなか面倒なうえに、ジオメトリパラメータがハードコーディングされているようなものがあるとうまく動作しないこともあり得る。

ということで、一番平和な方法としては、こちらからHDDの物理セクタを意識してパーティションを切ってやることとなる。

で、まず、Windows Vista以降について。
パーティション境界を1MiB境界に設定するようにしているため、実は気にする必要がない。
1MiB境界っていうことは4KiB境界でもあるためだ。
アラインメントオフセットが有効である場合はオフセット値を3584として定義するので、その場合でも問題ない。
が、ほかのディスクにイメージをクローンした場合とかを考えると面倒なので、オフセットは使わないようにするべき。

Windows XPではどうかというと、一つはオフセットを利用する方法。
そして、WDのHDDではユーティリティを使う方法がある
ファイルシステムをフォーマットしたあと、WD Align Utilityを使う。
やっていることは、推測だが、パーティション境界と物理セクタ境界が合わさるようにパーティションの切り直しとデータの移動を行っているんじゃないだろうか。
時間かかるみたいだし。

で、Linux。
fdiskだとパーティションの区切り方がシリンダ境界になってしまい、物理セクタ境界とあわせるのが面倒。
まあ開始シリンダを8の倍数にすればあわせられるけど、ロスが結構でる可能性がある。
単純に7*512*63*255バイト最大でロスする。
なので、GNU Partedを使ってパーティションを切る。
partedでは単位をセクタに指定できるので、それを利用してパーティションを切る。
単純に、開始セクタを8の倍数にすれば、物理セクタ境界とパーティション境界が一致するからだ。
たとえば、200GiBのプライマリパーティションを作成するなら以下のような感じ。

# parted
(parted) mkpart primary 64s 419430463s

開始が64セクタ目なのは、MBRの領域確保のため。
システムブートディスクとして使う予定がないなら8セクタを指定してもいいがそんなにけちらなくてもいいと思う。
また、Windows Vistaや7のように、1MiB境界をパーティション境界に指定してもいいと思う。
その場合は、1024*1024/512で2048セクタを開始位置に指定する。
Ubuntuのインストーラはその方式を採用したみたいだ。
ちなみに、パーティションの容量の計算は、G単位なら、n*2*1024*1024+開始セクタ-1となる。
ほかのパーティションを作成する際にも、開始セクタを8の倍数、終了セクタを8の倍数-1にすれば、物理セクタ境界とパーティション境界が一致しつつ、容量の無駄を出さないですむ。
もちろんpartedで切ったパーティションをWindowsで利用することも可能。
あとまあ、Linuxでならインストール時のパーティション切りの際に、シェルを起動してそこからpartedで切ったり、Live CDなんかからparedで切ってからインストールとかっていうのもできるため、そのあたりの自由度は高く、おのおのの環境に応じて柔軟な対応が可能だろう。
（パーティショニングツールの使い方がわからないとかっていうのは論外だが）

で、そのHDDかったのかって？

あ、はい、ぽちりました。

気を遣ってあげないといけない子とかかわいらしいじゃないですか。
まあ、彼女のマシン用なんだけどね。

xenでDomUを構築した際、コンソール接続したいと思うだろう。
通常、Linuxではttyが標準のキャラクタデバイスになっているが、xenでは専用の仮想コンソールデバイスがある。

それはxvcであったり、hvcだったりする。

What’s the correct console device name for my Xen PV guest

• Xenlinux (“xenified”) kernels use “xvc0″ as the console device.
• Upstream kernel.org pv_ops kernels use “hvc0″ as the console device

Examples of Xenlinux kernels using “xvc0″ console:

• xen.org linux-2.6.18-xen
• RHEL5 / CentOS5 kernel-xen 2.6.18
• Debian Etch 2.6.18-6-xen
• Debian Lenny 2.6.26-2-xen
• Ubuntu 8.04 LTS “hardy heron” 2.6.24 xen kernel
• Novell SLES 10 and SLES 11 xen kernels
• OpenSUSE xen kernels
• Various “xenified” forward-ports of the Novell/OpenSUSE Xen patches (2.6.29, 2.6.30, 2.6.31)

Examples of pv_ops domU kernels using “hvc0″ console:

• All upstream/mainline kernel.org Linux kernels since 2.6.26.
• Fedora 10, Fedora 11, Fedora 12 kernels
• Ubuntu 8.10 2.6.27 server-kernel
• Ubuntu 9.04 2.6.28 linux-image-server
• Ubuntu 9.10 2.6.31 ec2-kernel

で、xenではDomUとコンソール接続する際、標準ではそのキャラクタデバイスに接続するようになっている。

キャラクタデバイスを変えたい場合は、ブートオプションでxenconsで指定する。
実際はDomUの設定ファイルの、extraを用いて以下のようにすることが多いだろう。

extra='xencons=tty'

みたいな感じで。
でも特に理由がないなら標準の方を使った方がいいんだと思う。たぶん。

でまあ、DomUのセットアップの仕方によっては、DomUにxvc0あるいはhvc0が作られなかったりすることがある。
そういう場合は、作ってやればいい。

# mknod /dev/hvc0 c 229 0

みたいな感じで。

sshでもコンソールでもログインできないときはDomUのファイルシステムをマウントして、マウント先のdevに作ってやる。

で、/etc/inittabに以下を記述

1:2345:respawn:/sbin/getty 38400 hvc0

/etc/securettyに以下を記述

hvc0

ちなみにxvcはxen virtual console, hvcはhypervisor virtual consoleの略らしい。

なんかいろいろひどいことになってきましたｗｗｗ

まず、GFOUTLETのブログから

DECULTURE PT2X2ご予約頂いてるお客様へ
テーマ：ブログ

こんにちは。

GFアウトレット店長のキョウです。
DECULTURE　PT2X2ご予約のお客様へ
仕入れ元より再度の納期延期の連絡がありました。
前回、「部材の調達ミス」によりとの事でしたが
今回は製品上の「不具合発生」が原因との事です。
最短でも6月中旬になるとのお話ですが
これも確約ではないとの事です。

当店でもこれ以上の延期は心苦しい限りです。
再度、ご予約のお客様にお電話をさせて頂きます。
一度、ご返金をさせて頂ければと思います。

もちろん入荷確定時に再度、販売をいたしますので
その際も優先的にご案内させて頂きます。

ご返金方法は店頭でのご対応か銀行振り込みにて
対応させて頂ければと思います。

お忙しくてお電話に出れないお客様
お店までお電話頂くかメールでも対応いたします。

GFアウトレット電話番号
03-6206-8290

メールアドレス
info@gf-outlet.com

ご予約表に記載の予約番号とお名前・ご連絡先を
記載お願いします。
この度はご迷惑をおかけして申し訳ございません。

はい、5月末消えた－。
ってか絶対とんずらだってｗ

そして、ディスカウントショップ キララでは、正規PT2をPT2X1といって送ってくる事態が発生ｗｗｗ
PT2X2じゃないしX1って、PT2 数量 x1 っていう感じだろうか。ｗ

これに対して、2chより

4 名無しさん＠編集中 [sage] 2010/05/24(月) 23:19:55 ID:+h5N5FsX Be:

違う商品では？と送った、キララからの返信

> ※メールのご返答においては順次となります。ご了承ください。
> —————————————
>
> ディスカウントキララです。ご連絡ありがとうございます。
> ご注文いただきました商品の赤のカラーの商品は
> メーカーの発売納期が延滞に延滞となり、
> 現時点でも６月末まで延期しております。
>
> 現在ネット上でも多数の製品メーカーやブログ、販売サイトより指摘があるように
> 一部PT2を超える機能について論議がございます。
>
> 楽天市場と卸メーカーと協議の中、
> 正規専門チューナーのアースソフトの「PT2」を別途入荷させていただきまして
> 価格は今回販売させていただきました商品より高価な
> 製品として保証と不具合なき正規商品をご用意させていただきました。
>
> 参照　
> http://www.coneco.net/PriceList.asp?COM_ID=1090714383
>
> 取り急ぎ出荷を指示しておりましたので、ご連絡が後からのご連絡となり
> 大変申し訳ございません。
>
> 今回予約販売の赤のPT2において、メーカーの機能の検証中となっておりますが
> 一部販売を停止するようメーカーや楽天からの
> 連絡がある場合など全てのお客様にアースソフトのPT2をご用意させていただくよう
> 店舗の販売責任として考えております。
>
> お送りさせていただきました商品にてお気に召さないとのことでしたら
> 全額ご返金も承ります。
> ご検討いただきましてご希望がございましたらご連絡ください。

xenでinitrdをDom0とDomUで同じのを使うのは基本的にはNGっていう。
というのも、DomUの（仮想）ハードウェア構成は当然Dom0とは異なる。
従って、DomUのinitrdはDomUで作成したものを利用するべきなわけだ。

んだけども、DomUで作成したものはDomUのファイルシステムにおかれるわけで、これはDomUが起動していないときならマウントして中身をみることは可能だけども、 起動しているときは当然みれず、起動前にマウントしていたら当然DomUは起動できない。
実際のところDom0から見える必要があるのは起動時だけなんだけども、起動時にDom0から見える＝DomUのファイルシステムがマウントされている＝DomUは起動できない。

となると、DomUで使うカーネルやら初期RAMディスクやらをDom0のファイルシステム上に配置するのがたぶんまともな解決方法。
だけどそれらは一度配置したあとなかなか更新がかからないなら、scpやらなんやらで移してやればいいんだけども、sidなんかで運用している場合は意外とちょいちょい更新があり面倒。
じゃあ自動で転送する仕組みを作ろう。

とここまで書いてはや数時間。
どうしたらいいものか悩んでいる。
とりあえず、転送自体はscpなりでやればよく、それはスクリプトを書けばいい。
問題はスクリプトを実行するタイミングだ。
cronで回すのはスマートじゃないし、やっぱりinitramfs-toolsが動いた後に動いてほしい。
そうすると。。。かれこれ数時間悩んだが、思いつかない。

initramfs-toolsのmanページを眺めまくったがなんとも。

とりあえず、転送スクリプトだけでも作る。

とおもったところで閃いた。

DomUを起動する時に、いったんDomUのファイルシステムをマウントして、initrdとかをDom0にコピーしてから起動するようにすればいいはずだ。

と思って何とかならないかごちゃごちゃ調べていたら、見つかった。
DomUの設定ファイルはpythonスクリプトを実行できる。
これでかつる。（pythonとか全然書き方しらないけど）

さて、pythonのお勉強を始めるのもあれなので、pythonでシェルスクリプト呼び出す方法を調べた。
osモジュールをimportしてやってos.system関数を呼び出してやればいけるようだ。
ということで、シェルスクリプトを書く。

シェルスクリプトの内容は以下のようにする。

• DomUが利用するファイルシステムをマウント
• マウントポイント/bootからkernelとinitrdをコピー
• アンマウント

ということで、途中いろいろ試行錯誤はあったものの、最終的には以下のようなシェルスクリプトを書いた。

#!/bin/sh

# usage
# kernelfetch.sh DomU_Disk mount_point arch kernel_dist
# DomU_disk_path - path to DomU disk which contains DomU kernel and initrd
# mount_point - path to mount point where DomU_Disk will be mounted
# kernel_dist - Path to the directory where DomU kernel and initrd will be saved

# args check
if [ $# -ne 3 ]; then
 echo "usage: $0 DomU_Disk_path mount_point kernel_dist"
 exit 1
fi

if [ ! -d $2 -o ! -d $3 ]; then
 echo "directory not found"
 exit 2
fi

if [ -f $1 ]; then
 MOUNT_OPT="-o loop"
elif [ ! -b $1 ]; then
 echo "DomU disk not found"
 exit 3
fi

# kernel paths and names
BOOT_DIR="$2/boot/"
KERNEL_PREFIX="vmlinuz-"
INITRD_PREFIX="initrd.img-"

# mount DomU disk which contains kernels
if ! mount ${MOUNT_OPT} $1 $2; then
 echo "mount failed"
 exit 4
fi

# copy the kernel
if ! cp ${BOOT_DIR}${KERNEL_PREFIX}* ${BOOT_DIR}${INITRD_PREFIX}* $3; then
 echo "copy failed"
 umount $2
 exit 5
fi

umount $2

exit 0

このシェルスクリプトは、指定されたディスクイメージあるいはデバイスを、指定ディレクトリにマウントして、指定ディレクトリ/bootからカーネルイメージと初期RAMディスクイメージを指定したディレクトリにコピーして、アンマウントする、という流れになっている。

で、DomUの設定ファイルでこのスクリプトを実行し、持ってきたイメージを使うように書き換える。

import os

os.system('/etc/xen/scripts/kernelfetch.sh /dev/fileserver/fileserver /mnt/xentmp /etc/xen/kernel/file')

kernel      = '/etc/xen/kernel/file/vmlinuz-2.6.26-2-xen-amd64'
ramdisk     = '/etc/xen/kernel/file/initrd.img-2.6.26-2-xen-amd64'

そのほかの部分は通常のDomUの設定と同じ。
ようやくうまく動いた。

Windows7での電源管理では、通常終了のほかにハイバネート（休止状態）、スタンバイ（サスペンド・スリープ）、ハイブリッドスリープ（スリープ）がある。
これらの違いは以下のようになる。

• ハイバネート
  メモリの内容をHDD（hiberfil.sys）に保存して、すべてのデバイスの電源を落とす。ACPIのステータスS4。
• スタンバイ
  ACPIのサスペンドタイプによる。
  S1（パワーオンサスペンド）の場合は各種デバイスの通電したまま休止状態に移行する。
  省電力効果はないが復帰が早く、デバイス関連の不具合も出にくい。
  S3（メモリサスペンド）の場合は、チップセットとメモリには通電したままで、その他のデバイスの電源を落とす。
• ハイブリッドスリープ
  メモリの内容をHDDに保存するほかはスタンバイと同じ。

ちなみに、これらの機能はBIOSやらハードウェア、OSが対応していないと使えない。
ACPI非対応のデバイスに対してこれらの機能を利用すると、S1では平気なことも多いがS3, S4から復帰後に正常動作しなかったりする。

これらの特徴は以下のようになる。

• ハイバネート
  • 一切の通電がないので、消費電力はない。
    が、実際のところは電源とコンセントつないでいると微妙に電力流れるんでそこだけはある。
  • メモリの内容をHDDに移すので、大容量メモリの低速度HDDだとハイバネート時の時間がかかったりする。
  • メモリの内容がHDDに移っているので、コンセントを引っこ抜いても情報は消えない。
  • OSデータのロード等が省略されるため、起動が速い。
• スタンバイ
  • S1は省電力効果はないが、S3の場合はチップセットとメモリだけの通電になるので消費電力がごく少量に抑えられる。
    実測値で2Wから5W程度の模様。
    電源コンセントが刺さっているだけでの消費電力を差し引けば、メモリやチップセットによるだろうが1Wから3W程度と思われる。
  • ブレーカーが落ちたりすると通電が途切れるのでメモリのデータが消え、復帰できなくなる。
  • スタンバイ移行はメモリのHDDへの転送が行われないので高速。
  • 復帰もメモリにデータがすでに存在している状態なのでわずか数秒。
• ハイブリッドスリープ
  • 消費電力はスタンバイと同じ。
  • スタンバイ移行速度はハイバネートと同じ。
  • 復帰速度はスタンバイと同じ。
  • ブレーカーが落ちてもメモリのデータがHDDにあるため、スタンバイと比べると速度は落ちるが、ハイバネートと同等の速度で復帰可能。

とりあえず、ACPI対応のBIOS、OS、ハードウェアを使っているのであれば、これらの機能を使わない手はないと思う。
基本的に最近の周辺機器は対応しているし、対応していないものはかなりレガシーなものだろう。
まず、個人的に一押しはやはりハイブリッドスリープだ。
これは当然ACPIステータスS3で利用することが前提となる。
マイクロソフトと珍しく気が合うことになっているが、Windows7ではデスクトップでは基本的にデフォルトでハイブリッドスリープが有効になっている。
ハイブリッドスリープが有効になっているかどうかを確認するには

スタート->コントロールパネル->ハードウェアとサウンド->電源オプション->コンピュータがスリープ状態になる時間を変更->詳細な電源設定の変更->スリープ->ハイブリッド スリープを許可する

で設定がオンになっているか確認する。
スリープ時にS1で動作するかS3で動作するかはBIOSの設定による。
当然S3推奨、っていうか電源オフの代わりに利用するならS3じゃないと電気くいまくりで話にならない。

ハイブリッドスリープを有効にできない場合はBIOSやらチップセットやらどっかが対応していないと考えられる。
ちなみにノートPCはACアダプタを普段さしているならスリープを選択してもいいだろうが、そうじゃないなら少量とはいえ電力を消費するため、ハイバネートするようにした方がいいだろう。
ただでさえ電源オフで放置していてもバッテリー残量は少しずつ減っていくわけで。

Vistaからガジェットが使えるようになっているんだけども、CPUやGPUの使用率や温度をモニタリングできるガジェットがないかと思って探していた。
探してみればわかるんだが、使用率を表示できるものはいろいろあるんだけども、温度まで測定できるものは限られてくる。

で、候補は以下に絞られた。

• Multi Meter
  • いろいろな情報を表示可能。
    ただし温度は表示できない。
• HWMonitor Meter
  • CPUIDのHWMonitorから情報をフェッチしてきて表示する。
    このため温度も表示可能。
    ただし、動作にはHWMonitorの実行が必須。
    表示可能項目数が確か12項目くらいに制限されてる。
    表示可能な項目もHWMonitorで表示される情報のうちの一部。
• GPU Observer
  • GPUの温度を含めた一通りの情報を表示可能。
• Intel Core Serires
  • IntelのCore系CPUの温度を含めた一通りの情報を表示可能。

はじめはMulti MeterとHWMonitor Meterでいろいろと表示させようと思ったのだが、表示させる項目の設定なんかは最初すっからかんである上に、設定方法がめんどくさい。
ついでに、この組み合わせだとCPUの利用率とCPUの温度を別々のガジェットでみなければならない。
個人的にはCPUに関する情報はCPUに関するものとして一つのガジェットで表示させたい。
そこでほかにないか探したところ、GPU ObserverとIntel Core Seriresを見つけた。

GPU Observerはインストールしたら素直に動いてくれた。
グラボがGTX295であるため、GPU Observerを二つ動かして二つのコアをおのおのに表示させ、表示項目をちょちょいといじってOKだった。

はまったのはIntel Core Seriresの方だ。
これがまたクロックも電圧も温度も表示してくれない。
このガジェットはCPUの各種情報を取得するのにWinRing0を使っている。
温度表示なんかを有効にするには、ガジェットの設定からWinRing0のインストールを行う必要がある。
で、インストールしたんだけども、表示されない。
レジストリを見た感じWinRing0のバージョンは1.2のようだ。
でまあ、WinRing0の配布元のOpenSysLibにいくと、WinRing0の2.0が配布されていた。
1系は1.3まで出ていたようだが、配布は終了している。
ということで、こっちに置き換えてみたら何とかなるかもしれないと思い、同梱されているWinRing0のドライバを2.0に置き換えることにした。

1. WinRing0をアンインストール
2. ガジェットを終了
3. [WinDrive]:\Users\[UserName]\AppData\Local\Microsoft\Windows Sidebar\Gadgets\IntelCoreSeries24.gadgetにWinRing0 2.0のWinRing0.dll,WinRing0.sys,WinRing0x64.dll,WinRing0x64.sysを突っ込む
4. ガジェットを起動
5. WinRing0をインストール

エラーが出た。
サポートされないAPIだとかどうとか。
1.2と2.0でAPIが違うらしい。
下位互換くらい保っておけよと思いつつもWinRing0について調べてみたら、どうもこれは意図的らしい。
というのも、WinRing0 1.x系はカーネルモードドライバとして動作して、I/Oポートやら物理メモリやらいろいろともう生々しいレベルでタッチして動いているものだそうだ。
当然それは便利であるとともに、セキュリティ上のリスクを生じるものでもある。
そういった観点から鑑みて、

本質的に WinRing0 は存在してはならないライブラリ

だったとして、配布を停止したらしい。
ちなみに、カーネルモードドライバはWindows Vista x64以降、デジタル署名が要求される。
デジタル署名の失効の回避という事情もあったようだ。

まあなんにせよ、WinRing0 2系は、そういった関係から、APIに互換性はほとんどないんで、Intel Core Serires同梱のWinRing0が原因かどうかもわからないんだけども何か方法がないかと探していた。

あった。

728 名無し~3.EXE [] 2010/04/22(木) 17:16:00  ID:eDshp0TI  Be:
 >>4
 にあったリンク

http://blog.orbmu2k.de/category/sidebar-gadgets

 からCPUのガジェット落として使ってた
 OS再インスコしたら温度表示されなくなったんだけど
 原因分かる人いる？

 ちなみにOSインスコしてアップデートした後にガジェット
 インスコ、GPUのも最初なにも表示されなっかけどCPUIDの
 アプリインスコしたら表示されるようになった

 よろしくお願いします 

732 名無し~3.EXE [sage] 2010/04/23(金) 23:20:19  ID:zMNeiTas  Be:
 >>728
 うちも同じ状況だ… OSはWin7 Pro x64
 もともとVer2.1を使ってたのを2.4に更新したらおかしくなった…
 元に戻しても、2.0にしてもダメ。
 WinRing0 Driverのせいかと思って入れ直したりしたけど変わらず…

 というか、GPUのもその後しばらくたってから突然グラボを認識しなくなった…
 CPUIDの何入れました？ HWMonitorは入れてあるんだけど… 

734 名無し~3.EXE [sage] 2010/04/24(土) 04:57:15  ID:8VNNtnLG  Be:
 >>728 >>732
 はいよ。細かいことはreadmeみてくれれ

http://www1.axfc.net/uploader/File/so/42631.zip

readmeから引用

原因：IntelCoreSeries24に同梱されているドライバが正常に動かない。
解決策：ドライバだけIntelCoreSeries23から抜き出して上書きする。

ソースは2ちゃん。
にらみどころはそう間違ってなかったみたいだ。
ってか734神。

ようやく動いた。

もう意味がわからない。

説明するのもあれなんで動画でもどうぞ。

watch?v=GxK-0Xg4JcY

Firefox 3.7のnightly buildはすでに出ているのだが、Firefox 3.7は出さないことになったらしい。

Firefox 3.7 については、最大の開発目標であったプラグインのプロセス分離 (OOPP: Out Of Process Plugins) 機能を Firefox 3.6.4 にマージできたため、Firefox 3.7 というマイナーバージョンアップはなくなりました。

だそうで。
詳しくはこちらを参照。

そーすっとwebglはどうなるんだろう。
webglってのはブラウザ上でOpenGLを使って3D表現をする技術。
Firefoxでは3.7でサポートされるはずだったんだけど、そーすっと3.6.4に組み込まれるのか、4.0待ちになるのか気になるところ。

3.6.4は6/1にリリースされるようだ。

ちなみにFirefoxでwebglを使うには、about:configでwebgl.enabled_for_all_siteをtrueで有効にできる。
Configuration Maniaを使う方が楽だけど。
グラフィックカードがOpenGL 2.0非対応なものだったりするなら、ソフトウェアレンダリングも可能。
その場合はMesa 3D Graphic Libraryを拾ってきて、webgl.osmesalibでパスを指定する。
まあこれもConfiguration Maniaでやった方が。
ちなみにwebglのデモはここにいろいろある。
一応再度いっておくと、今現在firefoxでwebglを使うには、Firefox 3.7のnightly buildじゃないといけない。