kojiです。

CuBoxのarch linux上でkernel3.8.13+rtパッチだと、当方の環境でエラーが出ていました。（そのため3.8.10+rtで使っていました）

エラーの内容は、何曲か演奏するとcannot submit urb (err = -18)が出て、mpdが停止するというものでした。

　その後、先週末にリリースされたrt12で試してみたところ、当方の環境では上記の問題が解決しているようです。
　まだ、このカーネルでの起動での演奏２時間くらいですが、エラーが出ることもなく、鳴り続けています。

　取り急ぎ、報告まで

上記のメッセージを書いて、10分くらいしてから、エラーが出て止まりました。
　dmsegでみると、以下のエラーが延々と続いています
[ 4179.623101] cannot submit urb (err = -18)
[ 4179.625804] cannot submit urb (err = -18)

　検証不十分なままの書き込みすみませんでした。

　しばらくは、3.8.10+rtで様子見モードでいきたいと思います。

同じく3.8.13-rt12ですが、カーネルビルド直後からの運用にて現在まで問題なく動いております。Cubox Proを使用中です。ご報告まで。

top - 07:59:07 up 1 day, 21 min, 1 user, load average: 0.41, 0.43, 0.48
Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.7 us, 9.1 sy, 0.0 ni, 85.6 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
KiB Mem: 2073492 total, 215104 used, 1858388 free, 15712 buffers

twl

twlさん、こんにちは

貴重な動作報告情報どうもありがとうございます。
3.8.13-rt12で一日以上動いているようですね。

　私の方では、みみず工房のWebsiteの「cubox カーネル3.8+RTPatchのビルド方法」のアーティクルの中で説明して頂いてる方法で3.8.4くらいから3.8.10まで問題なく動作してきました。
　その後、いじる時間をとれず、久しぶりに3.8.13の前のパッチ辺りでビルドしたところ、前のメッセージのようなエラーが出るようになった次第です。

　configは上記のアーティクルで紹介されているものを使ってビルドしていますが、twlさんの方で動作しているカーネルの
configのポイント等をご教示頂けるとありがたいです。


koji

kojiさん、こんにちは

同じくarch linuxでの3.8.x+rtxでの状況報告です。

3.8.9+rt4
3.8.10+rt6
3.8.11+rt8
は全く問題ありませんでした。3.8.11+rt8は数日間の連続再生も試しました。
3.8.13になってから様子がおかしくなって
3.8.13+rt9 →　数分で cannot submit urb(err = -18)
3.8.13+rt10 →　ほぼOKだが、数時間～半日くらいでやはり同じエラー
3.8.13+rt11 →　このバージョンでは上記エラーは出ていませんが丸1日くらいしか連続再生テストはしていません。
3.8.13+rt12 →　丸一日くらい再生させると上記のエラーが出たり出なかったり。

と微妙な状態です。
.configは、yoさんの3.8.xのカーネルビルドの記事＋archスレの情報でcontrol groupを生かした状態で、3.8.xずっと共通でやっています。3.8.13で変更すべき箇所があれば自分も知りたいです。

kojiさん、fHiroさん、今晩は。3.8.13-rt12のbuildに使用した.configの件ですが、お返事が遅れ失礼しました。

kojiさん wrote:

>　configは上記のアーティクルで紹介されているものを使ってビルドしていますが、twlさんの方で動作しているカーネルの
> configのポイント等をご教示頂けるとありがたいです。

fHiroさん wrote:

> .configは、yoさんの3.8.xのカーネルビルドの記事＋archスレの情報でcontrol groupを生かした状態で、3.8.xずっと共通でやっています。
> 3.8.13で変更すべき箇所があれば自分も知りたいです。

不思議ですね。私も皆さん同様、yoさんが4/19/13に書かれた「cubox カーネル3.8+RTPatchのビルド方法」の指示に従った.configファイルをベースにbuildしているのですが、特に内容を意図的に変更した記憶はありません。ただ、3.8.10から3.8.11のbuildに移行した際、一度だけ、make menuconfigの途中で設定の不備があると叱られ、その部分を適当に変更、結果として問題なく3.8.11のbuildができた記憶があります。その時にdiffを保存しておけばよかったのですが、今はどこを修正あるいは追加したか記憶に残っておりません。申し訳ありません。

一応、現行の3.8.13-rt12build時の小生の.configを以下のURLに置きましたので、ご照覧下さい。お役に立てれば幸いです。

　　http://lydia.concorde.gr.jp/luke/CFG3813" target="_blank">http://lydia.concorde.gr.jp/luke/CFG3813　　(なお、このファイルは一ヶ月後には消去いたします。)

ところで、皆さんが問題にされているエラーはurb関連のもののようですね。3.6.9カーネルでも一時問題になったようですが、このエラーは使用しているUSBデバイスに依存する可能性はないのでしょうか。私はDDCとしてAmanero Combo384を常用していますが、このDDCでのトラブルは経験しておりません。他にMytek USB2.0およびHiFace Evoを使うことはありますが、いずれのドライバーモジュールでも現行のカーネルを含め、urbエラーによる音切れの経験はありません。ただし使用時間は数時間に限られます。

