Take It EASY!!: 2011

2011年9月18日

USB3.0ハブを調べてみる

USB3.0ハブを入手したので少し調べてみました。
まずは dmesg でどのように認識されているかを確認。USBデバイスが2つ認識されていた。1つはHigh-SpeedのUSBハブ。もう1つはSuper-SpeedのUSBハブ。
前から気になっていたけど、やはりUSB3.0ハブは上記のように内部的に2つのハブが存存在する模様。

hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
hub 3-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
usb 3-1: new high speed USB device number 2 using xhci_hcd
xhci_hcd 0000:05:00.0: WARN: short transfer on control ep
usb 3-1: default language 0x0409
xhci_hcd 0000:05:00.0: WARN: short transfer on control ep
usb 3-1: udev 2, busnum 3, minor = 257
usb 3-1: New USB device found, idVendor=2109, idProduct=3431
usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 3-1: Product: USB2.0 Hub
usb 3-1: usb_probe_device
usb 3-1: configuration #1 chosen from 1 choice
usb 3-1: Successful Endpoint Configure command
usb 3-1: adding 3-1:1.0 (config #1, interface 0)
hub 3-1:1.0: usb_probe_interface
hub 3-1:1.0: usb_probe_interface - got id
hub 3-1:1.0: USB hub found
xhci_hcd 0000:05:00.0: WARN: short transfer on control ep
hub 3-1:1.0: 4 ports detected
hub 3-1:1.0: standalone hub
hub 3-1:1.0: individual port power switching
hub 3-1:1.0: individual port over-current protection
hub 3-1:1.0: Single TT
hub 3-1:1.0: TT requires at most 32 FS bit times (2664 ns)
hub 3-1:1.0: Port indicators are supported
hub 3-1:1.0: power on to power good time: 100ms
usb 3-1: Successful Endpoint Configure command
hub 3-1:1.0: local power source is good
hub 3-1:1.0: enabling power on all ports
hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0002
hub 4-0:1.0: port 1, status 0103, change 0001, 5.0 Gb/s
hub 4-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x103
usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
usb 4-1: skipped 1 descriptor after endpoint
xhci_hcd 0000:05:00.0: WARN: short transfer on control ep
usb 4-1: default language 0x0409
xhci_hcd 0000:05:00.0: WARN: short transfer on control ep
xhci_hcd 0000:05:00.0: WARN: short transfer on control ep
usb 4-1: udev 2, busnum 4, minor = 385
usb 4-1: New USB device found, idVendor=2109, idProduct=0810
usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 4-1: Product: 4-Port USB 3.0 Hub
usb 4-1: Manufacturer: VIA Labs, Inc.
usb 4-1: usb_probe_device
usb 4-1: configuration #1 chosen from 1 choice
xhci_hcd 0000:05:00.0: WARN no SS endpoint bMaxBurst
usb 4-1: Successful Endpoint Configure command
usb 4-1: adding 4-1:1.0 (config #1, interface 0)
hub 4-1:1.0: usb_probe_interface
hub 4-1:1.0: usb_probe_interface - got id
hub 4-1:1.0: USB hub found
hub 4-1:1.0: 4 ports detected
hub 4-1:1.0: standalone hub
hub 4-1:1.0: individual port power switching
hub 4-1:1.0: individual port over-current protection
hub 4-1:1.0: TT requires at most 8 FS bit times (666 ns)
hub 4-1:1.0: power on to power good time: 2ms
usb 4-1: Successful Endpoint Configure command
hub 4-1:1.0: local power source is good
hub 4-1:1.0: enabling power on all ports
hub 3-1:1.0: state 7 ports 4 chg 0000 evt 0000
hub 4-1:1.0: state 7 ports 4 chg 0000 evt 0000

続いてディスクリプタの内容を見てみる。

2つのハブがそれぞれにディスクリプタを持っている。ちなみにUSB3.0ではハブディスクリプタの構造が変更になっているが、High-SpeedのハブはUSB2.0のハブディスクリプタを持っており、Super-SpeedのハブはUSB3.0のハブディスクリプタも持っている。Super-SpeedのハブはContainer IDのディスクリプタもあった。

Bus 003 Device 002: ID 2109:3431 --> USB2.0ハブ

Device Descriptor:

bLength 18

bDescriptorType 1

bcdUSB 2.00

bDeviceClass 9 Hub

bDeviceSubClass 0 Unused

bDeviceProtocol 1 Single TT

bMaxPacketSize0 64

idVendor 0x2109

idProduct 0x3431

bcdDevice 2.88

iManufacturer 0

iProduct 1 USB2.0 Hub

iSerial 0

bNumConfigurations 1

Configuration Descriptor:

bLength 9

bDescriptorType 2

wTotalLength 25

bNumInterfaces 1

bConfigurationValue 1

iConfiguration 0

bmAttributes 0xe0

Self Powered

Remote Wakeup

MaxPower 100mA

Interface Descriptor:

bLength 9

bDescriptorType 4

bInterfaceNumber 0

bAlternateSetting 0

bNumEndpoints 1

bInterfaceClass 9 Hub

bInterfaceSubClass 0 Unused

bInterfaceProtocol 0 Full speed (or root) hub

iInterface 0

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x81 EP 1 IN

bmAttributes 3

Transfer Type Interrupt

Synch Type None

Usage Type Data

wMaxPacketSize 0x0001 1x 1 bytes

bInterval 12

Hub Descriptor:

bLength 9

bDescriptorType 41

nNbrPorts 4

wHubCharacteristic 0x00e9

Per-port power switching

Per-port overcurrent protection

TT think time 32 FS bits

Port indicators

bPwrOn2PwrGood 50 * 2 milli seconds

bHubContrCurrent 100 milli Ampere

DeviceRemovable 0x00

PortPwrCtrlMask 0xff

Hub Port Status:

Port 1: 0000.0100 power

Port 2: 0000.0100 power

Port 3: 0000.0100 power

Port 4: 0000.0100 power

Device Qualifier (for other device speed):

bLength 10

bDescriptorType 6

bcdUSB 2.00

bDeviceClass 9 Hub

bDeviceSubClass 0 Unused

bDeviceProtocol 0 Full speed (or root) hub

bMaxPacketSize0 64

bNumConfigurations 1

Device Status: 0x0001

Self Powered

Bus 004 Device 002: ID 2109:0810

Device Descriptor:

bLength 18

bDescriptorType 1

bcdUSB 3.00

bDeviceClass 9 Hub

bDeviceSubClass 0 Unused

bDeviceProtocol 3

bMaxPacketSize0 9

idVendor 0x2109

idProduct 0x0810

bcdDevice 3.88

iManufacturer 1 VIA Labs, Inc.

iProduct 2 4-Port USB 3.0 Hub

iSerial 0

bNumConfigurations 1

Configuration Descriptor:

bLength 9

bDescriptorType 2

wTotalLength 31

bNumInterfaces 1

bConfigurationValue 1

iConfiguration 0

bmAttributes 0xc0

Self Powered

MaxPower 2mA

Interface Descriptor:

bLength 9

bDescriptorType 4

bInterfaceNumber 0

bAlternateSetting 0

bNumEndpoints 1

bInterfaceClass 9 Hub

bInterfaceSubClass 0 Unused

bInterfaceProtocol 0 Full speed (or root) hub

iInterface 0

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x81 EP 1 IN

bmAttributes 19

Transfer Type Interrupt

Synch Type None

Usage Type Feedback

wMaxPacketSize 0x0002 1x 2 bytes

bInterval 16

bMaxBurst 0

Hub Descriptor:

bLength 12

bDescriptorType 42

nNbrPorts 4

wHubCharacteristic 0x0009

Per-port power switching

Per-port overcurrent protection

bPwrOn2PwrGood 1 * 2 milli seconds

bHubContrCurrent 8 milli Ampere

bHubDecLat 0.0 micro seconds

wHubDelay 4000 nano seconds

DeviceRemovable 0x00

Hub Port Status:

Port 1: 0000.02a0 5Gbps power Rx.Detect

Port 2: 0000.02a0 5Gbps power Rx.Detect

Port 3: 0000.02a0 5Gbps power Rx.Detect

Port 4: 0000.02a0 5Gbps power Rx.Detect

Binary Object Store Descriptor:

bLength 5

bDescriptorType 15

wTotalLength 42

bNumDeviceCaps 3

USB 2.0 Extension Device Capability:

bLength 7

bDescriptorType 16

bDevCapabilityType 2

bmAttributes 0x00000002

Link Power Management (LPM) Supported

SuperSpeed USB Device Capability:

bLength 10

bDescriptorType 16

bDevCapabilityType 3

bmAttributes 0x00

Latency Tolerance Messages (LTM) Supported

wSpeedsSupported 0x000e

Device can operate at Full Speed (12Mbps)

Device can operate at High Speed (480Mbps)

Device can operate at SuperSpeed (5Gbps)

bFunctionalitySupport 0

Lowest fully-functional device speed is Low Speed (1Mbps)

bU1DevExitLat 3 micro seconds

bU2DevExitLat 1255 micro seconds

Container ID Device Capability:

bLength 20

bDescriptorType 16

bDevCapabilityType 4

bReserved 0

ContainerID {00000000-0000-0000-0000-000000000000}

Device Status: 0x0001

Self Powered

ちなみに、確認した環境は…

ホストPC : Gentoo Linux (kernel 2.6.39-gentoo-r3)

USBハブ : Buffalo BSH4A04U3BK

2011年4月24日

Gentoo Linuxで python をアップデート (2.6 -> 2.7)

Gentoo LinuxのPortageでPythonが2.6から2.7にアップデートがありました。アップデートしたら見事に(案の定?)トラブったので、僕が対応した方法をメモしておきます。

現象
portageによるpythonのアップデート(python-2.7.1-r1)後、emergeコマンドが一切動作しなくなる。x86-stableパッケージ(x86)を利用しており、python-2.7はSlotでインストールされていた。

解決方法
僕の場合は以下の方法で解決することができました。
まず、eselectでpythonパッケージを2.7に変更する
  $ eselect python list (python2.7の番号を確認。僕の環境では[1])
  $ eselect python set 1 (確認した番号[1]で設定する)
続いて python-updater コマンドで旧pythonに依存するパッケージの再ビルドを行う
  $ python-updater

これで解決しました。長らく使っていた2.6系はこれで不要に。--depcleanでアンインストール

NetBSDのUSBホストコントローラのドライバIF

NetBSDカーネル内部の話になります。

NetBSDのUSB(ホスト)ドライバでは各種ホストコントローラ(以下、HC)とUSBプロトコルドライバ間でIFが切られています。上位のプロトコルドライバからはHC種別(ehci, ohci, uhci)は意識せず、このIF関数をコールすることでホストコントローラを制御しています。今回、このIF形式と各IF関数で行う処理内容に関して簡単にまとめます。

なお今回、NetBSD-5.1を対象に記載しています。NetBSDでUSBホストドライバがサポートされてからIFは大きく変わっていません。

インタフェース形式
HCドライバのIFは、usbd_bus_methods構造体とusbd_pipe_methds構造体で宣言されています。本構造体は dev/usb/usbdivar.h で型宣言されており以下のような構造になります。

struct usbd_bus_methods {

usbd_status (*open_pipe)(struct usbd_pipe *pipe);

void (*soft_intr)(void *);

void (*do_poll)(struct usbd_bus *);

usbd_status (*allocm)(struct usbd_bus *, usb_dma_t *, u_int32_t bufsize);

void (*freem)(struct usbd_bus *, usb_dma_t *);

struct usbd_xfer * (*allocx)(struct usbd_bus *);

void (*freex)(struct usbd_bus *, struct usbd_xfer *);

};

struct usbd_pipe_methods {

usbd_status (*transfer)(usbd_xfer_handle xfer);

usbd_status (*start)(usbd_xfer_handle xfer);

void (*abort)(usbd_xfer_handle xfer);

void (*close)(usbd_pipe_handle pipe);

void (*cleartoggle)(usbd_pipe_handle pipe);

void (*done)(usbd_xfer_handle xfer);

};

構造体名から想像できますが、usbd_bus_methodsはHCに紐付けられたHCとして行うべき関数をまとめた構造体です。一方usbd_pipe_methodsはUSBの転送パイプ(コントロール転送とかバルク転送)として行うべき関数をまとめた構造体になります。

各関数で行うべき処理に関して、以下に記載します。

open_pipe

USB転送パイプのオープンを行います。上位で転送パイプを用いてデータ転送する場合にはまず本IFで転送パイプの初期化処理を行います。HCごとに転送パイプの取扱いおよび必要なデータ構造が異なるため本IFが用意されています。また本関数内部でUSB転送パイプとusbd_pipe_methodsの紐付けを行います。

soft_intr

割り込み処理を行う関数です。NetBSDのUSBホストドライバではUSB関連の割り込み処理はハード割り込みのコンテキストではなく、ソフト割り込みのコンテキストで実行することが設計ポリシーとなっており、ソフト割り込み実行時にも本関数が実行されます。各HCドライバ内での動きとしては、ハード割り込みが発生した際にソフト割り込みのスケジューリングを行い、そのソフト割り込み内で割り込み処理を行う流れになります。

do_poll

割り込をソフト側でポーリングするためのIFです。割り込み禁止状態でハードからのイベント(=割り込み)待ちが必要となるような場合に利用するIFです。

allocm

HCに渡す送受信用データ領域のメモリ確保を行う際のIFです。メモリ領域確保自体はHCに依存する部分は少なくNetBSD-5.1でも各HCでほとんど共通の処理を行っています。(HCによって送受信データのアライメントがある場合や特殊制御が必要な場合には本IFが意味を持ちます。)

freem

allocmで確保したメモリ領域を解放する際のIFです。

allocx

USB転送(usbd_xfer)を確保する際のIFです。HCでは転送単位で必要となる処理が多いたえめ、本IFは(allocmと異なり)HCごとに大きく異なるため、各HCごとに必要なデータ領域の確保等を行います。

freex

allocxで確保したUSB転送データ構造を解放する際のIFです。

transfer

上位USBプロトコルドライバからUSB転送を開始する際のIFです。

start

実際にHCに対してUSB転送を行う際のIFです。上記transferとstartの差異について説明しますが、NetBSDのUSBドライバの作りとしてUSB転送はパイプごとにキューイングする作りになっています。transfer()はこのキューにデータをエンキューするためのIFで、start()はキューのデータを実際に転送するIFです。またNetBSDのUSBドライバはデータ転送が終了した際にコールバック内でstart()を実行することで次の転送を開始するような作りにもなっています。

abort

転送中のUSB転送を中止する際のIFです。

close

open_pipe()でオープンしたパイプをクローズするIFです。

cleartoggle

USBプロトコルで定められているトグルをクリアするIFです。トグルの制御方法はHCごとに異なっておりHC(ハード)が完全制御するもののありますが、ソフト側で制御が必要なものもあるため本IFが存在します。

以上。

2011年4月23日

USB3.0とUSB2.0の差異その1 （USBハブクラスのStatusフィールド）

今、USB3.0の仕様を色々と見ています。「プロトコル層より上位は互換性がある」といったことも聞きますが、実際には細かなところに差異があります。特にUSB3.0ではハブの仕様が大きく変更されておりクラスリクエストも見直されています。
その違いの1つとして、ハブクラス仕様で決められているPort Status Field(wPortStatus)とPort Change Fileld(wPortChange)を以下で比較してみます。

USB3.0：wPortStatus

Bit 0 : Current Connect Status
Bit 1 : Port Enabled/Disabled
Bit 2 : Reserved
Bit 3 : Over-current
Bit 4 : Reset
Bit 5-8 : Port Link State
Bit 9 : Port Power
Bit 10-12 : Negotiated speed
Bit 13-15 : Reserved

USB3.0：wPortChange

Bit 0 : Connect Status Change
Bit 1-2 : Reserved
Bit 3 : Over-Current Indicator Change
Bit 4 : Reset Change
Bit 5 : BH Reset Change
Bit 6 : Port Link State Change
Bit 7 : Port Config Error
Bit 8-15 : Reserved

USB2.0：wPortStatus

Bit 0 : Current Connect Status
Bit 1 : Port Enabled/Disabled
Bit 2 : Suspend
Bit 3 : Over-current
Bit 4 : Reset
Bit 5-7 : Reserved
Bit 8 : Port Power
Bit 9 : Low-Speed Device Attached
Bit 10 : High-Speed Device Attached
Bit 11 : Port Test Mode
Bit 12 : Port Indicator Control
Bit 13-15 : Reserved

USB2.0：wPortChange

Bit 0 : Connect Status Change
Bit 1 : Port Enable/Disable Change
Bit 2 : Suspend Change
Bit 3 : Over-Current Indicator Change
Bit 4 : Reset Change
Bit 5-15 : Reserved

違いを明確化するために色付けしてみた。青字はUSB3.0で拡張あるいは無効になったフィールド、赤字が互換性の無いフィールド。この違いはUSB3.0でリンク層が追加され、リンク層制御をハブクラスで行わなければならないことに起因すると考えられます。

2011年2月11日

GRUBが立ち上がらなくなったときの対応(Gentoo Linux インストールCD)

現在、Windows 7/Gentoo Linux/NetBSDという3つのOSをPCにインストールしていて、ブートローダにGRUBを利用しています。OSの再インストール等を実施していると稀にMBRが書き換えられてGRUBが立ち上がらないあるいはOSが何も立ち上がらないという状況になります。そんなときの対処方法に関して記載します。

僕はいつも、Gentoo Linuxをインストールした際に利用したインストールCDを利用してます。基本的な流れとしては、

インストールCDから起動
Gentoo Linuxのパーティションをマウント、chroot
GRUBの再設定

という流れです。以下がインストールCD起動からGRUB再設定までに必要なコマンドです。

   # swapon /dev/sda2
   # mount /dev/sda3 /mnt/gentoo
   # mount /dev/sda1 /mnt/gentoo/boot
   # cd /mnt/gentoo
   # mount -t proc none /mnt/gentoo/proc
   # mount -o bind /dev /mnt/gentoo/dev
   # chroot /mnt/gentoo /bin/bash
   # grub

   grub> root (hd0, 0)
   grub> setup (hd0)

以上でMBRへのGRUB最設定が完了です。上記の方法はKnoppix等のLiveCDでもつかえるはずです。

2011年1月19日

とある場所で行われた会話

某メーカー新入社員：『いったい僕は、誰にために仕事をしているんだろう』

評論家：『お客様のためさ。それがメーカーが追及すべき唯一のことだから』
経営学者：『上司のために仕事するんだ。組織として機能するために必要だ』
哲学者気取り：『自分のためにやりなよ。幸せを追及しないと、人生は無意味だよ』

某メーカー新入社員：『あぁ…、いったい僕はどうすればいいんだ』

通りすがりの英国人：『Take it easy. Que sera sera』

USB3.0ホストチップ（xHCI）の調査

USB3.0ホスト（xHCI）のチップってどんなのが市場に出ているのだろう？
ってことで、調べてみた。（2010/01/18時点の情報）

ルネサスエレクトロニクス
μPD720200 ： PCIe Gen2 x 1、2ポート、
μPD720200A ： μPD720200に対して消費電力低減

FLESCO LOGIC
FL1009 ： PCIe Gen1 x 1、2ポート
FL1010 ： PCIe Gen2 x 1、2ポート

VIA Labs
VL800 ： 4ポート

チップだと、これだけ。IPだとどうなんだろう。
PLDA ：ホスト、デバイス両方のIP
Arasan ：同じくホスト、デバイス両方のIP

なお、ルネサスエレクトロニクスもIPを持っているらしい。
個人でこんなこと調べてどうなるわけでもないけど、念のため。

2011年1月9日

OProfileで取得可能なイベント

先日OProfileを初めて触ったが、どのようなイベントを取得できるのか調べてみた。OProfileで取得できるイベント種別は利用しているCPUにより異なる。
詳細はOProfileのドキュメントに記載されている『Event type reference』に記載されている。また、opcontrol コマンドの --list-events オプションで確認可能（あるいは ophelp コマンドでも確認できる）。私の環境だと以下のようになった。

% opcontrol --list-events
oprofile: available events for CPU type "Intel Architectural Perfmon"

See Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3B (Document 253669) Chapter 18 for architectural perfmon events
This is a limited set of fallback events because oprofile doesn't know your CPU
CPU_CLK_UNHALTED: (counter: all)
   Clock cycles when not halted (min count: 6000)
INST_RETIRED: (counter: all)
   number of instructions retired (min count: 6000)
LLC_MISSES: (counter: all)
   Last level cache demand requests from this core that missed the LLC (min count: 6000)
   Unit masks (default 0x41)
   ----------
   0x41: No unit mask
LLC_REFS: (counter: all)
   Last level cache demand requests from this core (min count: 6000)
   Unit masks (default 0x4f)
   ----------
   0x4f: No unit mask
BR_INST_RETIRED: (counter: all)
   number of branch instructions retired (min count: 500)
BR_MISS_PRED_RETIRED: (counter: all)
   number of mispredicted branches retired (precise) (min count: 500)

私が使っているCPU（Intel Core i5-560M）の場合だと、他のCPUに比べて取得できるイベント種別が少ない模様。

2011年1月3日

OProfileを使ってみる

LinuxカーネルのプロファイラであるOProfileを使ってみることにする。
始めて利用するので、今回はセットアップと超簡単な使い方のみ試してみる。

今回試した環境は、

システムは Gentoo Linux。カーネルバージョンは 2.6.36-gentoo-r6（Linux-2.6.36にGentoo向けパッチが当たっている）
PCは、ThinkPad X201を利用。CPUはIntel Core i5-540M

まずは環境のセットアップ。OProfileを利用するためにはLinuxカーネルでのサポートと専用ユーザランドのインストールが必要。Linuxカーネルのサポートは、CONFIG_OPROFILE と CONFIG_HAVE_OPROFILE のサポートがあれば最低限OKらしい。続いてユーザランドのインストール。Portageを使ってインストールする

  $ emerge dev-util/oprofile

インストールしたらOProfileで簡単なプロファイルを行ってみる。

  $ sudo opcontrol --vmlinux=/usr/src/linux/vmlinux
  $ sudo opcontrol --start
  # プロファイルをとる任意のプログラムを実行
  $ sudo opcontrol --stop

以上でプログラムのトレース取得は成功。
なお、opcontrolで各種処理を行うにはroot権限が必要な模様。そのため、sudoコマンドを用いて行っている。

続いてプロファイル結果の表示

  $ opreport # 全体の結果を表示
  $ opreport (プログラム名) # 該当するプログラムのみ
  $ opreport -l (プログラム名) # ??
  $ opreport -c (プログラム名) # ??

opreportでの各種コマンドラインオプションの詳細は今回は未確認。今日のところはこれで終了。もっと詳細を後日見ていきたいと思う。

参考ページ
OProfile : http://oprofile.sourceforge.net/news/
OProfile Documents : http://oprofile.sourceforge.net/docs/

備考
OProfileのサポートCPUを見るとCore-i5は十分なサポートされていないのか？？この点も後日確認したいと思う。
またOProfileの実行に伴い、/root/.oprofile/ ディレクトリが作成されて設定が保持される。
さらに実行時の各種詳細情報は /var/lib/oprofile/ ディレクトリ配下に記憶さえる模様。

登録: 投稿 (Atom)