0

Linux 2.6.24 を実行する XSCALE アーム コアを備えた ixp23xx ネットワーク プロセッサを搭載したフィールド上で、製品ソフトウェアを実行しています。フィールドから時折問題が発生し、ラボで再現されることもあります。コンソールには、次の障害行が出力されます。さらに掘り下げると、仮想アドレスが有効な物理アドレスにマップされていないページ テーブル エントリがほとんどないことがわかりました。したがって、これらの仮想アドレスにアクセスすると、不正確なアボートが発生する可能性があります。最終的な解決策は、間違ったマッピングを削除することです。そのため、次回は正確で簡単に検出できるセグメンテーション エラーが発生するはずです。ただし、間違ったエントリを削除するには時間がかかり、デバッグ情報を使用してビルドを作成する必要があるため、このオプションは後で使用します。

質問に戻ると、XSCALE データシートによると、この障害は、X ビット = 0、C ビット = 0、および B ビット = 0 に設定することにより、「完了するまでストール」を使用してほぼ正確 (+3 instr) にすることができます。しかし、Linuxでそれを行う方法が正確にはわかりません。それは役に立ちますか? 基本的に、これは DCACHE を無効にするように見えます。arc/arm/mm/proc-xscale.S の下のコードはすべてアセンブリであり、正確に無効にする方法がわかりません。Kernel Config には CONFIG_CPU_DCACHE_DISABLE というオプションが 1 つあります。これは DCACHE を無効にしているように見えますが、X=C=B ビットが 0 に等しい場合と同じでしょうか? 以下はデータシートからの抜粋です

*

不正確なデータ アボートは、アボート ハンドラが回復するのが困難なシナリオを作成する可能性があります。外部データ アボートとデータ キャッシュ パリティ エラーの両方が原因で、対象のレジスタ データが破損する可能性があります。これらのフォルトは不正確であるため、Data Abort フォルト ハンドラが呼び出される前に、破損したデータが使用されている可能性があります。このため、ソフトウェアは不正確なデータ アボートを回復不能として扱う必要があります。「完了するまで停止」とマークされたメモリ アクセスでさえ (セクション 3.2.2.4 を参照)、不正確なデータ アボートが発生する可能性があります。これらのタイプのアクセスの場合、障害は一般的な場合よりも多少不正確ではありません。障害を引き起こした命令から 3 命令以内で発生することが保証されています。つまり、「完了するまでストール」する LD または ST 命令が不正確なフォルトをトリガーした場合、その場合、その障害はプログラムによって 3 つの命令内で検出されます。MMU が無効になっている場合、すべてのデータ アクセスはキャッシュ不可かつバッファ不可になります。これは、MMU が有効になっている場合と同じ動作であり、データ アクセスでは、X、C、および B がすべて 0 に設定されたディスクリプタが使用されます。X、C、および B ビットは、プロセッサがいつ新しいデータを Dataキャッシュ。キャッシュは、データを行 (ブロックとも呼ばれます) でキャッシュに配置します。したがって、新しいデータをキャッシュに入れるかどうかを決定するための基準は、「ライン割り当てポリシー」と呼ばれます。Line Allocation Policy が read-allocate の場合、キャッシュを逃したすべてのロード操作 データ アクセスでは、X、C、および B がすべて 0 に設定されたディスクリプタが使用されます。X、C、および B ビットは、プロセッサがいつ新しいデータをデータ キャッシュに配置する必要があるかを決定します。キャッシュは、データを行 (ブロックとも呼ばれます) でキャッシュに配置します。したがって、新しいデータをキャッシュに入れるかどうかを決定するための基準は、「ライン割り当てポリシー」と呼ばれます。Line Allocation Policy が read-allocate の場合、キャッシュを逃したすべてのロード操作 データ アクセスでは、X、C、および B がすべて 0 に設定されたディスクリプタが使用されます。X、C、および B ビットは、プロセッサがいつ新しいデータをデータ キャッシュに配置する必要があるかを決定します。キャッシュは、データを行 (ブロックとも呼ばれます) でキャッシュに配置します。したがって、新しいデータをキャッシュに入れるかどうかを決定するための基準は、「ライン割り当てポリシー」と呼ばれます。Line Allocation Policy が read-allocate の場合、キャッシュを逃したすべてのロード操作

*

4

1 に答える 1

2

StrongARMとXScaleはIntel によるカスタム CPU です。他の ARM プロセッサと比較して、いくつかの奇妙な問題があるようです。

$ git checkout v2.6.24.7  # Activate time machine.
$ grep -B1 -A 9 CPU_XSC3 Kconfig 
# XScale Core Version 3
config CPU_XSC3
        bool
        depends on ARCH_IXP23XX || ARCH_IOP13XX || PXA3xx
        default y
        select CPU_32v5
        select CPU_ABRT_EV5T
        select CPU_CACHE_VIVT
        select CPU_CP15_MMU
        select CPU_TLB_V4WBI if MMU
        select IO_36

関連するKconfigはCPU_ABRT_EV5TとCPU_TLB_V4WBI です。これにより、興味のあるものを取得するabort-ev5t.Sとtlb-v4wbi.Sが選択されます。

関数: v5t_early_abort

 * Purpose : obtain information about current aborted instruction.
 * Note: we read user space.  This means we might cause a data
 * abort here if the I-TLB and D-TLB aren't seeing the same
 * picture.  Unfortunately, this does happen.  We live with it.

ほとんどの CPU には個別の I-TLBとD-TLBがないと思います。コードは、フォールトした命令を読み取ってデコードすることにより、フォールト ステータスをエミュレートしようとしています。I-TLB (命令 MMU ページ キャッシュ) とD-TLB (データ MMU ページ キャッシュ) が一致せず、命令メモリの読み取りが異常な動作をする場合があります。

あなたはそれと一緒に住んでいる人ですか？つまり、 ixp23xx XScale3 (XSC3) に個別の I/D変換ルック アサイド バッファー(TLB)があるかどうか知っていますか?

他の奇妙な点はIO_36です。CPU には36 ビットのアドレスがあります。ソースについてはdomain.hを参照してください。ドメインがアドレスの一部になるようです。これは奇妙な効果を引き起こしている可能性がありますが、ざっと見ても何も見つかりませんでした。

申し訳ありませんが、私はあなたの質問に答えていません。これは長いコメントになります。

質問に戻ると、XSCALE データ シートによると、この障害は、X ビット = 0、C ビット = 0、および B ビット = 0 に設定することにより、「完了するまでストール」を使用してほぼ正確に (+3 インスト) 行うことができます。...カーネル構成には1つのオプション、つまりCONFIG_CPU_DCACHE_DISABLEがあります

CONFIG_CPU_DCACHE_DISABLEでは問題は解決しません。および書き込みバッファリングI-cacheは引き続きアクティブです。また、システムは非常に遅くなります。代わりに、カーネル コマンド ライン オプションを使用できます。、、、、および をサポートしています。一部の値は、プラットフォームに適用できない場合があります。CONFIG_CPU_DCACHE_DISABLEでコンパイルするのと同等かもしれません。cachepolicyuncachedbufferedwritethroughwritebackwritealloccachepolicy=uncached

于 2013-05-15T17:20:09.650 に答える