最後に、現在私の使用しているMPDはJurgen Kramerさんのソース(https://github.com/lintweaker/mpd-dsd" target="_blank">https://github.com/lintweaker/mpd-dsd)をコンパイルしたものであることを追加しておきます。もしかしたらこのMPDバイナリの違いがエラーの有無になっている可能性も否定はできないですね。

皆様のお役に立てれば幸いです。

twl

twlさん、ありがとうございます。
アップしていただいた.configをチェックしてみましたが、cgroupsがらみのところ以外は同じでした。
twlさんが述べられている通りUSBデバイス&ドライバに依存する問題の可能性が強いと思います。3.8.9+rt以前のdmaバッファを使い切ってしまうのと似ていますが、でも症状的には自分の環境ではずっと軽いです。(usbデバイスはx-ddc）

fHIroさん、twlさん　kojiです。

　まとめレス失礼します。

　fHIroさんのところでも、私のところと同じエラーメッセージのようで、同様の症状の方が他にもおられることが確認でき、貴重な情報ありがとうございました。また、これまでのカネールのバージョンごとの検証結果も参考になります。私のところで、使っているのは、3.8.10-rt6です。
　また、機会があれば、3.8.11+rt8も試してみたいと思います。

　twlさん、早速、configのご紹介ありがとうございました。
私の方でも、diffをとってみましたが、fHIroさんご指摘のcgroupsがらみくらいでした。

　でも、一応検証をしてみようと思い、ご紹介頂いたconfigでmakeしたカーネルを入れてみました。
　ところが、やはり１時間少しで、cannot submit urb (err = -18)のエラーが出て演奏が止まってしまいます。

　fHIroさんの書かれている通り、機種依存による部分が大きいのかも分かりませんね。

参考までに、当方の環境を記しておきますと、
CuBox→M2Tech hiface two pro→Lux DAC-100
という構成です。

aplay -lの結果は、
**** List of PLAYBACK Hardware Devices ****
card 0: M20 [M2Tech USB Audio 2.0], device 0: USB Audio [USB Audio]
Subdevices: 0/1
と、認識はされているようですが…

　引き続き、様子をみていきたいと思います。

twlです。皆様の問題解決にはお役に立てませんでしたが、当座の問題点についてちょっとまとめてみます。

1. urbエラーの発生に関しUSBデバイスの機種依存性があるかもしれない。

fHiroさんはX-DDC、kojiさんはHIFACE TWO-Proを使用されています。お二人ともDAC接続にはRCAケーブルによるS/PDIF使用ということでよろしいでしょうか。

仮にそうであれば、私の場合はDDCからI2S接続で自作キットのBuffalo-IIIに接続していますので、I2SとS/PDIF接続の違いがエラー発生に関連する可能性も示唆されます。

もっとも、X-DDCの場合はHDMIケーブルでのI2S接続が可能なようですので、もしこの環境でエラーが生じているのであれば、私の推測は間違っているかもしれません。

2. 音源のソースはNASかあるいはHDDなどCubox直結のUSBメディアか。

urb関連のエラーをググってみると、HDDなどのUSBデバイス経由の音源であれば、そのデバイスがエラーの原因となる可能性が指摘されています。私の場合にはNASでもUSB HDDでもどちらの音源でもエラーは発生していませんが、間にUSBハブを介在させるとエラーが消えた、という不思議な？報告もあります。ちなみにNASはSynology DiskStation (DS106e) 接続の1.0T e-SATAドライブを使用しております。

以上、ご検討いただれば幸いです。

twl

twlさん、ありがとうございます。

とりあえず私の環境を挙げます。
・Cubox->X-DDC->同軸S/PDIF->DAC
・音源はNAS(ReadyNAS Ultra)に置き、Gigabit hub経由の有線接続
・データ形式はほとんどがAlac(apple lossless),44.1kh
・mpdは5月半ばのgit版、あるいは1.74安定版
　どちらもそれぞれに対応するyanさんpatchでrt化
--------------------------------
現在は、3.8.13+rt12で常時再生させて様子見です。
3.8.13+rt12にしてから例のエラーが出たのは、ログを見てもまだ1度しかないので、そのまま使っても差し支えない程度ではあります。
kojiさんと比べると症状は軽いようです。

また、このエラーが出ても以前のdmaバッファが足りなくなる問題の時と比べると、OS自体は健全で、ssh接続も普通にできる状態なので扱いやすいです。dma問題の時はシステム自体がくさってフリーズに近い状態でした。
ただあくまでもこれも自分の環境だけの話かも知れません。

twlさん、fHIroさん、kojiです。

■fHIroさんの書き込みを参考に、3.8.11+rt8のカーネルをビルドして、昨晩からずっとリピート再生した状態で出て、先程帰ってみたところ、18時間近く問題なく再生できています。
・uname -a
Linux alarmcubox 3.8.11-rt8_CuboxAudioRTuned #1 PREEMPT RT（略）

・top - 19:23:45 up 17:41（略）

　どうもご教示ありがとうございました。

■twlさん、どうも問題点の整理ありがとうございます。

>1. urbエラーの発生に関しUSBデバイスの機種依存性があるかもしれない。
>fHiroさんはX-DDC、kojiさんはHIFACE TWO-Proを使用されています。お二人ともDAC接続>にはRCAケーブルによるS/PDIF使用ということでよろしいでしょうか。

　はい、当方ではDDC-DAC間は同軸ケーブル（Beldenのケーブルで自作）による接続をしています。


>2. 音源のソースはNASかあるいはHDDなどCubox直結のUSBメディアか。

　こちらは、Debianを入れたサーバーに置いてあるflacファイルとaacファイルを、nfsでマウントする形で使っています。
　これまで、Linuxマシン同士の場合は（バックアップ用途だったので）rsync、Windowsマシンとの接続ではsambaを使っていましたので、nfsによるマウントはVoyage MPDをAtomマシンに導入してから使い始めたところです。
　なので、当初のfstabは、マウント元とマウント先を記述しただけのものでした。それでも、Atomマシンの方では問題なく再生できていました。

　その後、Cuboxを購入して、yoさんの雛祭りバージョンを使わせて頂いたのですが、当初、cannot submit urb (err = -27)（この時は、-18ではなく、-27でした）のエラーが出てダウンしました。
　最初はUSB関係なのでハードウェア的な問題かとにらんで、ケーブルを変えたり、接続端子を変えてみたり、ハブを介してみたりと色々とやってみましたが、症状は変わりませんでした。
　それで、ダメ元で、fstabにrsize=8192のオプションを加えたところ、ピタッとエラーが止まり、以降、3.8.13以前までは使えるようになっていました。

　当方の環境については、上記のような次第です。
　一度、USBメモリー等にファイルをコピーしてみて、マウントする等、問題を切り分けられるようにしてみたいと思います。

　引き続き、よろしくお願いします。

fHiroさん、kojiさん、S/PDIFでの接続環境の情報ありがとうございました。お二人とも音源はNASを利用されていることから、HDDなどのUSBデバイスがらみのエラーではないようですね。

S/PDIFの環境がこのエラーに関与しているのかどうか検証したく、先程mpd稼働のままでUSB接続をAmaneroからHiface Evoに変更、そこからS/PDIFでBuffalo III DACに接続しましたが、皆さんのエラーが再現されるかどうか、これから明日ぐらいまで様子をみて見ます。接続変更から約30分後の現在では問題ありません。

fHiroさんに関してはこのsubmit_urbエラーの影響は極めて小さいようですね。私の使用しているMPDにはyanさんpatchはあてていないのですが、おそらくこの違いによるエラーではないだろうと思われます。

kojiさんは

> それで、ダメ元で、fstabにrsize=8192のオプションを加えたところ、ピタッとエラーが止まり、
> 以降、3.8.13以前までは使えるようになっていました。

とありますが、私のfstabではyoさんの指示に従い以下にお示しするようにrsize=130048となっています。NASのマウント形式はnfsではなくcifsでありlinuxとWindowsの違いはありますが、再度ダメ元で試されてはいかがでしょうか。

//192.168.0.99/satashare/DSD /dsd128 cifs username=xxxxx,password=xxxxx,uid=mpd,file_mode=0666,dir_mode=0766,iocharset=utf8,rsize=130048,wsize=4096,cache=strict,sec=ntlmv2 0 0

十分には理解していないのですが、submit_urbエラーはUSBを介して送受信されるデータの順番待ちがうまくいかない場合に起きるようですね。 データのqueueがいっぱいになっていても充足されていなくとも起きるようです。もしかしたらrsizeの設定がこの部分に関与しているかもしれず、申し上げた次第です。

twl

twlです。

> S/PDIFの環境がこのエラーに関与しているのかどうか検証したく、-snip- DACに接続しましたが、
> 皆さんのエラーが再現されるかどうか、これから明日ぐらいまで様子をみて見ます。

と申し上げましたが、S/PDIF接続から約９時間後の現在、mpd接続に関するエラーは生じていません。短絡的な結論ですがS/PDIFとsubmit_urbエラーの関連はなさそうと思われます。やはり、このエラーについては説明の困難ななんらかの機種依存性があるのかもしれませんね。

twl

twlさん、fHiroさん、kojiです。

　お二人から、3.8.13+r12で問題なく動作されている報告があり、当方の環境を見直してみようと思いました。

twlさんから
>とありますが、私のfstabではyoさんの指示に従い以下にお示しするようにrsize=130048となっています。NASのマウント形式はnfsではなくcifsでありlinuxとWindowsの違いはありますが、再度ダメ元で試されてはいかがでしょうか。

とのサジェスチョンがあり、fstab周りをいじってみました。

　Googleで、nfsでマウンとする際のオプションの最適値などを調べてみたのですが、ネットワークの速度、HDDのキャッシュサイズ等が関係するようで、様々な記述がありました。（ちなみに、現在のrsize=8192も、man fstabの記述を参考に入れてみたものです）

　それで、まず、調べたサイトに記されていたrsize=32768と大きくしてみましたが、より短時間の3分くらいでエラーメッセージが出て演奏停止になるようになりました。
　rsizeのオプションを外してみたりしてみましたがエラーが出る症状は変わらずでした。

　調べてみた結果、「1024の倍数のオプションを与えていく」との記述があったので、一番少ない、rsize=1024を指定してみたところ、これまでのところ安定して動作するようになりました。

・top - 19:54:38 up 3:10（略）

現在、連続再生をさせて３時間が経過していますが、エラーが出ることなく演奏できています。
　さらに、2048など、数値を詰めてみるべきかも分かりませんが、とりあえず、私の環境ではrsizeを1024に指定してやることで解決の糸口が見えてきたようです。

　このまま、明朝まで、さらに様子をみて、追加報告をしたいと思います。

　お二人の書き込みがとても参考になりました。どうもありがとうございました。

皆さん、情報ありがとうございます。
私の方ですが、
3.8.13+rt12が今日、例の cannot submit urb (err = -18)を出しました。この4日間で2回目ですが、長時間連続再生とは関係ないような感じです。いずれにしろかなりの低頻度です。

fstabのnasマウント設定はcifsでtwlさんとほぼ同じです。(cache=strictが入っていない以外)

3.8.13+rt11だけがこのエラーを今まで確認していないので、試しにrt11でしばらく動かしてみます。
自分としてはこの手の作業は苦にならないので、楽しんでやっています。時々カーネルビルドすると手順も忘れなくて良いですし:)

こんにちは、kojiです。

　先程の書き込みの後、5時間くらいまで再生できていたのは確認しているのですが、その後、別の部屋に行き、先程戻ってきたら例のエラーメッセージをはいてとまっていました。

　以前に比べると、かなり改善しましたし、これだけの時間再生できるならば実用上は問題ないとも言えますが…

　引き続き、また、色々といじってみたいと思います。

　先程のメッセージでほぼ解決みたいなニュアンスでの書き込みになってしまったので、取り急ぎ、その後の経過報告です。

こんばんは。
rt13が出ているのを発見してしまったので入れ替えてテストしてみます。

こんばんは、kojiさん、twlさん

rt13ですがKernel Bootingから先に進まず起動しないので今のところテストできません。以前のyoさんの記事を見てboot.scrにvmallocを復活させてみましたが、だめでした。何かミスしてるのかも知れません。。

fHiroさん、お返事が遅くなりましたが私も同様です。rt13を従来のconfigでビルドしましたが、

Uncompressing Linux... done, booting the kernel.

ここから先に行ってくれません。何度やっても同じなので、現在はrt12に戻っているところです。

twl

twlさん、kojiさん
情報ありがとうございます、やはりrt13でまさかのbootせず、ですね。時間があるときにいじってみようと思います。

あと、もし梅雨入り版のmpd.confをお使いの場合、別スレのアップサンプリングのところに載っているように、player outputの優先度をFIFO:54->53に(ひな祭り版相当)戻した方が良いです。

自分の環境だと、これを54にすると例のcannot submit urb(error = -18)がすぐ出るようになりました。
その辺りの状況からするとやはりmpdをrt化している場合に出る現象かも知れません。

fHiroさん、twlさん

　いじる時間がなくて、遅ればせながら、私の方でもrt13パッチでのカーネルを作成して起動してみました。

　すでに、皆さんから途中で止まるとの報告が上がっていたので、シリアル接続をして様子を確認しました。
　皆さんと同様、uImageを読みに行くところでUncompressing…とずっと出たままとまってしまいますね。
　以降、このuImageから来るエラーメッセージが表示もされないので、解決の糸口がみえにくいですね。

　さしあたっては、次のrt14が出るのを待つ…という感じでしょうか？

twlです。3.8.13-rt13でとりあえずbootできる状態になりました。

従来のconfigでは何度buildしても、boot時に'Uncompressing Linux... done, booting the kernel.'以上には進まないので、rt12とrt13のpatchファイルのdiffをとってみたところ、rt13での変更部分はすべて'ifdef CONFIG_PREEMPT_RT_BASE'を含む記述になっていました。従ってこの設定を避ければとりあえずbuild可能と判断しました。

カーネルのmake menuconfigにおけるPREEMPT_RT関連の設定は、従来

( ) No Forced Preemption (Server)
( ) Voluntary Kernel Preemption (Desktop)
( ) Preemptible Kernel (Low-Latency Desktop)
( ) Preemptible Kernel (Basic RT)
(X) Fully Preemptible Kernel (RT)

となっていますが、この設定では自動的にCONFIG_PREEMPT_RT_BASE=yとなってしまうため、

( ) No Forced Preemption (Server)
( ) Voluntary Kernel Preemption (Desktop)
(X) Preemptible Kernel (Low-Latency Desktop)
( ) Preemptible Kernel (Basic RT)
( ) Fully Preemptible Kernel (RT)

と、敢えてFully Preemptible Kernelを外した設定にしました(CONFIG_PREEMPT__LL=y)。従ってこの設定はyoさん方が目指しているrtカーネルに相当するものかどうかがちょっと微妙なところなのですが、とりあえず、この設定でbuildとすると、voila!、通常にbootでき、現在mpd自体も順調に稼働しています。

boot.scrはyoさんおすすめのboot2.txtを基本としたもので、大きな変更はありません。なお、boot時にCGROUP関連が設定されていないとのmessageがいつもうるさく出るので、上記の変更に加え、CGROUPの設定もyesにしてあります(CONFIG_CGROUPS=y)。

この設定がいいのかどうかこれから検討が必要ですが、とりあえず経過を報告させていただきます。

twl

twlさん、情報ありがとうございます。
試してみます、patch差分も見てみようと思います。

twlさん、kojiさんこんばんは。

私の環境でもBasic RTをOFFにしてビルドすると、正常に起動することを確認しました。
その後
3.8.13+rt12
3.8.13+rt13
の状態のソースファイルを比較すると
変更のあるのは、patchファイルからもわかりますが

linux-3.8.13/include/linux/list_bl.h
のみでした。中身を見ると
/////////////
static inline void hlist_bl_lock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
bit_spin_lock(0, (unsigned long *)b); // -> こっちはrt12と同じ
#else
raw_spin_lock(&b->lock); // -> rt13での追加
__set_bit(0, (unsigned long *)b);
#endif
}

