[Suzaku:01529] Re: エラー表示の解析方法について

菊地 義和 email@hidden
2009年 6月 24日 (水) 14:55:18 JST


溝渕様

菊地です。お返事ありがとうございます。

もう少し、説明させてください。

> 自分で書いたコードで直接実行していなくても、カーネルで用意されている関数
> を使用している場合は、呼ばれる可能性はあると思います。

カーネルで用意されている関数は使用していないので
わからなくなっています。

次のコードの中で落ちていることはわかっておりますが、
原因が推測できません。
そもそも、確認の仕方がよくないのではないか、
あるいは、仕組み(関数の構造)がよくないのではないか
と思ったりし始めたのですが、関係あるでしょうか。
それに関係してですが、キャッシュの関数を実行している
ようです。キャッシュについて関係するでしょうか。

発生しているコード
-------------------------------------------
 printk("aaaaaa !!.\n");←ここまではログに記録されています。
    i = 0;
    barrier();
    while( 1 ) {
     if ( i > 1600000 ) {// 約450msec
      break;
     }
    barrier();
     i++;
    barrier();
    }
 printk("i = %d\n",i);
------------------------------------------

仕組み;
------------------------------------------
whike(1)
{
    関数 f( );
    if(条件1)break;
}

(間略)

void 関数f()
{
    上記発生しているコードを含む
}
------------------------------------------
>
> 例えば、printk()しか使っていなくても、vprintk()が呼ばれたりすると思います。 
> 

はい、この辺りは意識しているつもりです。

>
> エラー発生場所から、grepやetagsやglobalを使うなどして追っていくと
> kmem_cache_allocにたどりつくと思います。


以上
----- Original Message ----- 
From: "mizo" <email@hidden>
To: "菊地 義和" <email@hidden>; "SUZAKU general discussion list" 
<email@hidden>
Sent: Wednesday, June 24, 2009 1:45 PM
Subject: Re: [Suzaku:01527] Re: エラー表示の解析方法について


> 溝渕です。
>
> 菊地 義和 wrote:
>> c0045bdc <kmem_cache_alloc>:
>> c0045bdc: 3021ffe0  addik r1, r1, -32
>> c0045be0: f9e10000  swi r15, r1, 0
>> c0045be4: fa61001c  swi r19, r1, 28
>> c0045be8: 96710002  msrclr r19, 2
>> c0045bec: 80000000  or r0, r0, r0
>> c0045bf0: e8e50000  lwi r7, r5, 0        ←RPCはここを指していました。
>> c0045bf4: e8870000  lwi r4, r7, 0
>> c0045bf8: 3104ffff  addik r8, r4, -1
>> c0045bfc: 64680402  bslli r3, r8, 2
>> c0045c00: be040034  beqid r4, 52  // c0045c34
>>
>> それで、続いてアドバイスいただけますでしょうか。
>>
>> ・インストラクション「lwi r7, r5, 0」は
>> 「kmem_cache_alloc」というラベル(関数)の内部であると
>> 理解しましたが、そうでしょうか。
> そうです。
>
>> ・関数「kmem_cache_alloc」は当方のソフトからは
>> 実行していないのですが、どのようなときに実行される
>> と考えられるのでしょうか。
> 自分で書いたコードで直接実行していなくても、カーネルで用意されている関数
> を使用している場合は、呼ばれる可能性はあると思います。
>
> 例えば、printk()しか使っていなくても、vprintk()が呼ばれたりすると思います。 
> 
>
> エラー発生場所から、grepやetagsやglobalを使うなどして追っていくと
> kmem_cache_allocにたどりつくと思います。
>
>> ・先にお送りしたレジスタ情報と上記逆アセンブルの
>> 結果から、次に確認すべき点はどのような箇所になる
>> のでしょうか。
> lwi r7, r5, 0
> で使用しているレジスタの値を確認して、それらの値が適切であるかどうかを判
> 断します。 




suzaku メーリングリストの案内