Re:Help: from proc to thread?

2002-06-02 Thread kai ouyang
>> Based on the explain of the thread: struct proc *td_proc; /* Associated process. */ in the struct>> thread.>> and refer to the CCD code.>> I modify this function as following:>> int raidlookup(path, td, vpp)>>  char   *path;>>  struct thread *td;>>  struct vnode **vpp; /* result */>> {>>  struct nameidata nd;>>  struct vnode *vp;>>  struct vattr va;>>  struct proc *p;>>  int error, flags;>>  /* Sanity check the p_fd fields.  This is really just a hack */>>  p = td->td_proc; >So it dies here? >> Now the system will be crash , when it excutes the "p = td->td_proc".>> the system Information is :>> kernel: type 12 trap, code=0>> Stopped at raidlookup+0x19: movl 0(%eax),%ebx >Hmm, can you get the 'faulting va (virtual address)' error message that it>prints out? >Add a line to the beginning of the function as a sanity check that does: >KASSERT(td != NULL, "thread is null"); >and compile your kernel with invariants and see if it panics with>"thread is null". Yeah, thread is NULL.But I view all the callers, I did not find any assignment to td.I do not know the kernel how assign td to the structure.The RAIDFrame has the similar function as the vinum. I find this problem when I config a RAID level volume.Now, I check the raidctlioctl() function,because the process is here from user space to kernel space.Because the raidlookup's td is gotten from raidctlioctl() function.I add the two line to the latter function.KASSERT(td != NULL, ("raidctlioctl thread is NULL"));KASSERT(raidPtr->engine_thread != NULL, ("raidctlioctl engine thread is NULL"));It debugs in the second line. So, the raidctlioctl funcion has the td, but didn't transfer the parameter to the raidlookup().HI take place the two line by the following lines:KASSERT(td != NULL, ("raidctlioctl thread is NULL"));raidPtr->engine_thread = td;KASSERT(raidPtr->engine_thread != NULL, ("raidctlioctl engine thread is NULL"));now it pass. I want to know when the kernel assign td to raidctlioctl function? Now, the RAIDFrame will be crash here: RF_THREADGROUP_WAIT_START(&raidPtr->engine_tg);panic: runq_choose: process 218(raid) in state 3Debugger("panic")Stopped at Debugger+0x40: xorl %eax,%eax raidPtr->engine_tg is the RF_ThreadGroup_s structure. struct RF_ThreadGroup_s { int created; int running; int shutdown; struct  mtx mutex;    int cond;};/* * Wait for all threads to start running */#define RF_THREADGROUP_WAIT_START(_g_) { \ mtx_lock(&(_g_)->mutex); \ while((_g_)->running < (_g_)->created) { \  RF_LTSLEEP(&((_g_)->cond), PRIBIO, "rfwcond", 0, &((_g_)->mutex)); \ } \ mtx_unlock(&(_g_)->mutex); \} RF_LTSLEEP(void *cond, int pri, const char *text, int time, struct mtx *mutex){ return (msleep(cond, mutex, pri, text, time));} I man mtx_lock and find it excute after mtx_init().before the macro RF_THREADGROUP_WAIT_START, it call the rf_mtx_init();int rf_mutex_init(m)struct mtx *m;{ mtx_init(m, "RAIDFrame FreeBSD5.0", MTX_DEF); return (0);}So. I am puzzled about it.´ÓÍøÕ¾µÃµ½¸ü¶àÐÅÏ¢¡£MSN Explorer Ãâ·ÑÏÂÔØ£ºhttp://explorer.msn.com/lccn

>> Based on the explain of the thread: struct proc *td_proc; /* Associated process. */ 
>in the struct
>> thread.
>> and refer to the CCD code.
>> I modify this function as following:
>> int raidlookup(path, td, vpp)
>>  char   *path;
>>  struct thread *td;
>>  struct vnode **vpp; /* result */
>> {
>>  struct nameidata nd;
>>  struct vnode *vp;
>>  struct vattr va;
>>  struct proc *p;
>>  int error, flags;
>>  /* Sanity check the p_fd fields.  This is really just a hack */
>>  p = td->td_proc;

>So it dies here?

>> Now the system will be crash , when it excutes the "p = td->td_proc".
>> the system Information is :
>> kernel: type 12 trap, code=0
>> Stopped at raidlookup+0x19: movl 0(%eax),%ebx

>Hmm, can you get the 'faulting va (virtual address)' error message that it
>prints out?

>Add a line to the beginning of the function as a sanity check that does:

>KASSERT(td != NULL, "thread is null");

>and compile your kernel with invariants and see if it panics with
>"thread is null".

Yeah, thread is NULL.
But I view all the callers, I did not find any assignment to td.
I do not know the kernel how assign td to the structure.
The RAIDFrame has the similar function as the vinum. I find this problem  
when I config a RAID level volume.
Now, I check the raidctlioctl() function,because the process is here from user space 
to  
kernel space.
Because the raidlookup's td is gotten from raidctlioctl() function.
I add the two line to the latter function.
KASSERT(td != NULL, ("raidctlioctl thread is NULL"));
KASSERT(raidPtr->engine_thread != NULL, ("raidctlioctl engine thread is NULL"));
It debugs in the second line. So, the raidctlioctl funcion has the td, but didn't  
transfer the parameter to the raidlookup().
H
I take place the two line by the following lines:
KASSERT(td != NULL, ("raidctlioctl thread is NULL"));
raidPtr->engine_thread = td;
KASSERT(raidPtr->engine_thread != NULL, ("raidctlioctl engin

Re:Help: from proc to thread?

2002-06-02 Thread John Baldwin


On 03-Jun-2002 kai ouyang wrote:
> Yeah, thread is NULL.
> But I view all the callers, I did not find any assignment to td.
> I do not know the kernel how assign td to the structure.
> The RAIDFrame has the similar function as the vinum. I find this problem  
> when I config a RAID level volume.
> Now, I check the raidctlioctl() function,because the process is here from user space 
>to  
> kernel space.
> Because the raidlookup's td is gotten from raidctlioctl() function.
> I add the two line to the latter function.
> KASSERT(td != NULL, ("raidctlioctl thread is NULL"));
> KASSERT(raidPtr->engine_thread != NULL, ("raidctlioctl engine thread is NULL"));
> It debugs in the second line. So, the raidctlioctl funcion has the td, but didn't  
> transfer the parameter to the raidlookup().
> H
> I take place the two line by the following lines:
> KASSERT(td != NULL, ("raidctlioctl thread is NULL"));
> raidPtr->engine_thread = td;
> KASSERT(raidPtr->engine_thread != NULL, ("raidctlioctl engine thread is NULL"));
> now it pass.
> I want to know when the kernel assign td to raidctlioctl function?

The kernel passes the thread pointer for the current thread down the stack to
the ioctl routine.

> Now, the RAIDFrame will be crash here:
>  RF_THREADGROUP_WAIT_START(&raidPtr->engine_tg);
> panic: runq_choose: process 218(raid) in state 3
> Debugger("panic")
> Stopped at Debugger+0x40: xorl %eax,%eax

It looks like you made a thread runnable and then changed it's p_stat
to SSLEEP while it was on the run queue.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message