2020年4月1日水曜日

[Linux] エージングで逝ってしまう調査3

こんにちは

ソフトな道をほのぼのと今日も歩きます。


今回は、前回の逝ってしまう原因調査の続きです。


スレッドがsnd_pcm_writei()実行中に”-EBADFD”が入ってくると、

   

    そのエラーに対する処理は入っていない為


    リトライ発生という無限ループに入っていました。

   

調査したところ、そもそも、EBADFD自体でるのがNGということが分かりました。


スレッド内でクローズ処理をしていたのですが、


オープン失敗に対してもクローズ処理をしているところがありました。


要するにnullに対してのクローズ処理。


お恥ずかしい限りですw


また、FDファイルディスクリプタ自体が不定な箇所がありました。


fopen()とopen()のエラー判定は違うことに対処できていなかったです。


fopen()の失敗はNULL(0)

open()の失敗は-1

です。

 

FDはそれぞれ1以上、0以上となるので、エラー判定はしっかりしないと、数百回に一回の不具合につながります。


    今回は以上です。


[環境]

私の使用環境は VMware 上でUbuntu14.04を使用しています。

コンパイラ: arm-linux-gnueabihf-gcc


今日から新入社員が入ってきます。

電車内でおしゃべりしているが、飛沫感染させないようにしてもらいたいですね。

 

2020年3月26日木曜日

[Linux] 音がなる時にノイズがなる。

こんにちは

ソフトな道をほのぼのと今日も歩きます。


今回は、音が鳴る時に瞬間的にノイズのようなものが入ることについて記載します。


鳴っていたのを調べてみました。


linux-x.xx.xx/sound/soc/codecs/tlv320aic31xx.c


{TIMER_CLOCK_MCLK_DIVIDER , 0x00},*/


これをいじるとpop音の対応ができるとあったのですができませんでした。


試行錯誤した挙句、初期化を行うとどうやらパツパツ音が鳴るようです。


なので、起動時に一度だけ初期化を行うようにしました。


結果としてpop音はこの対策によってならなくなりました。


[環境]

私の使用環境は VMware 上でUbuntu14.04を使用しています。

コンパイラ: arm-linux-gnueabihf-gcc


商品券を12000円を国民に給付する案があるようです。


安倍総理の顔入りなら記念にとっておこう。


麻生元総理ならすぐに使おうかな。


2020年3月14日土曜日

[Linux] エージングで逝ってしまう調査2

こんにちは

ソフトな道をほのぼのと今日も歩きます。


今回は、前回の逝ってしまう原因調査の続きです。


スレッドがsnd_pcm_writei()実行中に”-EBADFD”が入ってくると、

   

    そのエラーに対する処理は入っていない為


    リトライ発生という無限ループに入っていました。


https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#gabc748a500743713eafa960c7d104ca6f


    こちらを見ると、”-EBADFD自体はPWMが正しくない状態になっているようです。


    手探りですが、snd_pcm_recover()を行って、復帰しなければ

   

    あきらめて、全体的にリトライを行うようにしようと思います。

           

今回は以上です。


[環境]

私の使用環境は VMware 上でUbuntu14.04を使用しています。

コンパイラ: arm-linux-gnueabihf-gcc



2020年3月6日金曜日

[Linux] エージングで逝ってしまう調査

こんにちは

ソフトな道をほのぼのと今日も歩きます。


今回は、linux 上で自作したアプリを実行中に何のエラーもなくどこかに逝ってしまったかのような現象について考えてみたいと思います。


2020-03-05時点ではまだ分かっていません。


  1. デバッカで強制ブレークすると、ソース情報にはないアドレスで止まりました。

→何かしらの処理でメインに戻れなくなったか?スレッドが入ってはいけない処理でスレッドが入ってしまったか

  1. "/etc/rc.local"から本アプリを登録していたが辞めてみたところ、現象発生時に"ctrl+c"で強制的に抜けることができた。

→DDRメモリが辺という訳ではない。

  1. いたるところでデバッグ用にprintf文を出力させてみた。

          →音再生開始してから終了するまでの間にスレッドが入っているような気がします。

スレッドは確かにクリエイトして動かしているだけなので、

動作としてラウンドロビンだとアウトかもしれません。

まずは、スレッドの動作仕様を見直してみることにします。

int pthread_getschedparam(pthread_t thread, int *policy,

                         struct sched_param *param);

で見ていきます!

           

今回は以上です。


[環境]

私の使用環境は VMware 上でUbuntu14.04を使用しています。

コンパイラ: arm-linux-gnueabihf-gcc


2020年2月19日水曜日

[Linux] SDカードブートがカードによって出来ない件

こんにちは

ソフトな道をほのぼのと今日も歩きます。


今回は、SDカード(MicroSDカードです。以下、SDカードとします。)の種類によってlinuxが起動できなかった件についてになります。


最近、ユーザにSDカードを渡す約束があったので、今までの開発に使用していた


ものとは別のSDカードを用意して、


uboot, kernel, デバイスツリー、ユーザランド(rootfs)を書き込んで、


端末に挿し込んで起動してみたところ、uboot→kernel途中までは


動作しているようですが、ユーザランドに到達する前に


“Waiting for root device /dev/mmcblk0p2..."


から先に進みませんでした。


SDの違いとしては以下の通りでした。


[NG品]

    スピードクラス10

    バスインターフェーススピード:UHS-I

[OK品]

スピードクラス10

    バスインターフェーススピード:記載ない

(

上記については、以下のサイトが分かりやすかったです。

https://www.green-house.co.jp/special/sd-card/

}


どうやら、クロックが速すぎて、ドライバ側では対応できていないことが

判明しました。


