> > On Sun, Feb 25, 2001 at 10:29:42PM -0800, Kris Kennaway wrote:
> > > This is on a UP system.
> >
> > Had another one of these, under the same conditions. Both times I was
> > running more(1) on a stdin stream which was generated by a "find |
> > grep | more" operation, and I suspended the process with ^Z,
> > triggering the panic. Perhaps this will help in tracking down the
> > root cause.
>
> I'm pretty sure I know what this is; I'll work up a patch tonight.
>
Sorry this is taking so long. Its turned out to be a little more
complex to fix properly than I originally thought. We're going to
have to change the way one of the fields of struct proc (p_pptr)
is locked. The problem is that a process is getting preempted
when its not SRUN, which should be protected by the scheduler
lock so that the preemption can't occur.
This is the best workaround I can think of:
Index: kern/kern_intr.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/kern_intr.c,v
retrieving revision 1.47
diff -u -r1.47 kern_intr.c
--- kern/kern_intr.c 2001/02/28 02:53:43 1.47
+++ kern/kern_intr.c 2001/03/02 02:28:08
@@ -366,7 +366,7 @@
*/
ithread->it_need = 1;
mtx_lock_spin(&sched_lock);
- if (p->p_stat == SWAIT) {
+ if (p->p_stat == SWAIT && curproc->p_stat == SRUN) {
CTR1(KTR_INTR, __func__ ": setrunqueue %d", p->p_pid);
p->p_stat = SRUN;
setrunqueue(p);
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
