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
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/02/2011 16
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
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]);
}
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
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 x...@bouyapop.org 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
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
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;
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 x...@bouyapop.org wrote:
// xigh: move unlocking
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.
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
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.
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 on real hardware
:
On Fri, 11 Jun 2010 16:59:42 +0200 Philippe Anel x...@bouyapop.org 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
and execute crash.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 x...@bouyapop.org wrote:
I only did my tests on 9vx. I have a version that I
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
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
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
Could not crash with your program, but it crashed quite fast with this one:
#include u.h
#include libc.h
#include thread.h
enum {
NPROC=10,
};
void
crproc(void * p)
{
int i = (int)p;
while (1) {
int fd;
char *name = smprint(/tmp/%d, i);
fd = create(name,
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 rewrote a simple
centos 5.4 x64 with your 9vx.
ron minnich wrote:
On Fri, May 28, 2010 at 6:40 AM, Philippe Anel x...@bouyapop.org 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
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 r...@swtch.com
To: Fans of the
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, 2008 at
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: Fans
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
33 matches
Mail list logo