私の解決した方法は、”High Speedで動作させるように変更する”、の方針でした。


デバイスツリーファイル(xx.dts)を以下のように”no-1-8-v;”を追加することで


現象は収まりました。

-----------------------------------------------

    &mmc_1 {

        status = "okay";

        bus-width = <4>;

        …

        no-1-8-v;

        …

    };

-----------------------------------------------

           

今回は以上です。


[環境]

私の使用環境は VMware 上でUbuntu14.04を使用しています。

コンパイラ: arm-linux-gnueabihf-gcc


    コロナウィルスになった場合の症状が分からないでいます。

    たまに、すごい咳をしている人見かけますがそういう人は

    もしかしたらもしかすると。。。と思ってしまいます。

    人混みはやはり避けたほうがよさそうですね。


2020年2月12日水曜日

開発時の予期しない問題の予防1

こんにちは

ソフトな道をほのぼのと今日も歩きます。


今回は、開発している時に、やっておいたほうがよいことを記載します。


こちらを行うことで、認識していない不具合の遭遇をある程度予防できると

思います。


なぁんだ、そんなことか?と言った内容ですので、さらっと見るだけでもいいと思います。


------------------------------------------------------------------------------------------

1.条件文のその他の処理をどうするかを考えておく。


2.デバッグメッセージをソース内に組み込んでおきます。その際”#ifdef”で

表示/非表示切り替えが容易に行えるようにしておきます。

------------------------------------------------------------------------------------------



“1.条件文のその他の処理をどうするかを考えておく。”

こちらswitch文のdefaultの処理を作りましょうということです。if文の場合、elseでしょうか。

意外とこういうところから意味の分からない現象につながっていく危険性があります。


“2.デバッグメッセージをソース内に組み込んでおきます。その際”#ifdef”で

表示/非表示切り替えが容易に行えるようにしておきます。”

これは、デバッグ用メッセージを利用して、不具合の特定/対策などが早期にできるようにする私なりの工夫となります。

以下、一例です。

-----------------------------------------------------------------------------------------------

[test.c]

switch ( state& 0x7 ) {

case TEST_SENSOR_1:       

#ifdef DEBUG_TEST_MESSAGE

    printf("test sensor_1: 開始センサアクティブ (%s %d) \n", __FILE__, __LINE__);

#endif

[test.h]

#define   DEBUG_TEST_MESSAGE

-----------------------------------------------------------------------------------------------

test.cに#ifdef ”キーワード”としておき、

ヘッダファイル”test.h”にてキーワードを定義する/しないによって#ifdef内が

有効/無効になります。

こうしておくと、runして2二日後に原因不明なハングが発生といった

やっかいな不具合の調査時に役に立ちます。(絞り込みを行うことができます。)


今回は以上です。


[環境]

私の使用環境は VMware 上でUbuntu14.04を使用しています。

コンパイラ: arm-linux-gnueabihf-gcc


最近、東京は国際人が多くなりましたね。


新型コロナではないですが、本人は気づいていない(潜伏期間の人)が


他国の人(免疫の無い)に伝染病をうつしてしまう可能性がないか、


気になってしまいます。


いずれにしても、人混みは避けたほうが良さそうですね。



2020年2月6日木曜日

[Linux] サウンドがならない対応

こんにちは

ソフトな道をほのぼのと今日も歩きます。


Linuxにおけるアプリ開発をしています。


今回は、音が鳴らないという現象が発生しました。


ALSAを使用しての音声出力を行っています。


音ファイルはRIFF形式のものですが、


このファイルは一体どんな設定なんだろう。。


ということで調べてみたところ、以下のサイトが大変わかりやすかったです。


https://taku-o.hatenablog.jp/entry/20181120/1542726865


私が使用しているファイルをエディタでバイナリで開いてみて


リンク先内容と照らし合わせて書き出してみました。


---------------------------------------------

bits_per_sample : 16bits

num channels: 1チャネル(モノラル)

サンプリングレート: 22050

byte rate: ブロックサイズは44100

---------------------------------------------


この設定で音が鳴るはず。。と思っていたのですが、


まだ動作しませんでした。


調べてみたところ、バッファはmallocを使って行っていましたが、


これを以下のように、2バイトバス幅に設定した静的バッファに


したところ音が鳴りだしました。



static short buff[0x1000];



推測ですが、bits_per_sampleが16bitなので、アライメントがそれにあう


short型でメモリ確保しておかないとだめなのかもしれません。

そして、音が鳴るようになったところで、ターミナル(teraterm)をみたら、


なにやら、以下の表示がされていました。


“ALSA lib pcm.c:8432:(snd_pcm_recover) underrun occurred”


調べてみたところ、以下が参考になりました。


https://tutorialmore.com/questions-174806.htm


確かに、”snd_pcm_writei();”を連続して呼び出す際にウェイトを入れてあげると


上記”underrun ”は発生しなくなりました。


ウェイトを入れるのは美しくないので、それに代わる何かを探してみました。


そしてありました。



snd_pcm_set_params();のレイテンシの設定を変更してあげる。



こちらを行うことで、上記”underrun”の現象はなくなりました。


以上です。


[環境]

私の使用環境は VMware 上でUbuntu14.04を使用しています。

コンパイラ: arm-linux-gnueabihf-gcc


新型コロナウィルスが発生していますが、なんとか乗り切りましょう。


(マスクが少ないから、石鹸でよく洗って再度使うしかない状態です。


フリマの一部の人たちに買い占められて、高値を払うか、それとも死を選ぶかの


究極的選択になっていますが、私は買わないで使いまわす選択肢を選びます!


その分、武漢へ空からマスクを降らせましょう。)