Re: [9fans] That deadlock, again

[erik quanstrom <quanstro@labs.coraid.com>]

> 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