static inline void hlist_bl_unlock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
__bit_spin_unlock(0, (unsigned long *)b); // -> こっちはrt12と同じ
#else
__clear_bit(0, (unsigned long *)b); // -> rt13での追加
raw_spin_unlock(&b->lock);
#endif
}
で処理を分けているところのみがrt13で追加されています。
ので、rt13でBasic RTをOFFにすると実質rt12と同じものになっていると思われます。

//////////////////
list_bl.hは
make list head locking RT safeと言うことなので
何らかの資源の排他管理を行っているようなのですが、このロックと解放
処理がrt13で変更されて、raw_spin_lock()という仕組みを使うようになっています。

この解放待ちでデッドロックになっているような気はしますが、rt12までの仕組みも基本は同じようなことをしていますし、謎です。
list_bl.hはRTパッチ全般で使用されているので、実際に止まっている箇所を特定するにはデバッガか、怪しい箇所にコンソールメッセージを仕込むとかだと思いますが、linuxに詳しくないのでそれもままなりません。

VMWare Playerがあまりに遅くて(起動に5分とか)やる気が失せるほどなので、SSDに換えたところ爆速になりました。
VMWareのubuntu起動も20秒程度です。HDDがいかにシステムの足を引っ張っているかがわかりました。

fHiroさんwrote:

