On Fri, Sep 3, 2010 at 1:21 AM, Charles Forsyth wrote:
>>that avoids the exploding 9vx problem. But we need to get a real fix.
>
> i'm sure i posted the real fix to the list (essentially issuing CLD at
> specific points).
>
>
I missed it. If you can point me to it I'll give it a try.
ron
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
>that avoids the exploding 9vx problem. But we need to get a real fix.
i'm sure i posted the real fix to the list (essentially issuing CLD at specific
points).
On Thu, Sep 2, 2010 at 8:05 AM, ron minnich wrote:
> On Thu, Sep 2, 2010 at 4:57 AM, erik quanstrom wrote:
>
>> since 56%4==0, can't you correct the size mismatch by using
>> 32-bit types to prevent 64-bit 9vx from doubling the size?
>
> yep, that's what I'm doing now. I just ran out of time to f
On Thu, Sep 2, 2010 at 4:57 AM, erik quanstrom wrote:
> since 56%4==0, can't you correct the size mismatch by using
> 32-bit types to prevent 64-bit 9vx from doubling the size?
yep, that's what I'm doing now. I just ran out of time to finish it.
ron
On Thu Sep 2 02:38:12 EDT 2010, rminn...@gmail.com wrote:
> OK, the problem with _tos on 9vx is making some sense.
>
> gcc and 8c disagree on the size of the Tos struct. It's declared the
> same way in 9vx as in
> Plan 9, but 8c thinks it is 56 bytes and gcc thinks it is 88.
>
> The reason is th
OK, the problem with _tos on 9vx is making some sense.
gcc and 8c disagree on the size of the Tos struct. It's declared the
same way in 9vx as in
Plan 9, but 8c thinks it is 56 bytes and gcc thinks it is 88.
The reason is that 9vx is compiled on a 64-bit machine in this case,
so we are running 32
> personal opinion: the difficulty of getting this code right, and its
> complexity, tell me something is wrong with the interface. Look at the
> trouble we're going through to get a 64-bit number out of the kernel.
> Look at how hard it is to get right.
>
> Two ways out:
> 1. "reserved" fds. an f
On Tue, Aug 31, 2010 at 5:54 AM, erik quanstrom wrote:
>> A simple change:
>> pid = getpid();
>
> shouldn't you just fix it so _tos->pid is set?
yep. I just have to find the time.
>
> also, the comments in the new nsec.c don't
> match the code. the code looks something like this
>
> do{
> A simple change:
> pid = getpid();
shouldn't you just fix it so _tos->pid is set?
also, the comments in the new nsec.c don't
match the code. the code looks something like this
do{
...
tries = 0;
}while(tries++ == 0); /* retry once */
of cours
I'd been having a problem once I built from source on vx32.
lots of commands would hang until I hit return.
ratrace showed this:
rminn...@xcpu2:~$ more /tmp/problem
ratrace -c /bin/date
24577 date Pread 0x19f6 0
0ee0/"." 8 0 = 1 "" 0x11cef69ae0b06c68 0x11cef69c0a58d900
24577 date Close 0x1a3
11 matches
Mail list logo
