On Nov,Wednesday 24 2010, at 5:35 AM, David Holland wrote:
> On Tue, Nov 23, 2010 at 11:13:02PM +, David Holland wrote:
>> However, I discovered today that rumpfs's VOP_LOOKUP implementation
>> relies on being able to access not just the name to be looked up, but
>> also the rest of the pathn
On Tue, Nov 23, 2010 at 11:13:02PM +, David Holland wrote:
> However, I discovered today that rumpfs's VOP_LOOKUP implementation
> relies on being able to access not just the name to be looked up, but
> also the rest of the pathname namei is working on, specifically
> including the parts th
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> > (The soft int may vary). Looking at the sources, I see that
> > sched_nextlwp() is carefull to not propose a new lwp if a migration is
> > in progress. But when this KASSERT fires we're not necesserely about to
> > switch to a new (non-idle) lwp,
On Tue, Nov 23, 2010 at 06:49:47PM +0200, Antti Kantee wrote:
> On Fri Nov 19 2010 at 00:11:12 +, Andrew Doran wrote:
> > You can release it with either call, mutex_spin_ is just a way to avoid
> > additional atomic operations. The ususal case is adaptive mutex, but
> > stuff like the dispatch
I have run into a problem fixing namei.
First, background: VOP_LOOKUP is the per-fs vnode operation that takes
a directory and a name and returns the vnode associated with that
name. This currently has a horrific interface and the chief goal of
the namei cleanup is to rectify this so all it needs
hi,
> Hello,
> working with a source code based on the matt-nb5-mips64 branch,
> I can reproduce this panic:
> panic: kernel diagnostic assertion "spc->spc_migrating == NULL" failed: file
> "/dsk/l1/misc/bouyer/tmp/src/sys/kern/kern_synch.c", line 656
> mttycn_pollc 1 ipl 0x6
> Stopped in pid 0.4
On Fri Nov 19 2010 at 00:11:12 +, Andrew Doran wrote:
> You can release it with either call, mutex_spin_ is just a way to avoid
> additional atomic operations. The ususal case is adaptive mutex, but
> stuff like the dispatcher/scheduler makes use of spin mutexes exclusively
> and the fast path