> list_bl.hは
> make list head locking RT safeと言うことなので
> 何らかの資源の排他管理を行っているようなのですが、このロックと解放
> 処理がrt13で変更されて、raw_spin_lock()という仕組みを使うようになっています。
>
> この解放待ちでデッドロックになっているような気はしますが、rt12までの仕組みも基本は同じようなことをしていますし、謎です。

fHiroさん、解析ありがとうございました。

http://www.spinics.net/lists/linux-rt-users/msg10198.html" target="_blank">http://www.spinics.net/lists/linux-rt-users/msg10198.htmlを参照すると、今回のlist_bl.hがらみの問題は背景に
include/linux/jbd_common.hの変更があるようです。私はこの変更の詳細についての知識はありませんが、JBDはext3の
journalingに関して使われているシステムのようです。

現在私の環境ではbootやrootfsにはext3を用いているので、これをext4にするともしかして状況が変わるのかもしれません。
まだ憶測の段階ですが時間があったらちょっと試してみます。

twl

twlさん、情報ありがとうございます。

私も、ext3の1パーティション構成なのでext4に変換して試してみましたが残念ながら
booting the kernel.から先には進みませんでした。
いちおう手順ですが

ext3 -> ext4への変換は
VMWare上のubuntuで
tune2fs -O extents,uninit_bg,dir_index /dev/sdf1
e2fsck -fDC0 /dev/sdf1

