2413551_ja-JP

Yes

IW612のBluetoothが数日後にクラッシュする

こんにちは、

ユーザーの一人から、murata LBES5PL2EL-923(IW612コア)のBluetooth機能に関するバグを報告がありました。BluetoothスタックがBluetooth静的RFCOMM/SPPでデバイスにコネクテッドすると数日後にクラッシュする現象です

（元のレポートは公開されており、日本語版はhttps://armadillo.atmark-techno.com/forum/armadillo/31772で閲覧可能です。））

これに関して既知のバグはありますか？

ソフトウェアのセットアップ：

* Linux 6.12 は lf-6.12.49-2.2.0 に基づく(正確なソースツリー:https://github.com/atmark-techno/linux-6.12-at/tree/6.12.105-r0)

これはBTの問題ですが、参考までにワイヤレスドライバーはmwifiex lf-6.12.49-2.2.0をベースにしています。

* ファームウェアをimx-firmwareリポジトリの最新版lf-6.18.20_2.0.0にアップデートしました。https://github.com/nxp-imx/imx-firmware/tree/lf-6.18.20_2.0.0/FwImage_IW612_SD

* BlueZスタック（正確なバージョンを確認中です。申し訳ありませんが、確認し忘れていました。）

* 基板は*Bluetooth classic*(BLEではない)で単一のデバイスに接続され、RFCOMM/SPPで接続されています。60秒ごとにアプリケーションはメッセージを送信し、返信(簡単なポーリング)を受け取ります。数日後にコマンドタイムアウトが入り、BTドライバが再起動します

クラッシュ後に/sys/class/bluetooth/hci0/devcoredump/dataから取得したファームウェアダンプを添付しました。役に立つと仮定して、クラッシュまではdmesgにメッセージはありません(すみません、「FWダンプ開始」の前に短縮されているためタイムスタンプがなく、クラッシュ直後だったと理解しています)。

FWのリロード機構は動作しますが、再接続が必要なので、可能であれば対応が良いでしょう。

[    0.000000] Linux version 6.12.105-0-at (builder@71056255c5a6) (aarch64-alpine-linux-musl-cc (Alpine 15.2.0) 15.2.0, GNU ld (GNU Binutils) 2.45.1) #1-Alpine SMP PREEMPT Mon Aug 24 07:48:35 UTC 2026
[...]
[    9.321032] wlan: version = SDIW612---18.99.8.p52-MM6X18540.p33-GPL-(FP92) 
[...]
[   10.349326] Bluetooth: hci0: FW already running.
[   38.303160] Bluetooth: MGMT ver 1.23
[170117.376944] Bluetooth: hci0: command tx timeout
Bluetooth: hci0: ==== Start FW dump ===
Bluetooth: hci0: ==== FW dump complete ===
Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se
Bluetooth: hci0: FW Download Complete: 412940 bytes

分析に役立つその他の情報があれば、お尋ねください。

よろしくお願い申し上げます。

Re: IW612 bluetooth crash after a few days

1. HCIログも提供していただければ、どのコマンドがタイムアウトし、ファームウェアダンプが生成されているかを特定するのに役立ちます。

この件で具体的にどういう意味か教えていただけますか?実行後から実行できるコマンドはありますか?それともプロセスが実行されている間にhcidumpや同等のコマンドを実行すればよいのでしょうか?

Wi-Fiドライバーの読み込みパラメータを入手> 3.To、/lib/firmware/nxp/wifi_mod_para.conf を教えてください。

このファイルは使わないので、ここでもデフォルトのパラメータを使うべきです。ログレベルをデフォルト値から下げたので、DMESGもあまり役に立たないでしょう(前回の返信でdmesgのリンクを送りました)。

この期間中にWi-Fiを使っているかどうか、ユーザーに確認してみます

Re: IW612 bluetooth crash after a few days

こんにちは、 @martinetd

1. HCIログも提供していただければ、どのコマンドがタイムアウトし、ファームウェアダンプが生成されているかを特定するのに役立ちます。

2. WLANが稼働している間にWLANベースのユースケースを教えてくれますが、ファームウェアダンプが生成されている間にWLANが正常に動作しているか確認してもらえますか?

3.To get Wi-Fiドライバー loading parameters, you can provide us the: /lib/firmware/nxp/wifi_mod_para.conf

または、WiFiやBluetoothの読み込み全過程を含む 通常の起動DMESGログ を提供してもらえます。DMESGのログから情報を得ることができます。

4.現在、お客様が使用されているものよりも新しい公開されているGitHubファームウェアリリースはありません。

imx-firmware/FwImage_IW612_SD (lf-6.18.20_2.0.0) · nxp-imx/imx-firmware · GitHub

ですので、これは既知の問題ではないと思います。

私たちは、ユースケースに関する情報やHCIログを多めに持っておきたいので、何が起こったかを追跡したり手順を再現したりして、ローカルで問題を再現できるようにしたいと考えています。

もしこの問題に関する他に情報があれば、ぜひ教えてください。

よろしくお願いいたします。

Christine。

Re: IW612 bluetooth crash after a few days

こんにちは、 @Christine_Li さん、迅速なご返信ありがとうございます。

> 1.もしbtnxpuartドライバーを使っているなら、btnxpuart.cを教えてください。

私たちは、 https://github.com/nxp-imx/linux-imxで提供されている btnxpuart を使用しています。バージョン lf-6.12.49-2.2.0 に基づいており、正確なファイルはこちらでご覧いただけます https://github.com/atmark-techno/linux-6.12-at/blob/6.12.105-r0/drivers/bluetooth/btnxpuart.c

2. Wi-FiとBluetooth/802.15.4のコンボファームウェアを使用していますか？それとも、別々のファームウェアを使用していますか？

両方使っています:起動時にWi-FiドライバーがコンボFWを読み込み、クラッシュ後に別のFWをリロードします(だからログで別FWの名前を付けています)。

このクラッシュが発生したとき、コンボファームウェアがロードされていました（起動後の最初のクラッシュ）が、両方のファームウェアで再現すると理解しています。

> 3.Wi-FiとBluetoothドライバーの負荷パラメータを教えてもらえますか?

明示的に設定している唯一のWiFiパラメータはdrv_mode = 0x3で、使っていないWiFiダイレクトインターフェースを無効化します。Bluetoothパラメータは設定していません。もし正確な設定のダンプ方法を教えていただければ、ユーザーにコマンドを実行してもらい、情報を取得してもらうよう頼めます。

> 4.詳細な再現手順を教えていただけますか?

これはユーザー報告に基づくものなので、説明したこと(数日間60秒ごとにRFCOMM接続をポーリングする)以上のことは言えません。チップが接続されているサブデバイスによって異なるのではないかと心配しています。

RFCOMM経由でpingを送ってローカルで再現できるデバイスを探してテストスクリプトを提供してみますが、今のところファームウェアやBTNXPUARTドライバの既知のバグが記載されたリリースノートは見つからなかったので、既知のバグがあるかどうか(そしてできればファームウェアのダンプから何か情報が得られるか)を確認したいです。

よろしくお願い申し上げます。

Re: IW612 bluetooth crash after a few days

こんにちは、 @martinetd

1. Bluetooth用にNXPのBTNXPUARTドライバーを使っていますか?それともLinuxのオープンソースUartドライバを使っていますか?

もしbtnxpuartドライバーを使っているなら、btnxpuart.cを教えてください。

2. Wi-FiとBluetooth/802.15.4のコンボファームウェアを使用していますか？それとも、個別のファームウェアを使用していますか？

ログが下にあるのを見ているので、別のFWを使っているのではないかと疑っています。確認が必要です。

hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se

3. Wi-FiとBluetoothドライバーの負荷パラメータを教えてもらえますか?

4. 詳細な再現手順を教えていただけますか?

よろしくお願いいたします。

Christine。

Re: IW612 bluetooth crash after a few days

> * BlueZスタック（正確なバージョンを確認中です。申し訳ありませんが、確認し忘れていました。）

参考までに、BlueZ版は5.82です

Re: IW612 bluetooth crash after a few days

> btmon

ご説明いただきありがとうございます。

クラッシュの再現には数日かかり、ログが大きくなるため、完全なログを保存・共有するのは現実的ではないかもしれません(1分で100KB見えるので、2日で約300MBになります)。
残念ながらbtmonにはtcpdumpのような「巡回記録」モードはないようですが、クラッシュ直前の数分だけに興味があるなら、顧客のログを5分ごとに2ファイル交互に表示して、最後の5分を記録できるようにリクエストできます。
（未テスト）といった形で、最後のサンプルを送ることは許容範囲でしょうか？(ただし、ランの間にイベントが記録されない短いウィンドウがあります...)

I=0; while ! [ -e /sys/class/bluetooth/hci0/devcoredump/data ]; do timeout 300s btmon -K -t -w log.$I; I=$((I+1%3)); done

> コアダンプが読み取れません

残念ですが、どうしようもありません。

このファイルは、FW ダンプ完了メッセージの後に /sys/class/bluetooth/hci0/devcoredump/data から読み取ったものです。もしこの方法が適切でない場合や、より有用なデータを取得する方法があれば喜んで対応しますが、今は btmon トレースに焦点を当てましょう。

よろしくお願い申し上げます。

Re: IW612 bluetooth crash after a few days

こんにちは、 @martinetd

1. btmonの場合：

==>はい、サイズの都合で全工程を記録できれば、あなたが提案した方法が良いと思います。それに、それ以外に良いアイデアはありません。

2. ファームウェアダンプの場合：

drvdbg=0xa0037でドライバーを読み込むことをおすすめします。これにより、より多くのfwダンプやドライバーのダンプログを記録して分析できます。

問題が発生しました

ログは以下のようにこのディレクトリに自動的に保存されます。

========================================

[4221.173141]ディレクトリ /data/dump_4220 の作成エラー。/var にディレクトリを作成してみてください。

[4221.173147]ウェイクアップデバイス...

[4221.173231]ディレクトリ /var/dump_4220 の作成に成功しました。

[4221.173232]ディレクトリ名は /var/dump_4220 です

[ 4221.173233] === ドライバ情報開始ダンプ===

[4221.173289]DRVダンプデータは/var/dump_4220/file_drv_infoにあります。

[4221.173306]ウェイクアップデバイス...

[4221.173889]SDIO Func0 (0x0-0x9): 43 03 06 00 07 00 00 02 03 00

[4221.175173]SDIO 機能 1 (0x4-0xb): 00 00 00 00 ff ff ff ff

[4221.175879]SDIO Func1: (0x4c) 00 (0x50) 08 (0x54) 07 (0x55) 0c (0x58) 10 (0x59) 00 (0x5c) 00 (0x5d) 00

[4221.176284]SDIO 機能 1 (0xc0-0xca): DC fe 96 00 31 11 00 37 37 02 20

[ 4221.177301] |

[4221.275861]SDIO Func1 (0xc0-0xca): DC fe a1 00 3b 00 00 37 37 02 20

[4221.276501]ドライブ情報の合計バイト数 = 263150 (0x403ee)

[ 4221.276503] === ドライバー情報ダンプ終了===ウェイクアップ装置...

[ 4221.276555] ==== デバッグモード出力開始: 4220.878602 ===

====================================================

ダンプが「/var」や「/data」で自動生成されていない場合は、以下の「cat /proc/mwlan/adapter0/fw_dump > file_fw_dump」コマンドを使って手動で収集できます。

2. DMESGログにディレクトリが印刷されていないか、あなたの場合はログレベルが下がっている場合は、以下の方法で登録してください:

- echo debug_dump > /proc/mwlan/adapter0/config

しばらく（1～2分）お待ちください。

fw_dumpの場合：

- cat /proc/mwlan/adapter0/fw_dump > file_fw_dump

drv_dumpの場合：

cat /proc/mwlan/adapter0/drv_dump > file_drv_dump

このようなFWクラッシュ問題に対して、btmonログはお客様のユースCASEや問題シナリオをよりよく理解するための拡張ログです。FW_dumpは私たちにとって最も重要なログです。

また、前述の通り、このテスト中にお客様にWi-Fiのユースケースについても尋ねてください。

よろしくお願いいたします。

Christine。

Re: IW612 bluetooth crash after a few days

BTmonについては了解しました。リクエストしてみます（Wi-Fiの使用状況についても質問します）。

まずファームウェアのダンプについて確認させてください。私が取得したダンプはBluetoothのダンプでしたが、あなたが説明しているのはワイヤレスのダンプのようですね。

お客様からのトレースではWiFiドライバはクラッシュしなかったので、drvdbg=は効果がないのではないかと思います。

また、結合ファームウェアの場合(「echo debug_dump > /proc/mwlan/adapter0/config」)でワイヤレスファームウェアが必要な場合、問題はBTドライバーが自動的に新しいファームウェアをリロードし、アダプターを再起動してしまうため、これを動作させるにはファームウェアの読み込みを無効にする必要があることです

ダンプは分析に有用だと思います。もしダンプの入手方法を修正できるなら、まず知りたいです。何をすべきかが明確になったら、一度にお客様にすべて尋ねます

よろしくお願いします。

Re: IW612 bluetooth crash after a few days

こんにちは、 @martinetd

この件で具体的にどういう意味か教えていただけますか?実行後から実行できるコマンドはありますか?それともプロセスが実行されている間にhcidumpや同等のコマンドを実行すればよいのでしょうか?

==>hciログは、以下のコマンドでBluetooth/BLEを有効にする後にキャプチャ可能です:

btmon -w failed_snoop.log &

その後、顧客は再現手順を実行し、この問題を再現しようとします。

failed_snoop.log には、Bluetooth/BLE のすべてのプロセスが記録されます。

問題が再現されたら、このログを確認して実行されているコマンドやイベント情報を把握し、関連する疑いを見つけることができます。

これは、ファイアウォールがクラッシュした後に失敗したログを実行して取得するためのコマンドではありません。

ところで、提供された fw ダンプ bin ファイルfw_devcorecump.binを復号化するために、社内の専門家チームに協力を依頼しました。しかし残念ながら、復号がうまく解読できていません。ファイルが破損しているか、データが不足しているため復号できないようです。

よろしくお願いいたします。

Christine。