Same here.
- Original Message -
From: "Francisco J Ballesteros"
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Sent: Wednesday, September 02, 2009 11:43 AM
Subject: Re: [9fans] "Blocks" in C
IMHO, I'd say C is C and I think it's better to leave
it as it is. If you wan
Thanks for this info Russ.
Can you briefly tell us why you (Russ, Rob, Ken and Dave) no longer use
Plan9 ?
Because of missing apps or because of missing driver for your hardware ?
And do you still use venti ?
Phil;
- Original Message -
From: "Russ Cox"
To: "Fans of the OS Plan 9 fr
Can you tell us why some things are impossible to scale with 5000 posix
threads (and easy to scale with 5000 plan 9 style threads) ?
Is this specific to posix or linux ? Or maybe you will write a paper on this
?
Phil;
- Original Message -
From: "ron minnich" <[EMAIL PROTECTED]>
To: "
That's almost what they do with KSE in FreeBSD (or Scheduler Activation in
NetBSD) right ?
Phil;
I've been writing a lot of Erlang code lately, and I keep thinking about, but
not having too much time to do much about, wanting to have a runtime for the
libthread "threads" that could auto-sc
Sorry for the mistake.
- Original Message -
From: "Noah Evans" <[EMAIL PROTECTED]>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Sent: Thursday, October 09, 2008 12:53 AM
Subject: Re: [9fans] p9p acme freezes on devdraw read in MacOS X
The fixes work very well. Thank you.
On Wed, Oct 8, 200
Could not crash with your program, but it crashed quite fast with this one:
#include
#include
#include
enum {
NPROC=10,
};
void
crproc(void * p)
{
int i = (int)p;
while (1) {
int fd;
char *name = smprint("/tmp/%d", i);
fd = create(name, OWRITE, 0666);
I rewrote a simple version with fork(). And got a crash until I move :
#ifndef __APPLE__
if(!usetty && !nofork && fork() > 0)
_exit(0);
#endif
before mach0init();
Now it no longer crashes.
Phil;
Sorry, I was talking about 9vx/main.c:^main of course.
But forget it, it still crashes ... it just takes more time before crashing.
I suspected the fork in main() because I do not have (for a very very
long time) crash with '-F' flag (ie nofork).
Phil;
Philippe Anel wrote:
I rewrot
centos 5.4 x64 with your 9vx.
ron minnich wrote:
On Fri, May 28, 2010 at 6:40 AM, Philippe Anel wrote:
Could not crash with your program, but it crashed quite fast with this one:
and mine did not crash at all with that one. What system were you on?
ron
FYI, I found that in src/9vx/main.c, in main(), setmach(&mach0) is
called before mach0init() and thus machkeyinit() ... if you move
machkeyinit() from mach0init() to main(), before setmach(&mach0) ... do
you still have a crash ?
BTW, it does not fix the lotsafiles bug ...
Phil;
Charles Forsy
You also have to recompile vx library.
Phil
Brian L. Stuart wrote:
OK, somebody sent a hint that it
might make sense to take the -O3 out
of the make flags. Done.
Result: I can now get through this command:
hget -v http://plan9.bell-labs.com/plan9/download/plan9.iso.bz2>/tmp/iso.bz2
|[2]aux/sta
Hi 9fans,
While reading src/9/port/proc.c:^runproc, I realized that the
following code is called without any lock. I would expect one in order
to walk through the each rq lists, as it is called with interrupt
enabled.
I think this would not crash the system because procs are not
dynamically all
Thank you. That's what I was thinking. I suppose this has been written
like this because traversing the queue might require too much time for
having a lock.
Phil;
Sape Mullender wrote:
Well spotted. But the queue is maintained in a way that
traversing it while it's being changed cannot cause
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
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 unloc
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
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 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.
eel the problem is here, and we can imagine ... why not, the cpu
running proc A blocking on a bus request or something else.
I don't know if the model is good or not ... and as I wrote, this is only
a thougth experiment ... with my poor brain :)
Phil;
Philippe Anel wrote:
I never seen it
logs.hist[i].op = op;
k9logs.hist[i].pc = pc;
k9logs.hist[i].sp = &p;
if (up) {
k9logs.hist[i].p0 = up->pid;
k9logs.hist[i].s0 = up->state;
}
else {
k9logs.hist[i].p0 = 0;
k9logs.hist[i].s0 = 0;
}
if (p) {
k9logs.hist[i].p1 = p->pid;
ash.c with 8c/8l.
When it crashes, you can watch the latest logs with the gdb command
k9logs 100 (it will show you 100 last ops).
Phil;
Bakul Shah wrote:
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 cir
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
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
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
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
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
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;
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
On 7/17/2010 10:33 AM, Skip Tavakkolian wrote:
is there a way to do in acid the equivalent to gdb 'call'?
Did you try to write an acid function with something like this :
*PC=test
where 'test' is the name of the function to call such as:
void test(void)
{
print("hello from test\n");
}
This one sounds like to work (except it does not save registers) ...
defn call(addr)
{
local pco;
// we need stack space, and thus process stopped.
if status(pid) != "Stopped" then {
print("Waiting...\n");
stop(pid);
}
//
Not needed in my opinion. Acid can also helps.
If we decide that function marked for unit testing with a known regexp
such as ending by _Test ...
defn utest()
{
sl = symbols;
while sl do {
s = head sl;
if (regexp(".*_Test", s[0])) then {
call(s[2]);
You'll also have to include Charles's CLD fix. Regarding sched.c, what
do you call a real fix ?
I mean, this hack just works isn't it ?
Phil;
it's done and available. This tree also includes the hack in sched.c
that avoids the exploding 9vx problem. But we need to get a real fix.
ron
Hello,
A 'page-in' occurs on page fault exception, which cannot be masked.
Phil;
Le 22/02/2011 16:10, r...@hemiola.co.uk a écrit :
I'm struggling to understand the ins and outs of the usb ohci driver
(usbohci.c) and have a question (well, several).
If one writes to an endpoint, then "epio" g
Oh, sorry, I forgot that the page-in operation might require an interrupt
from the disk or network controller in order to reload the page.
Phil;
Le 22/02/2011 16:31, Philippe Anel a écrit :
Hello,
A 'page-in' occurs on page fault exception, which cannot be masked.
Phil;
Le 22/
35 matches
Mail list logo