cuboxに差して3.8.13-rt11で正常起動を確認
kernel.logでext4になっていることを確認。

3.8.13-rt13にしてcubox reboot で起動せず...

です。とりあえず私の環境での結果報告でした。

ext4のノンジャーナルにしていなかったのに気づいたので引き続きノンジャーナル化してテストしてみました。
tune2fs -c 0 -O ^has_journal /dev/sdf1
e2fsck -fDC0 /dev/sdf1

cuboxのkernel.logで
Jul 9 02:10:07 localhost kernel: EXT4-fs (mmcblk0p1): mounted filesystem without journal. Opts: (null)
ノンジャーナルのext4を確認。

で結果ですが、rt13ではやはり起動せずでした。
ただ気のせいかも知れませんが、ジャーナルレスの方が音が良いような気がするのでこのままにしようと思います。

fHiroさん、ext4ファイルシステムとrt13とのtrialおよびその結果のご報告、ありがとうございました。大変参考になりました。私もext4を試してみましたが、fHiroさんと同じ結果でした。

＃でも、ジャーナルレスの方が音が良いというのは思いがけない収穫でしたね。

いずれにしても考えつくことも尽きた状態ですので、rt14あたりが発表されるまで、私もちょっと様子見の状態になろうかと考えております。

twl

twlさん、こんばんは。

１つ気になるのは、3.8.xになってからcubox固有パッチが無いので適用せずにカーネルをビルドしていることです。
3.6.9までは固有パッチのあたったカーネルソースが有ります。その後カーネルにcuboxのパッチが取り込まれた結果不要になったのかどうかが私にはわかりません。ただカーネルソースに取り込まれたとした場合にはビルド時に何らかの指定が必要になるはずですが、それが.config設定には入っていないような気がします。

いずれにせよ、現状ではrtの更新待ちですね..

fHiroさん
patchの話しじゃなくてすいません。

>ただカーネルソースに取り込まれたとした場合にはビルド時に何らかの指定が必要になるはずですが、
Device Treeで最低限の機能を組み込んでいるようです。
make dtbs
cd arch/arm/boot
cat zImage dts/dove-cubox.dtb > zImage.cubox
固有patchではないので、例えばオプティカルなどは動かないようです。
dtsに対するpatchを公開されている方がいらしゃいます。残念ながら3.8のものはないようです。
http://moinejf.free.fr/" target="_blank">http://moinejf.free.fr/　（画面右上のほう）

