> I suggest you fix ether82598: it is OK to call qlock() and qunlock()
> without "up", but only if sure that the qlock() will succeed. If it
> has to wait, it will panic.
yes. that's it.
> >If it has to wait, it will panic. Given that, why do the locking at all?
>
> i assume the intention is along these lines:
>
> it's to allow the use during reset of a given driver's
> standard functions that normally must qlock, to avoid requiring two copies
> of them, with and without the qlock.
>
> after reset, it's illegal to call qlock without a process (notably
> in an interrupt function), as it previously was.
i think lucio has stated the current restriction more exactly,
but this is closer to the assumed intent. perhaps we should make
this what qlock actually does with
diff -c /n/dump/2010/1118/sys/src/9/pc/main.c pc/main.c
/n/dump/2010/1118/sys/src/9/pc/main.c:201,206 - pc/main.c:201,207
poperror();
}
kproc("alarm", alarmkproc, 0);
+ conf.postdawn = 1;
touser(sp);
}
diff -c /n/dump/2010/1118/sys/src/9/pc/dat.h pc/dat.h
/n/dump/2010/1118/sys/src/9/pc/dat.h:107,112 - pc/dat.h:107,113
ulong ialloc; /* max interrupt time allocation in bytes */
ulong pipeqsize; /* size in bytes of pipe queues */
int nuart; /* number of uart devices */
+ int postdawn; /* mutiprogramming on */
};
/*
diff -c /n/dump/2010/1118/sys/src/9/port/qlock.c port/qlock.c
/n/dump/2010/1118/sys/src/9/port/qlock.c:18,23 - port/qlock.c:18,25
{
Proc *p;
+ if(up == nil && conf.postdawn)
+ panic("qlock: %#p: postdawn up nil\n", getcallerpc(&q));
if(m->ilockdepth != 0)
print("qlock: %#p: ilockdepth %d\n", getcallerpc(&q),
m->ilockdepth);
if(up != nil && up->nlocks.ref)
a test kernel i've got does boot with this test.
- erik
