
Ubuntu日本語フォーラム
ログインしていません。
ページ: 1
Ubuntu日本語フォーラムにおいて、無線で接続できないという質問を多く見かけます。
単に設定の問題であれば、個別に質問に答えていく対応でよいと思うのですが、
USB無線LAN子機が認識されておらず、その解決方法がソースを取得して
VendorIDとProductIDをソースコードに追加してビルド、導入というケースを見かけます。
このような対応は初心者には進めにくいですし、初心者に改善要望を求めるのも酷です。
スキルのある人は、改善要望を出さずに自分でソースビルドすることで対応してしまう
ので改善要求をあげない場合が多いと思われます。
そこでこの様なケースを収集して、Ubuntu Japanese Kaizen Projectへ要望を
提出するためのトピックを立てるという方法を考えました。
○今のところ考えているは、以下のような要領。
・Lucidの最初のメンテナンスリリースまたはMaverickへ反映される事を目指す
・開始はLucidリリース後、適切な時期
・収集期間はとりあえず、2週間ぐらい。(あまり長いと、ダレそうなので)
・半年に一致度くらいの頻度で周期的に行ってもよいかもしれないです。
・可能な限り具体的にカーネルソースツリーのドのファイルにどういう修正をするかまで調べる。
(これはそこまでやっておけば対応していただける可能性が高くなるであろうという理由からです。)
例えばlinux_2.6.32-18.27.diff.gzの中を調べると下記のような記述があり、
Ubuntu独自のパッチもありなのだと思います。
(もちろん最上流で反映されるのが望ましいと思っています。)
--- linux-2.6.32.orig/drivers/staging/rt2870/2870_main_dev.c +++ linux-2.6.32/drivers/staging/rt2870/2870_main_dev.c @@ -142,6 +142,7 @@ { USB_DEVICE(0x7392, 0x7717) }, /* Edimax */ { USB_DEVICE(0x1EDA, 0x2310) }, /* AirTies 3070 */ { USB_DEVICE(0x1737, 0x0077) }, /* Linksys WUSB54GC-EU v3 */ + { USB_DEVICE(0x0411, 0x015D) }, /* Buffalo Airstation WLI-UC-GN */ { } /* Terminating entry */ };
[Ubuntu Japan Teamの方々へ]
皆さまからみて、開始の適切な時期や
要望として出た場合に採用される可能性を高くするためのポイントがあれば
ご教示いただけますでしょうか。
○収集の方法
「ネットワーク環境」または「ハードウェア」のカテゴリに
トピックを作成する方法がよいのではないかと思います。
(深い考えがあるわけではなく、とりあえずの提案です。)
○問題点や課題として上がりそうな事項
・ハードウェアサポート情報Wikiとの関係
情報が散在するという問題がありそうです。
収集期間が終わった後速やかに反映するということでどうでしょうか。
・情報の確認方法
対象のハードを持っていないと確認できないという問題があります。
間違ったドライバのソースにVendorIDとProductIDを使いしてしまうと
ハングアップする可能性もありそうです。
対処方法は思いついていません。
以上、みなさまに意見いただければと存じます。
オフライン
その問題のパッチが入った経緯が https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441990 にあるので、とりあえず読むといいんではないでしょうか。
最終的にそろえるべき内容をリストしてみます。が、最重要項目は、
・報告が増えて混沌とする前に、うまく以下を満たせる方法を考える;)
ということです(つまり、まだ報告しないでくださいな、という)。
報告する方に頑張ってもらうしかないもの:
・問題のデバイスの正式な製品名と、*購入日*と、メーカーページのURL
・問題のデバイスの接続前後のdmesg
・問題のデバイスのlsusb -v相当部
・DeviceIDを足さない状態ではどうなるのか(認識されないのか、見た目認識されるけどつながらないのか、見た目認識されてつながるけど速度が出ないのか)を明確にする。
LPに登録したりといった「Ubuntuに含めてもらう」人が頑張るもの:
・1bug1デバイス1パッチ。ムリなら、1bug1ドライバ。
・ubuntu kernelのgit先端に含まれていないかチェックする
・LKML(のLinusツリーやstaging)に同じパッチがないかチェックして、ない場合はLKMLか#ubuntu-kernelで相談してくる
あたりでしょうか。ちゃんと考えていないのでまだヌケがあるかもしれません。後半のいかにも一般人お断りワールドはこっちでやります。
5/中旬からmaverickの開発が立ち上がるので、それまでは余裕があります。まずは、集めるべき情報をどうやれば効率よく集められるのか、というのを考える必要がありますが……。
これは、10.04リリースされてからやった方がいいような気がしました。
10.04で試す -> LKML的なgitツリーでチェック -> 取りまとめる -> LPに登録して場合によりLKML(canonical.comメールアドレス持ちにまとめてもらう方がいいかも)、という展望になるかなと思います。
まずは、「こういう情報が欲しいです」という取得・確認手順をwikiにまとめてもらうのが良さそうな気がします。
※必要な操作のスクリプト化は不可、という前提でお願いします。スクリプトにしないと取得できないよ、というケースでは、前半部分の必須要件が満たされる保証がないので。
オフライン
hito さん
とりあえず、
集めるべき情報をどうやれば効率よく集められるのか、というのを考える
ことも開始するのは10.04リリースされて、状態が落ち着いてからということで了解致しました。
5月の初旬くらいに再度このトピックに相談の投稿します。
ーーーーーーーーーーーーーーーーーーーーーーーーーーー
LKLMとはLinux Kernel Mailing List の略でしょうか。
(すいませんそんなこともわかりません。)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441990
読んでみました。
このバグに関する流れではLKLMは出てこなかったようです。
http://kernel.ubuntu.com/~kernel-ppa/mainline/の下を試すのが基本のようでした。
#8でJohnFluxさんがパッチを [email protected] へ送ってからは非常に展開が早いですね。
#8が 2010-03-25で 2010-03-26にはFix Committed、2010-03-27にはFix Released です。
Stefan Baderがどのような判断をしてLKLMでの修正ではなく、
Ubuntuでの修正にしたのかは記述がありませんでした。
どういう判断をしたのか興味があるところです。(私が関わることはないのですが。)
オフライン
#3で URLのすぐ後ろに日本語を続けておかしくなった部分の訂正です。
http://kernel.ubuntu.com/~kernel-ppa/ma … �した。
↓
http://kernel.ubuntu.com/~kernel-ppa/mainline/ の下を試すのが基本のようでした。
オフライン
MidSpecLowLoad による投稿:
#8でJohnFluxさんがパッチを [email protected] へ送ってからは非常に展開が早いですね。
#8が 2010-03-25で 2010-03-26にはFix Committed、2010-03-27にはFix Released です。
Stefan Baderがどのような判断をしてLKLMでの修正ではなく、
Ubuntuでの修正にしたのかは記述がありませんでした。
どういう判断をしたのか興味があるところです。(私が関わることはないのですが。)
基本路線としては、
・可能ならUpstream(この場合LKML)
・ダメならUbuntu独自
となります(この法則を把握していれば判断の基準はおおむね分かるかと)。
Ubuntu KernelはDebian由来のものではないので、UpstreamでダメならUbuntu、というルールとなっています(Debian由来のものであれば、UpstreamでダメならDebian、さらにダメならUbuntu独自)。
このケースでは、
・Lucidで使う2.6.32はすでにLKML(略語の正体はお考えのもので合っています)的にはリリースされている
・2.6.32系のMaintenance ReleaseはLucidのFreezeには間に合わない
というあたりでUbuntu Kernelでmergeするという判断が下されているはずです。
オフライン
hitoさん
ご丁寧な解説ありがとうございます。
Stefan Baderさんの判断については、なんとなくの興味だけだったのですが
お忙しいところお手間を掛けてしまい申し訳ありませんでした。
(しかし、非常に勉強になりました。)
訂正
MidSpecLowLoad による投稿:
http://kernel.ubuntu.com/~kernel-ppa/mainline/ の下を試すのが基本のようでした。
「基本」は何となく使ってしまったもので、事実に基づいた表現ではりません。
bug #441990 の前半のやりとりで
http://kernel.ubuntu.com/~kernel-ppa/mainline/ 以下を
参照していたということだけが事実です。
オフライン
MidSpecLowLoad による投稿:
「基本」は何となく使ってしまったもので、事実に基づいた表現ではりません。
bug #441990 の前半のやりとりで
http://kernel.ubuntu.com/~kernel-ppa/mainline/ 以下を
参照していたということだけが事実です。
おおむね合っています。kernel-ppaのmainline buildは、LKMLのカーネル(これをmainlineと呼び習わします)をビルドしているもので、これを入れることでLKMLのLinusツリーで問題が再現するかどうかがチェックできます。
オフライン
Maverickの開発も始まったようですし、そろそろ再開しても良いのではないかと思い、投稿いたしました。
報告する側ががんばる部分について、少しまとめてみました。
(情報を集めたあとの、"DeviceID"の追加のワークアラウンドについては記載していないです。)
ご意見をいただければ幸いです。
hitoさん による投稿:
報告する方に頑張ってもらうしかないもの:
・問題のデバイスの正式な製品名と、*購入日*と、メーカーページのURL
・問題のデバイスの接続前後のdmesg
・問題のデバイスのlsusb -v相当部
・DeviceIDを足さない状態ではどうなるのか(認識されないのか、見た目認識されるけどつながらないのか、見た目認識されてつながるけど速度が出ないのか)を明確にする。
以下、lsusbで出力されるidVendor:idProduct(-vをつけないlsusbの出力で"ID"として表示されるもの)を便宜上"DeviceID"とよびます。
とりあえず、集める情報の枠を作ってサンプルを書き込んでみました。
(手持ちがGW-USMicroNしかないので貧弱ですが。)
https://wiki.ubuntulinux.jp/MidSpecLowLoad
一番上の表を
"https://wiki.ubuntulinux.jp/HardwareSupport/UsbWirelessLanClinet"
あたりにつくり、その下に
"https://wiki.ubuntulinux.jp/HardwareSupport/UsbWirelessLanClinet/[DeviceID]"
という形で機種ごとのページを作っていくことを考えています。
ずっと続けていくのであれば、機器ごとページはUbuntuのバージョンごとにあったほうがいいかも知れません。
以下、若干順番が前後しますが冒頭で引用した部分の詳細について。
・問題のデバイスの正式な製品名と、*購入日*と、メーカーページのURL
「*購入日*」が必要な理由は製品の型番が同じでも製造時期によって採用チップが異なる場合があるためだと思うのですが、"DeviceID"を明示しておけばそれで代替できる気がします。
購入日はIDの目安になる気がしますが、それほど結びつきは強くないと思われます。
またたたき台のように"DeviceID"をキーにすると、購入日だけが"DeviceID"に従属せず、すわりが悪いのも気になります。
しかし、これから購入する際にUbuntuで使えるかどうかの目安になるとおもわれるのでやはり必要でしょうか。
(当該IDの製造時期のFrom-Toがわかると良いのですが。)
・DeviceIDを足さない状態ではどうなるのか(認識されないのか、見た目認識されるけどつながらないのか、見た目認識されてつながるけど速度が出ないのか)を明確にする。
機器の認識有無はiwconfigでよいと思います。(認識されていない場合は出力がありません、これはドライバをmvして確認しました。)
接続の速度も"Bit Rate=135 Mb/s"のように表示されます。
(Blacklistで認識をやめた場合にどうなるかが若干気になりますが、すいません書き方がわからず試していません)
(サンプルは https://wiki.ubuntulinux.jp/MidSpecLowLoad にあります。)
・問題のデバイスの接続前後のdmesg
私の環境ではdmesgは770行ほど出力がありました。
全行を掲載するのはちょっとためらわれます。
認識された場合に、その前後を数行を含めて掲載するのが妥当かと思います。
(サンプルは https://wiki.ubuntulinux.jp/MidSpecLowLoad にあります。)
・問題のデバイスのlsusb -v相当部
GW-USMicroNの場合はsudoをつけて実行するとチップの製造ベンダーの名称が"iManufacturer"のところに出力されました。
sudoをつけることは重要だと思いました。
$ sudo lsusb -v -d 1d6b:0001 Bus 002 Device 002: ID 2019:ed14 PLANEX Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x2019 PLANEX idProduct 0xed14 bcdDevice 1.01 iManufacturer 1 Ralink iProduct 2 802.11 n WLAN iSerial 3 1.0 bNumConfigurations 1
(出力の全量は https://wiki.ubuntulinux.jp/MidSpecLowLoad にあります。)
オフライン
MidSpecLowLoad による投稿:
・問題のデバイスの正式な製品名と、*購入日*と、メーカーページのURL
「*購入日*」が必要な理由は製品の型番が同じでも製造時期によって採用チップが異なる場合があるためだと思うのですが、"DeviceID"を明示しておけばそれで代替できる気がします。
購入日はIDの目安になる気がしますが、それほど結びつきは強くないと思われます。
またたたき台のように"DeviceID"をキーにすると、購入日だけが"DeviceID"に従属せず、すわりが悪いのも気になります。
しかし、これから購入する際にUbuntuで使えるかどうかの目安になるとおもわれるのでやはり必要でしょうか。
(当該IDの製造時期のFrom-Toがわかると良いのですが。)
そのデバイスを入手したいと思った人にとって非常に役に立つので、できるだけあった方が良いと思います。
・DeviceIDを足さない状態ではどうなるのか(認識されないのか、見た目認識されるけどつながらないのか、見た目認識されてつながるけど速度が出ないのか)を明確にする。
機器の認識有無はiwconfigでよいと思います。(認識されていない場合は出力がありません、これはドライバをmvして確認しました。)
接続の速度も"Bit Rate=135 Mb/s"のように表示されます。
(Blacklistで認識をやめた場合にどうなるかが若干気になりますが、すいません書き方がわからず試していません)
(サンプルは https://wiki.ubuntulinux.jp/MidSpecLowLoad にあります。)
うまく動いていないケースでは、iwconfigをふくめ、あらゆるコマンドの出力は嘘を吐くことがあるので避けるほうがいいです。
特に、実際に使って速度が出るのか、つながるのか、という情報はコマンドでは取れません。125Mb/sとか出てるけど実際には4b/sだよぅ、みたいなことはよくあるので。
・問題のデバイスの接続前後のdmesg
私の環境ではdmesgは770行ほど出力がありました。
全行を掲載するのはちょっとためらわれます。
認識された場合に、その前後を数行を含めて掲載するのが妥当かと思います。
(サンプルは https://wiki.ubuntulinux.jp/MidSpecLowLoad にあります。)
USBものなら、起動後に装着してもらって「dmesg | diff -u /var/log/dmesg - 」するのがいいと思います。もっといい方法がありそうなので、それでもいいのですが。
内蔵品はがんばって探してもらうしかないのですが、漏れも起こりえるのが悩ましいところです(たぶんdmesg全文を貼ってもらうよりは、探してもらって、デバイスの所有者が見落としたものはあきらめる方法の方が筋がいい)。
オフライン
そのデバイスを入手したいと思った人にとって非常に役に立つので、できるだけあった方が良いと思います。
それでは欄を設けておいて、所有している人が自分の購入時期を追加するというのでよろしいでしょうか。
(一つのIDの購入時期に欄に複数の日付が記載されることがある。)
うまく動いていないケースでは、iwconfigをふくめ、あらゆるコマンドの出力は嘘を吐くことがあるので避けるほうがいいです。
特に、実際に使って速度が出るのか、つながるのか、という情報はコマンドでは取れません。125Mb/sとか出てるけど実際には4b/sだよぅ、みたいなことはよくあるので。
う、そうなんですか。
そうすると
・DeviceIDを足さない状態ではどうなるのか(認識されないのか、見た目認識されるけどつながらないのか、見た目認識されてつながるけど速度が出ないのか)を明確にする。
を確認する方法が分かりません。どうすべきでしょうか。
私としては方法をご存知の方のご教示を待つより手立てがないです。
ちなみにhitoさんのおっしゃっている"実際には4b/s"とiwconfigのBit Rateは比較可能なものなのでしょうか。
iwconfigの"Bit Rate=135 Mb/s"の表示は、私の想像ですが、
その速度が出るということではなく、接続に使っている規格と電波状況できまるAPとの約束事見たいなもので、
実測した通信速度と比較できるようなものではないと思っているのですが。
(自分で書いていて意味がよく分かりませんねこの記述は。要は常に"規格上の速度" > "実測速度" で状況によってはその開き方が大きくなるので、実測から使用している規格を推定することにあまり意味がないのではないかと。)
USBものなら、起動後に装着してもらって「dmesg | diff -u /var/log/dmesg - 」するのがいいと思います。もっといい方法がありそうなので、それでもいいのですが。
内蔵品はがんばって探してもらうしかないのですが、漏れも起こりえるのが悩ましいところです(たぶんdmesg全文を貼ってもらうよりは、探してもらって、デバイスの所有者が見落としたものはあきらめる方法の方が筋がいい)。
"dmesg | diff -u /var/log/dmesg - "を試してみました。
ドライバをmvして認識できなくした場合と、正常認識できる場合の両方を張り付けました。
( https://wiki.ubuntulinux.jp/MidSpecLowLoad を修正)
内蔵品もノートの場合は割合ON/OFFできるスイッチがついているものが多い気がします。
(私はノートPCを持っていないのですが...)
スイッチがないものはどうにもならないですね。
オフライン
ページ: 1