tinkerさん、こんにちは。

device treeの方に入っていたんですね。アドバイスいただいて、ありがとうございます。
実はそもそもdts自体良くわかっていないので^^;;
教えていただいた、リンク先のページ何かすごく前にも見たことがあります、3.10-rc1のパッチが載っていますね。
改めてhttp://www.xilka.com/sheeva/" target="_blank">http://www.xilka.com/sheeva/の方を見てみると、DTパッチと言うのがあったりするので(前は意味が良くわからなかった)、と3.8.xで使えるものもあるかもです。

カーネル3.8.xは13で打ち止めなので、rtも3.9か3.10に移行ですね。またいろいろありそうです。
普通にオーディオ機器としてcuboxを使うのには全く推奨できない楽しみ方ですはありますが。。

voyage mpdのcuboxも出たようですし、squeeze boxもcuboxで動くようですし、興味は尽きません。

fHiroさん

rtのpatchが出るとすれば3.10.xですね。3.10も3.8みたいな音だったら良いなと思ってます。

>普通にオーディオ機器としてcuboxを使うのには全く推奨できない楽しみ方ですはありますが。。
これはこれで楽しいんで^^;

fHiroさん、tinkerさん、kojiです。
この間、ほとんどいじる時間がとれず、皆さんの検証の書き込みを拝見させて頂いていました。
　次は、3.10ベースなのですね。楽しみに待ちたいと思います。


>普通にオーディオ機器としてcuboxを使うのには全く推奨できない楽しみ方ですはありますが。。
　故・長岡氏の「手段が目的となることを趣味という」という言葉を思いだしました(^_^)
　でも、音が確かに変わっていくので、いじっていて楽しいですよね。

>voyage mpdのcuboxも出たようですし、squeeze boxもcuboxで動くようですし、興味は尽きません。
　上記の書き込みで、Voyage Muboxがリリースされたのを知りました。今度、時間がとれる時に、インストールしてみたいと思います。
　どうもありがとうございました。

皆さん、
寝る前になんとなくrtのページをリロードしたらrt14を発見w！
結果は・・・,めでたくブートしました:D
まだ1時間程度ですが、urbのエラーは出ていません。

例の include/linux/list_bl.hですが、修正が入っていました。
----------いちおうソースの修正部分を載せておきます ------------------
static inline void hlist_bl_lock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
bit_spin_lock(0, (unsigned long *)b);
#else
raw_spin_lock(&b->lock);
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
__set_bit(0, (unsigned long *)b); -> rt13ではこれが生きていた。
#endif
#endif
}

static inline void hlist_bl_unlock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
__bit_spin_unlock(0, (unsigned long *)b);
#else
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
__clear_bit(0, (unsigned long *)b); -> rt13ではこれが生きていた。
#endif
raw_spin_unlock(&b->lock);
#endif
}
-------------------------------------------------
CONFIG_PREEMPT_RT_BASEが定義されていない場合の処理との互換性を取るためかと思っていた
__set_bit(0, (unsigned long *)b);
__clear_bit(0, (unsigned long *)b);
ですが、rt14では
CONFIG_SMP
CONFIG_DEBUG_SPINLOCK
のいずれかを定義している場合のみ生きるようになっていました。

fHiroさん、rt14のおしらせ、ありがとうございました。

私も先程このrt14カーネルをbuild、問題なくbootできmpdも順調に稼働しています。とりあえず、ご報告まで。

twl

twlです。

このスレッドのタイトルで続けていいものかどうか迷いましたが、とりあえず報告です。

去る８月12日に3.10.6-rt3が発表されたことを以下のURLで知りました。特徴としてv3.8のパッチがいくつかあてられ、armではRT-FULLがサポートされたとのこと、

　　https://lwn.net/Articles/563165/" target="_blank">https://lwn.net/Articles/563165/

早速rtパッチ付きのカーネルをarchlinuxでビルドしてみました。古い3.8.11-rtから3.8.13-rtで用いていた.configがそのまま通り、昨夜からCuBox上で動いていますが、立ち上げから約９時間、mpdの再生は円滑、特にトラブルには遭遇しておりません。音質の評価は主観的なものですが、not badといったところです。

[root@alarmcubox ~]# uname -a
Linux alarmcubox 3.10.6-rt3_CuboxAudioRTuned #1 PREEMPT RT Mon Aug 19 09:31:48 JST 2013 armv7l GNU/Linux

top - 07:15:20 up 8:54, 1 user, load average: 0.67, 0.66, 0.60
KiB Mem: 2073228 total, 178192 used, 1895036 free, 9844 buffers
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1091 mpd 20 0 79848 9160 4284 S 4.6 0.4 25:57.89 mpd


以前に3.10.4のrt kernelを試した際にはうまく動作しなかったのですが、今回のrt3パッチで旧3.8の環境が一部組み込まれたことにより、3.10-rtの環境にうまく移行できそうな気配です。

以上、おしらせでした。

twlさん、3.10.6-rt6のお知らせありがとうございます。

実は自分も3.10.4+rt2を軽く試したのですが、うまくビルドできなかったので、様子を見ておりました。3.10.6+rt試してみます。

