On Sun, Jun 13, 2010 at 11:03 AM, Philippe Anel wrote:
> I tried with adding :
>
> while (p->mach)
> sched_yield();
>
>
> at the end of sched.c:^runproc(), before the return.
>
> It seems to work well.
>
> What do you think ?
Not sure I understand all the implications but I'll try anythin
If anyone can help me with some valgrind patches we can see if
valgrind can be useful.
Charles, I am really puzzled about your ubuntu experience.
Oh, wait, can you set
LANG=C
and try again? Or is it?
BTW when you get the immediate explosion does a window even ever come
up or does it die before
Charles,
Can you please give us stack information with gdb ?
Phil;
On Mon, 2010-06-14 at 20:15 +0100, Charles Forsyth wrote:
> it's interesting that neither of philippe's changes,
> however justified, make any visible difference
> to 9vx on my ubuntu 10.04LTS system: 9vx still
> fails almost imm
it's interesting that neither of philippe's changes,
however justified, make any visible difference
to 9vx on my ubuntu 10.04LTS system: 9vx still
fails almost immediately. that's consistent with
9vx behaving itself as well as on any other platform
until i changed the linux and/or ubuntu version.
i
i wasn't clear enough what i meant by `interrupt handler'. i didn't mean
the device-specific function, but its caller. in pc/trap.c you see
if(up && !clockintr)
preempted();
and on other platforms (perhaps not enough) there are calls to preemp
I tried with adding :
while (p->mach)
sched_yield();
at the end of sched.c:^runproc(), before the return.
It seems to work well.
What do you think ?
Phil;
Hi,
The solution is not that simple. I mean when kprocs go to sleep
through the call to psleep(), a pwakeup() is required. We cannot
simply change the following sched.c:^runproc() part :
while((p = kprocq.head) == nil){
by:
while(((p = kprocq.head) == nil) || p->mach){
The a/proc.c sche
Should be, at least I think so. But I don't even know yet how we can do
this. :)
I think we can use the go trick and postpone the call to ready() while
p->mach != 0.
But I don't know where yet.
Phil;
ron minnich wrote:
On Sun, Jun 13, 2010 at 7:26 AM, Philippe Anel wrote:
In fact you'r
On Sun, Jun 13, 2010 at 7:26 AM, Philippe Anel wrote:
> In fact you're right, and this shows us this would only happens to 9vx.
> Indeed, the proc is a kproc and thus is not scheduled by the 9vx/a/proc.c
> scheduler,
> but by the one in 9vx/sched.c ... where dequeueproc() is not called and
> where
In fact you're right, and this shows us this would only happens to 9vx.
Indeed, the proc is a kproc and thus is not scheduled by the
9vx/a/proc.c scheduler,
but by the one in 9vx/sched.c ... where dequeueproc() is not called and
where p->mach
is not checked.
Thank you !
Phil;
Richard Miller
> that's only because the clock interrupt handler directly or indirectly (eg,
> via sched) calls spllo, and other trap or interrupt handlers could do that.
wouldn't that be fatal with shared 8259 interrupts?
- erik
Philippe said:
> Again, the change I proposed is not about sleep/wakeup/postnote, but
> because wakeup() is ready()'ing the awakened process while the mach on
> which sleep() runs is still holdind a pointer (up) to the awakened
> process and can later (in schedinit()) assumes it is safe to access
> - splhi -- it's not a true splhi in some sense; is it possible that
> some code is sneaking in and running even when you splhi()? Could this
> explain it?
The error Philippe has found is only indirectly related to splhi().
It's a race between a process in sleep() returning to the scheduler on
cp
> FYI, I've wondered if they had the same problem in go runtime because
> I suspected the code to be quite similar. And I think go team fixed the
> problem in ready() equivalent in go runtime, by adding a flag in Proc
> equivalent so the proc (G in go) is put back to the run queue ...
are you sure
On Sat, Jun 12, 2010 at 3:15 PM, Charles Forsyth wrote:
>>in Linux parlance, Plan 9 is a "preemptible" kernel. Interrupt handlers can
>>be interrupted, so to speak.
>
> interrupt handlers are not normally interruptible during the interrupt
> processing, but rather at the end (eg, when anyhigher,
>in Linux parlance, Plan 9 is a "preemptible" kernel. Interrupt handlers can be
>interrupted, so to speak.
interrupt handlers are not normally interruptible during the interrupt
processing, but rather at the end (eg, when anyhigher, anyready or preempted
is called).
processes running at non-inte
There's kind of an interesting similarity here to what I had to deal
with on the Xen port.
So, a few random thoughts, probably useless, from early problems of
this sort I've had.
- in Linux parlance, Plan 9 is a "preemptible" kernel. Interrupt
handlers can be interrupted, so to speak. Except for
> - does richard miller's alternate implementation of wakeup
> solve this problem.
No, it doesn't.
9fans,
FYI, I've wondered if they had the same problem in go runtime because
I suspected the code to be quite similar. And I think go team fixed the
problem in ready() equivalent in go runtime, by adding a flag in Proc
equivalent so the proc (G in go) is put back to the run queue ...
Phil;
In
Hi,
I really think the spin model is good. And in fact, I really think
current sleep/wakeup/postnote code is good. However, this model makes
the assumption that plan9 processes are really Machs and not coroutines.
I think we need a larger model, which includes the scheduler.
I mean a model th
You can download my own (ugly) 9vx source code here :
http://www.bouyapop.org/9vxigh.tar.bz2
In 9vx you'll find .gdbinit and crash.c.
Just copy it to vx32 and replace 9vx folder, compile it and execute it
under gdb with you own 9vx env.
(gdb) r -F -r
then compile and execute crash.c
> I haven't used promela so can't say anything about it.
http://spinroot.com/spin/Man/index.html
- erik
On Fri, 11 Jun 2010 19:31:58 +0200 Philippe Anel wrote:
>
> I only did my tests on 9vx. I have a version that I instrumented with
> a circular log buffer, and I have some gdb macros which dumps the
> buffer.
>
> I can put the whole source somewhere and even a log with my comments
> of the bug i
I only did my tests on 9vx. I have a version that I instrumented with
a circular log buffer, and I have some gdb macros which dumps the
buffer.
I can put the whole source somewhere and even a log with my comments
of the bug if you want to see it. But please note that I made several
changes (beca
On Fri, 11 Jun 2010 16:59:42 +0200 Philippe Anel wrote:
> Ooops I forgot to answer this :
> > - does changing spl* to manipulation of a per-cpu lock solve the problem?
> > sometimes preventing anything else from running on your mach is
> > exactly what you want.
> >
> No ... I don't think so.
On Fri, Jun 11, 2010 at 8:04 AM, erik quanstrom wrote:
> please wait. we still don't understand this problem
> very well. (why does this work on real hardware?)
all the 9vx failures I have seen are with the kexec threads. This is a
major 0vx change from 9. I do think that there is something in
Oooops ... sorry for double copy :) The post was supposed to be :
I never seen it on real hardware but I think it does not mean it
cannot happen. The problem in 9vx comes from the fact 9vx Mach are
simulated by pthreads which can be scheduled just before calling
gotolabel in sleep(). This gives
I never seen it on real hardware but I think it does not mean it
cannot happen. The problem in 9vx comes from the fact 9vx Mach are
simulated by pthreads which can be scheduled just before calling
gotolabel in sleep(). This gives the time to another Mach (or pthread)
to 'readies' the proc A.
On Fri Jun 11 10:54:40 EDT 2010, x...@bouyapop.org wrote:
> I don't think either splhi fixes the problem ... it only hides it for
> the 99.9% cases.
on a casual reading, i agree. unfortunately,
the current simplified promela model disagrees,
and coraid has run millions of cpu-hrs on quad
On Fri Jun 11 11:03:32 EDT 2010, rminn...@gmail.com wrote:
> I'm going to put this change into my hg repo for 9vx and do some
> testing; others are welcome to as well.
>
> That's a pretty interesting catch.
please wait. we still don't understand this problem
very well. (why does this work on re
I'm going to put this change into my hg repo for 9vx and do some
testing; others are welcome to as well.
That's a pretty interesting catch.
ron
On Fri, Jun 11, 2010 at 2:49 PM, Philippe Anel wrote:
> Schedinit() initialize the scheduler label ... on which sleep() goes when
> calling gotolabel(&m->sched).
>
> Phil;
yep. Toldja I was not awake yet.
ron
Ooops I forgot to answer this :
- does changing spl* to manipulation of a per-cpu lock solve the problem?
sometimes preventing anything else from running on your mach is
exactly what you want.
No ... I don't think so. I think the problem comes from the fact the
process is no longer exclusivel
I don't think either splhi fixes the problem ... it only hides it for
the 99.9% cases.
Phil;
erik quanstrom wrote:
schedinit only runs once and sleep runs all the time. That's the part
I don't get.
gotolabel in sleep sends you back to the
setlabel at the top of schedinit.
B
> schedinit only runs once and sleep runs all the time. That's the part
> I don't get.
gotolabel in sleep sends you back to the
setlabel at the top of schedinit.
> But you might have found something, I sure wish I understood it all better :-)
i'm not entirely convinced that the problem isn't the
Schedinit() initialize the scheduler label ... on which sleep() goes
when calling gotolabel(&m->sched).
Phil;
ron minnich wrote:
I'll look but one thing doesn't make sense to me:
On Fri, Jun 11, 2010 at 2:06 PM, Philippe Anel wrote:
// xigh: move unlocking to schedinit()
I'll look but one thing doesn't make sense to me:
On Fri, Jun 11, 2010 at 2:06 PM, Philippe Anel wrote:
> // xigh: move unlocking to schedinit()
schedinit only runs once and sleep runs all the time. That's the part
I don't get.
But you might have found something, I sure wish I unde
Dear 9fans,
I think I maybe have found the reason why some of us have a *double
sleep* error while running 9vx. I think this would even explain some
segmentation faults seen in kprocs.
Please forgive me for the length of this post. I'm trying to be as
explicit as possible.
I have no certainty
38 matches
Mail list logo
