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 
> 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().
> Hmmmm....
> 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

Reply via email to