3.8.13+rt14ですが、NASをcifs->nfsに変えたところurbエラーが頻発するようになったため、現状は最安定の3.8.11+rt8で使用しています。音質的にも3.8.13+rt14よりこちらの方が良い感じがします。

twlさん

Cuboxでも出来るんですね。以前、別スレでPREEMPTでもエラーが出るようなこと書いてあったので、難しいのかと思ってました。
wandboard dlの場合は、以下のpatchを当てないとPREEMPT RTでは動きませんでした。
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=c72a0e036f9d80c609e608a723751343f1f5e9fc" target="_blank">https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=c72a0e036f9d80c609e608a723751343f1f5e9fc

一つ教えてください。
twlさんが記載されているmpdなんですが、RES，SHRとか%MEMが通常より極端に小さいようですが、何か特殊な事されていますか？
1091 mpd 20 0 79848 9160 4284 S 4.6 0.4 25:57.89 mpd

tinkerさん、今晩は。

> Cuboxでも出来るんですね。以前、別スレでPREEMPTでもエラーが出るようなこと書いてあったので、
> 難しいのかと思ってました。

私はそういう知識もなくCuBoxを購入、指南場所としてのみみず工房でyoさんの書かれるままに従ってきただけなので、単に運がよかっただけなのだろうと思っております。カーネルをビルドしてからpreemptとかpreempt_rtの意味を後で学ぶようないい加減な人間ですので。

> 一つ教えてください。
> twlさんが記載されているmpdなんですが、RES，SHRとか%MEMが通常より極端に小さいようですが、
> 何か特殊な事されていますか？

そういうご指摘を受けるまではこれが当たり前なんだろうと考えておりましたが、このArchlinux/Cuboxで動くmpdによる負荷は軽めなんですね。でも、CPUに関してはBBBカーネルで行われているようなcpufrequtilsの設定などは行っておりません。/etc/mpd.confに関してもほぼdefaultに近い設定、buffer_time、period_timeおよびpriorityなどの設定は削除してあります。

mpdはgithub経由でコンパイルした0.17.4-DSDを用いていますが、正規の0.17.4版と大きな違いはないと思われます。ただしコンパイルの際、glib2-0がインストールされていない等、色々文句を言われるので、とりあえずglib-2.34.0をあらかじめコンパイル、インストールして./configureが通るようにしてあります。それでもあれがない、これがないと色々叱られるので、autoconfやautomakeをインストールした状態でautogen.shでconfigureを作成、これをもとにコンパイルしたmpdを使用しております。これは0.17.4のコンパイルでも同様です。ただ、%MEMが小さいのはおそらくビルドしたカーネルの性格がそのまま出ているのではと考えております。

