:Yep, I was aware of this before, but I didn't rip it out since I didn't
:know what Kirk's intentions were. I'm assuming he's got his experience
:with making the BSD/OS vfs reentrant in mind, so I don't want to break
:anything that gets closer to that. A seperate test and then lock would
:not be
On Mon, 28 Jun 1999, Peter Wemm wrote:
> Doug wrote:
> > Please forgive me if this is a naive question, but could this problem a
> lso
> > relate to why starting netscape now panic's my system? I have a UP celeron
> > 300a system and with the most recent -current I can boot fine, startx f
On Sun, 27 Jun 1999, Doug wrote:
> *nod* I will just hang out in windows for a while and check my commit
> mail. If it doesn't get fixed by the time I am ready to go back to beating
> on my serial console project, I'll do just that.
Hah, well some of us aren't quite that lucky :)
I manage
Peter Wemm wrote:
>
> Doug wrote:
> > Please forgive me if this is a naive question, but could this problem a
> lso
> > relate to why starting netscape now panic's my system? I have a UP celeron
> > 300a system and with the most recent -current I can boot fine, startx fine,
> > but as s
Doug wrote:
> Please forgive me if this is a naive question, but could this problem a
lso
> relate to why starting netscape now panic's my system? I have a UP celeron
> 300a system and with the most recent -current I can boot fine, startx fine,
> but as soon as I try to start netscape th
Please forgive me if this is a naive question, but could this problem also
relate to why starting netscape now panic's my system? I have a UP celeron
300a system and with the most recent -current I can boot fine, startx fine,
but as soon as I try to start netscape the system locks and rebo
Matthew Dillon wrote:
> :
> :But that doesn't fix the UP problem where cluster_wbuild() tries to
> :recursively re-lock a buf that the current process already owns. I have a
> :few ideas about that one though, I just don't understand the clustering
> :well enough yet to fix it.
>
> Ok, I jus
:
:But that doesn't fix the UP problem where cluster_wbuild() tries to
:recursively re-lock a buf that the current process already owns. I have a
:few ideas about that one though, I just don't understand the clustering
:well enough yet to fix it.
Ok, I just hit this testing the lockmgr chang
:In the long term, we probably need an spl-aware simplelock or maybe the
:cunning no-cost interrupt thread scheme which BSDi are using.
:
:--
:Doug RabsonMail: [EMAIL PROTECTED]
:Nonlinear Systems Ltd. Phone: +44 181 442 9037
I really like the idea
:It seems to me the main problem (so far) is the buftimelock..
:
:simple_lock(&buftimelock);
:bp->b_lock.lk_wmesg = buf_wmesg;
:bp->b_lock.lk_prio = PRIBIO + 4;
:bp->b_lock.lk_timo = 0;
:return (lockmgr(&(bp)->b_lock, locktype, &buftimelock, curproc));
:
:
Doug Rabson wrote:
> On Sun, 27 Jun 1999, Peter Wemm wrote:
>
> > Doug Rabson wrote:
> > > On Sun, 27 Jun 1999, Peter Wemm wrote:
> > >
> > > > Matthew Dillon wrote:
> > > > > Ah, yes, some of us were just discussing this in a small mailing
list
> > .
> > > > > Hopefully Kirk wi
On Sun, 27 Jun 1999, Peter Wemm wrote:
> Doug Rabson wrote:
> > On Sun, 27 Jun 1999, Peter Wemm wrote:
> >
> > > Matthew Dillon wrote:
> > > > Ah, yes, some of us were just discussing this in a small mailing list
> .
> > > > Hopefully Kirk will pick up on it soon. Ah well.. someone
Doug Rabson wrote:
> On Sun, 27 Jun 1999, Peter Wemm wrote:
>
> > Matthew Dillon wrote:
> > > Ah, yes, some of us were just discussing this in a small mailing list
.
> > > Hopefully Kirk will pick up on it soon. Ah well.. someone else gets
to b
> > e
> > > the brunt of i
On Sun, 27 Jun 1999, Peter Wemm wrote:
> Matthew Dillon wrote:
> > Ah, yes, some of us were just discussing this in a small mailing list.
> > Hopefully Kirk will pick up on it soon. Ah well.. someone else gets to b
> e
> > the brunt of it for a change :-). Kirk doesn't have an S
Matthew Dillon wrote:
> Ah, yes, some of us were just discussing this in a small mailing list.
> Hopefully Kirk will pick up on it soon. Ah well.. someone else gets to b
e
> the brunt of it for a change :-). Kirk doesn't have an SMP box so he
> didn't see the bug.
>
> I
In message <[EMAIL PROTECTED]>, Peter Wemm writes:
>Speaking of SMP and simple locks, I'd like to turn on the debugging
>simplelocks that keep a reference count and check before switching to make
>sure that a process doesn't sleep holding a lock. This is a pretty
>fundamental sanity check and wo
Matthew Dillon wrote:
> Ah, yes, some of us were just discussing this in a small mailing list.
> Hopefully Kirk will pick up on it soon. Ah well.. someone else gets to b
e
> the brunt of it for a change :-). Kirk doesn't have an SMP box so he
> didn't see the bug.
>
> I
Ah, yes, some of us were just discussing this in a small mailing list.
Hopefully Kirk will pick up on it soon. Ah well.. someone else gets to be
the brunt of it for a change :-). Kirk doesn't have an SMP box so he
didn't see the bug.
I have tentitively tracked the problem do
panic: lockmgr: locking against myself
Debugger("panic")
Stopped at Debugger+0x37: movl$0,in_Debugger
db> trace
Debugger(c024333b) at Debugger+0x37
panic(c0242560,c3337df8,c32f4ed8,c76bd2c0,14d) at panic+0x74
lockmgr(c3337e20,12,c029f320,c6c90a20) at lockmgr+0x20b
cluster_wbuild(c76bd2c0
19 matches
Mail list logo
