>> Actually, I can't help wondering how this *ever* worked.  There was
>> a time when that diskless machine worked fine with my NFS server,
>> and I haven't changed anything since then that I can see affecting
>> this.
> Except you upgraded. :-)

I don't *think* so.  I've been using 2000-02-19 sources since, well,
February last year.  And I set up that NFS server a matter of weeks
ago.  I find it difficult to believe I had a kernel a year old still
kicking around.

What's more, I don't think I touched *anything* on the server between
setting it up and noticing the crash.

Well, not that it matters much.

>>> Could you try changing the genfs_no{,is,un}lock{,ed} calls into the
>>> real-lock varieties and see what happens?
>> I didn't try that, since [...]
> If you can, please try it.

I probably can.  Would you rather I make the no* routines do real
locking, or that I change specfs's vnopeops to use the real-locking
routines?

Do you also want me to back out the VOP_UNLOCK I added?  (Presumably,
since otherwise, what's to tell whether it works?)

>> What I did do, and it seems to have made the problem go away, is
>> +++ ufs_vnops.c	Tue Mar 13 01:00:13 2001
>> +			VOP_UNLOCK(vp,0);
> That actually is the other way to fix the problem, though with doing
> this the vput really should be a vrele() (since otherwise you're
> implicitly relying on specfs using the nolock routines :-)

Ah, now, that's the sort of thing I meant when I wrote of someone
actually understanding the code. :-)

> We either: 1) [...], 2) [...], or 3) [...]

Actually, why mess with the v_op pointer at all?  (I don't understand
the code enough to see why that's being done.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B