実はBBBのスレッドを横目でみながら私も密かにBBBで遊んでいました (^^; 。しかしarchlinuxのrtカーネルビルドに比べ、かなり無理なパッチを当てないと動作しない状況、しかもそこまで努力してもpreempt_rtというかRT_FULLの環境が得られないというのは、patchの使用は最小限という私の趣旨と合わないので、現在は無理のない状況での設定でBBB上のmpdをCuBox上のmpdと比較試聴している状態です。

このスレッドとしては不適当かもしれませんが、比較のためにBBB上で動かしているDebian Wheezy版およびArchlinux版でのmpd動作状況を、現在のCuBoxの状況を含め、お示しさせていただきます。

用いたカーネルはDebianがBBB-eMMC-flasher-debian-7.1-2013-07-22.img(bone24が入っています)およびArchLinuxARM-am33x-latest.tar.gz(3.8.13-7-ARCH)です。Debian版ではDSD128まで途切れることなく心地よい音楽再生が得られていますが、Archlinux版ではDSD128は楽音の変質が著明、DSD64では一応正常な再生は可能なものの、静音時にプチプチと細かなノイズが発生します。いずれもPCM再生ではまったく問題ありません。

BBB arch

Linux alarm 3.8.13-7-ARCH #1 SMP Sat Jul 13 11:54:56 CDT 2013 armv7l GNU/Linux

top - 23:24:36 up 24 min, 1 user, load average: 1.18, 0.62, 0.40
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
184 mpd 20 0 89156 11628 5484 S 4.6 2.3 1:20.77 mpd

BBB debian

Linux arm 3.8.13_0811+ #2 SMP PREEMPT Sun Aug 11 09:10:16 JST 2013 armv7l GNU/Linux

top - 23:27:32 up 0 min, 1 user, load average: 0.81, 0.24, 0.08
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1894 mpd 20 0 72564 6752 1836 S 8.5 1.3 0:02.68 mpd

現在稼働中のCuBox Archlinux (3.10.6-rt3_CuboxAudioRTuned #1 PREEMPT RT)

top - 00:44:47 up 1 day, 8 min, 1 user, load average: 0.33, 0.47, 0.54
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1088 mpd 20 0 79796 9168 4276 S 5.0 0.4 70:45.08 mpd


長文、お詫び申し上げます。

twl

twlさん

私のとこは、3.10.6をFULL RTに出来るまで1週間かかってます。やっぱり日頃の行いってやつでしょうか(笑)

twlさんのmpdはmpd-dsdのもので、RTパッチがかけてあるのかは分かりませんが、RTとしては動かしていないというところでしょうか。それでRESとかSHRが小さいんですね。

BBBは苦労しましたが、勉強になったことも沢山ありました。
今回3.10.6であれこれやったことも、BBBの方に還元できるかもしれないです。
先述のpatchは3.10.8に取り込まれたようです。
このpatchは3.8.xにも使えますので、このスレ本来の目的どおり3.8.13のエラーを回避できる可能性があります。

BBBではcpufrequtilsを使いましたが、Cubox，wandboardでは使っていません。
代わり（でもないですが）に、wandboardでは、Debian及びUbuntuにcgroup-binをインストールしてcgroupを使えるようにしています。何となく動いてはいるようです（CPU0,1でそれなりに負荷を分散）
top - 18:29:37 up 20:19, 1 user, load average: 0.00, 0.02, 0.05
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu0 : 1.1 us, 0.4 sy, 0.0 ni, 98.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 1.4 us, 1.0 sy, 0.0 ni, 97.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 1032624 total, 539132 used, 493492 free, 58900 buffers
KiB Swap: 0 total, 0 used, 0 free, 397516 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
56 root -54 0 0 0 0 S 9.6 0.0 129:44.75 irq/72-ci13xxx_
2369 mpd 20 0 83040 70m 25m S 2.3 7.0 26:07.33 mpd
2983 root 20 0 5704 1224 880 R 0.7 0.1 0:00.17 top
50 root -55 0 0 0 0 S 0.3 0.0 2:57.61 irq/150-2188000
1503 root -54 0 0 0 0 S 0.3 0.0 1:40.52 cifsd

tinkerさん wrote:

> 私のとこは、3.10.6をFULL RTに出来るまで1週間かかってます。やっぱり日頃の行いってやつでしょうか(笑)

いえいえ、BBBでのtinkerさんやyoさんの熱心なやり取りを拝見しておりますと、生半可な気合いではBBBに入っていけないなと思っていた次第です。

> twlさんのmpdはmpd-dsdのもので、RTパッチがかけてあるのかは分かりませんが、RTとしては動かしていない
> というところでしょうか。それでRESとかSHRが小さいんですね。

ご指摘のごとくRTパッチはかけておりません。そういうことがtopの結果に現れているのですね、なるほど。

> 今回3.10.6であれこれやったことも、BBBの方に還元できるかもしれないです。
> 先述のpatchは3.10.8に取り込まれたようです。

そうですか、それは楽しみですね。でもそうなるとCuBoxで結構満足している私ももう少し真面目にBBBに取り組む必要がおきそうです。

> このpatchは3.8.xにも使えますので、このスレ本来の目的どおり3.8.13のエラーを回避できる可能性があります。

実は今回CuBox上の3.10.6-rt3カーネルで皆様ご経験のURBエラーを初経験、めでたくお仲間になることができました (^^)。

ほぼ48時間連続稼働していたmpdから楽音が再生されなくなったので何事かと思って調べたらCuBoxがハングしていました。再起動してlogを見たら、おなじみのurb submitエラーの痕跡あり、エラーの出自をたどると以下のようなOopsエラーから出発していることが分かりました。

Aug 21 00:26:11 alarmcubox kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Aug 21 00:26:11 alarmcubox kernel: pgd = ed220000
Aug 21 00:26:11 alarmcubox kernel: [00000000] *pgd=2d145831, *pte=00000000, *ppte=00000000
Aug 21 00:26:11 alarmcubox kernel: Internal error: Oops: 80000007 [#1] PREEMPT ARM
Aug 21 00:26:11 alarmcubox kernel: Modules linked in:
Aug 21 00:26:11 alarmcubox kernel: CPU: 0 PID: 1143 Comm: mpd Not tainted 3.10.6-rt3_CuboxAudioRTuned #1
Aug 21 00:26:11 alarmcubox kernel: task: ed094b40 ti: ed27e000 task.ti: ed27e000
Aug 21 00:26:11 alarmcubox kernel: PC is at 0x0
Aug 21 00:26:11 alarmcubox kernel: LR is at rt_spin_lock_slowlock+0x34/0x258
Aug 21 00:26:11 alarmcubox kernel: pc : [<00000000>] lr : [<c04742ac>] psr: 600f0013
Aug 21 00:26:11 alarmcubox kernel: sp : ed27fe08 ip : 000200d2 fp : 00000000
-snip-
Aug 21 00:26:11 alarmcubox kernel: [<c009c094>] (SyS_read+0x3c/0x70) from [<c000e240>] (ret_fast_syscall+0x0/0x30)
Aug 21 00:26:11 alarmcubox kernel: Code: bad PC value
Aug 21 00:26:11 alarmcubox kernel: ---[ end trace 0000000000000002 ]---
Aug 21 00:26:11 alarmcubox kernel: note: mpd[1143] exited with preempt_count 1
Aug 21 00:26:11 alarmcubox kernel: delay: estimated 0, actual 1103
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: delay: estimated 1810, actual 1103
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: delay: estimated 2161, actual 1103
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)

おそらく3.8.x-rtカーネルの伝統を引き継いだバグのようなので、debugを目的としたKernel Oops Reportを送るべき問題のようですが、とりあえずOopsによる被害はさして大きくないのでCuBoxではそのままこの新しいRTカーネルでmpdを動かしております。

twl

このスレッド、長くなりましたので、「kernel3.8/10と最新rtパッチでトラブル」というタイトルで続けます。