[9fans] problem with rminnich's 9vx

[9fans] problem with rminnich's 9vx

[Mathieu Lonjaret]

Hi all, 

this is probably trivial; this is what I get when trying to start 9vx:

Warning! factotum can't protect itself from debugging: '#p/5' file does not exist
init: warning: can't open #p/2/ctl: '#p/2' file does not exist

init: starting /bin/rc
FAILED
Warning! auth/factotum can't protect itself from debugging: '#p/64' file does not exist
rio: can't open display: initdisplay: /dev/draw/new: no frame buffer
init: rc exit status: rio 9: display open

init: starting /bin/rc
#d/0: rc: .: can't open: '#d/0' file does not exist
init: rc exit status: rc 67: error

init: starting /bin/rc
#d/0: rc: .: can't open: '#d/0' file does not exist
init: rc exit status: rc 68: error

this last error keeps on repeating.
as a plan 9 tree I'm using the same old one that I kept using with rsc's
9vx (minimal tree provided by rsc, and later filled with more plan 9
stuff), could that be the issue? if yes, what do you guys for a tree
with ron's 9vx?

uname -a:
Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011 x86_64 GNU/Linux

Cheers,
mathieu

[9fans] problem with rminnich's 9vx

[Noah Evans]

I've seen this behavior before, once using 9vx on a remote xsession
and once when using strace on a (broken) 9vx that was compiled for
32bit on a 64bit linux. Are there any mitigating factors that could be
causing your problem?

Noah



On Tue, Mar 29, 2011 at 11:00 AM, Mathieu Lonjaret
<mathieu.lonjaret at gmail.com> wrote:
> Hi all,
>
> this is probably trivial; this is what I get when trying to start 9vx:
>
> Warning! factotum can't protect itself from debugging: '#p/5' file does not exist
> init: warning: can't open #p/2/ctl: '#p/2' file does not exist
>
> init: starting /bin/rc
> FAILED
> Warning! auth/factotum can't protect itself from debugging: '#p/64' file does not exist
> rio: can't open display: initdisplay: /dev/draw/new: no frame buffer
> init: rc exit status: rio 9: display open
>
> init: starting /bin/rc
> #d/0: rc: .: can't open: '#d/0' file does not exist
> init: rc exit status: rc 67: error
>
> init: starting /bin/rc
> #d/0: rc: .: can't open: '#d/0' file does not exist
> init: rc exit status: rc 68: error
>
> this last error keeps on repeating.
> as a plan 9 tree I'm using the same old one that I kept using with rsc's
> 9vx (minimal tree provided by rsc, and later filled with more plan 9
> stuff), could that be the issue? if yes, what do you guys for a tree
> with ron's 9vx?
>
> uname -a:
> Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011 x86_64 GNU/Linux
>
> Cheers,
> mathieu
>
>
>

[9fans] problem with rminnich's 9vx

[Mathieu Lonjaret]

Nothing remote or fancy here, just starting 9vx locally (-u glenda -r
plan9vx) after having built it.
However, it is a 64 bits linux and I haven't done anything special or
set any flag when building (cd src; make; make install). Should I?

On Tue, Mar 29, 2011 at 11:18 AM, Noah Evans <noah.evans at gmail.com> wrote:
> I've seen this behavior before, once using 9vx on a remote xsession
> and once when using strace on a (broken) 9vx that was compiled for
> 32bit on a 64bit linux. Are there any mitigating factors that could be
> causing your problem?
>
> Noah
>
>
>
> On Tue, Mar 29, 2011 at 11:00 AM, Mathieu Lonjaret
> <mathieu.lonjaret at gmail.com> wrote:
>> Hi all,
>>
>> this is probably trivial; this is what I get when trying to start 9vx:
>>
>> Warning! factotum can't protect itself from debugging: '#p/5' file does not exist
>> init: warning: can't open #p/2/ctl: '#p/2' file does not exist
>>
>> init: starting /bin/rc
>> FAILED
>> Warning! auth/factotum can't protect itself from debugging: '#p/64' file does not exist
>> rio: can't open display: initdisplay: /dev/draw/new: no frame buffer
>> init: rc exit status: rio 9: display open
>>
>> init: starting /bin/rc
>> #d/0: rc: .: can't open: '#d/0' file does not exist
>> init: rc exit status: rc 67: error
>>
>> init: starting /bin/rc
>> #d/0: rc: .: can't open: '#d/0' file does not exist
>> init: rc exit status: rc 68: error
>>
>> this last error keeps on repeating.
>> as a plan 9 tree I'm using the same old one that I kept using with rsc's
>> 9vx (minimal tree provided by rsc, and later filled with more plan 9
>> stuff), could that be the issue? if yes, what do you guys for a tree
>> with ron's 9vx?
>>
>> uname -a:
>> Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011 x86_64 GNU/Linux
>>
>> Cheers,
>> mathieu
>>
>>
>>
>

[9fans] problem with rminnich's 9vx

[Noah Evans]

I don't know enough about the causes to be of much help. Ron, Yiyus or
Russ might know.

Noah



On Tue, Mar 29, 2011 at 11:25 AM, Mathieu Lonjaret
<mathieu.lonjaret at gmail.com> wrote:
> Nothing remote or fancy here, just starting 9vx locally (-u glenda -r
> plan9vx) after having built it.
> However, it is a 64 bits linux and I haven't done anything special or
> set any flag when building (cd src; make; make install). Should I?
>
> On Tue, Mar 29, 2011 at 11:18 AM, Noah Evans <noah.evans at gmail.com> wrote:
>> I've seen this behavior before, once using 9vx on a remote xsession
>> and once when using strace on a (broken) 9vx that was compiled for
>> 32bit on a 64bit linux. Are there any mitigating factors that could be
>> causing your problem?
>>
>> Noah
>>
>>
>>
>> On Tue, Mar 29, 2011 at 11:00 AM, Mathieu Lonjaret
>> <mathieu.lonjaret at gmail.com> wrote:
>>> Hi all,
>>>
>>> this is probably trivial; this is what I get when trying to start 9vx:
>>>
>>> Warning! factotum can't protect itself from debugging: '#p/5' file does not exist
>>> init: warning: can't open #p/2/ctl: '#p/2' file does not exist
>>>
>>> init: starting /bin/rc
>>> FAILED
>>> Warning! auth/factotum can't protect itself from debugging: '#p/64' file does not exist
>>> rio: can't open display: initdisplay: /dev/draw/new: no frame buffer
>>> init: rc exit status: rio 9: display open
>>>
>>> init: starting /bin/rc
>>> #d/0: rc: .: can't open: '#d/0' file does not exist
>>> init: rc exit status: rc 67: error
>>>
>>> init: starting /bin/rc
>>> #d/0: rc: .: can't open: '#d/0' file does not exist
>>> init: rc exit status: rc 68: error
>>>
>>> this last error keeps on repeating.
>>> as a plan 9 tree I'm using the same old one that I kept using with rsc's
>>> 9vx (minimal tree provided by rsc, and later filled with more plan 9
>>> stuff), could that be the issue? if yes, what do you guys for a tree
>>> with ron's 9vx?
>>>
>>> uname -a:
>>> Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011 x86_64 GNU/Linux
>>>
>>> Cheers,
>>> mathieu
>>>
>>>
>>>
>>
>

[9fans] problem with rminnich's 9vx

[yy]

ron's 9vx and mine are compiled differently in 64bits systems, so you
can try mine and see if there is any difference, but I don't really
know. I don't have any x86_64 system I can use to test 9vx, so please
let me know if things get better (or worse). If you don't want to
download the whole vx32 tree again you can just rollback the last
changes by ron and compile that, the result will be the same.

> what do you guys for a tree
> with ron's 9vx?

For testing, I always use a plan9.iso file (a full tree can solve some
problems but I don't think it will solve yours). When I need write
permissions I use a kfs file I filled with the contents of the iso.


-- 
- yiyus || JGL .

[9fans] problem with rminnich's 9vx

[Mathieu Lonjaret]

Good call; yours starts without a problem, thanks.

On Tue, Mar 29, 2011 at 11:47 AM, yy <yiyu.jgl at gmail.com> wrote:
> ron's 9vx and mine are compiled differently in 64bits systems, so you
> can try mine and see if there is any difference, but I don't really
> know. I don't have any x86_64 system I can use to test 9vx, so please
> let me know if things get better (or worse). If you don't want to
> download the whole vx32 tree again you can just rollback the last
> changes by ron and compile that, the result will be the same.
>
>> what do you guys for a tree
>> with ron's 9vx?
>
> For testing, I always use a plan9.iso file (a full tree can solve some
> problems but I don't think it will solve yours). When I need write
> permissions I use a kfs file I filled with the contents of the iso.
>
>
> --
> - yiyus || JGL .
>

[9fans] problem with rminnich's 9vx

[Christoph Lohmann]

Hello,

Mathieu Lonjaret wrote:
>
> this last error keeps on repeating.
> as a plan 9 tree I'm using the same old one that I kept using with rsc's
> 9vx (minimal tree provided by rsc, and later filled with more plan 9
> stuff), could that be the issue? if yes, what do you guys for a tree
> with ron's 9vx?

the bug is easy to solve [0]. Ron didn't integrate my patch
for this one for a long time, so I started my own repository
of 9vx.

I tried to solve the problem by resolving all sprint() occur-
ences in the Plan 9 kernel and that way in 9vx too. The patch
wasn't accepted; sprint() needs to be fixed.


Sincerely,

Christoph Lohmann

[0] http://git.r-36.net/vx32/commit/?id=d6e5c080a23fcb914b740db48573305f3712eba0

[9fans] problem with rminnich's 9vx

[ron minnich]

This one is extremely weird.

On Tue, Mar 29, 2011 at 2:00 AM, Mathieu Lonjaret
<mathieu.lonjaret at gmail.com> wrote:
> Hi all,
>
> this is probably trivial; this is what I get when trying to start 9vx:
>
> Warning! factotum can't protect itself from debugging: '#p/5' file does not exist
> init: warning: can't open #p/2/ctl: '#p/2' file does not exist

If #p does not work, well! things are seriously wrong. Do you ever get
an rc prompt?

Oh, I see; it's the ubuntu + sprintf problem. I should have taken
Christoph's patch, sorry about that; my fault.

As to your other questions. There's no real reason to build 9vx as a
64-bit binary, and it causes a lot of headaches, so I stick with a
32-bit version nowadays; also, I build all my binaries using my
sysfromiso repo as a starting point. In fact I build all my arm
kernels on 9vx using sysfromiso and use 9vx as the server for the root
file system for the ARMs. In spite of everything I much prefer hg to
replica.

We need a better way to keep 9vx going than just "Ron's version" or
"Joe's version" or whatever. Certainly patches should not just be
directed to me. I don't see the harm in bringing the discussions to
this list.

Here's the patch in question.

 sprint(char *buf, char *fmt, ...)
 {
 	int n;
-	uint len;
 	va_list args;

-	len = 1<<30;  /* big number, but sprint is deprecated anyway */
-	/*
-	 * on PowerPC, the stack is near the top of memory, so
-	 * we must be sure not to overflow a 32-bit pointer.
-	 */
-	if(buf+len < buf)
-		len = -(uintptr)buf-1;
-
 	va_start(args, fmt);
-	n = vsnprint(buf, len, fmt, args);
+	n = vsnprint(buf, 65536, fmt, args);
 	va_end(args);
 	return n;
 }

Note the len = 1 << 30; why was that ever done? I never figured that
out so was never sure about the implications of this patch. Anybody
know?

thanks

ron

[9fans] problem with rminnich's 9vx

[Mathieu Lonjaret]

Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that
patch, I think that means Yiyus' doesn't have it either. And yet,
Yiyus' works for me, so I doubt this bug was the culprit for me. More
like a 64 bits issue as Yiyus mentionned earlier, no?

On Tue, Mar 29, 2011 at 5:06 PM, Christoph Lohmann <20h at r-36.net> wrote:
> Hello,
>
> Mathieu Lonjaret wrote:
>>
>> this last error keeps on repeating.
>> as a plan 9 tree I'm using the same old one that I kept using with rsc's
>> 9vx (minimal tree provided by rsc, and later filled with more plan 9
>> stuff), could that be the issue? if yes, what do you guys for a tree
>> with ron's 9vx?
>
> the bug is easy to solve [0]. Ron didn't integrate my patch
> for this one for a long time, so I started my own repository
> of 9vx.
>
> I tried to solve the problem by resolving all sprint() occur-
> ences in the Plan 9 kernel and that way in 9vx too. The patch
> wasn't accepted; sprint() needs to be fixed.
>
>
> Sincerely,
>
> Christoph Lohmann
>
> [0]
> http://git.r-36.net/vx32/commit/?id=d6e5c080a23fcb914b740db48573305f3712eba0
>
>

[9fans] problem with rminnich's 9vx

[ron minnich]

On Tue, Mar 29, 2011 at 8:42 AM, Mathieu Lonjaret
<mathieu.lonjaret at gmail.com> wrote:
> Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that
> patch, I think that means Yiyus' doesn't have it either. And yet,
> Yiyus' works for me, so I doubt this bug was the culprit for me. More
> like a 64 bits issue as Yiyus mentionned earlier, no?

well, actually, it's more like yiyus forked mine long ago and then we
trade patches ... so it's not clear what's going on here. Did you look
to see if yiyus took that patch?

I run 9vx on 64-bit boxes all the time. One thing I do know is that
ubuntu keeps adding things to the libraries and compiler, so: what
version of ubuntu?

I tend to trust Christoph's diagnosis on this one but ...

ron

[9fans] problem with rminnich's 9vx

[Mathieu Lonjaret]

On Tue, Mar 29, 2011 at 6:09 PM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, Mar 29, 2011 at 8:42 AM, Mathieu Lonjaret
> <mathieu.lonjaret at gmail.com> wrote:
>> Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that
>> patch, I think that means Yiyus' doesn't have it either. And yet,
>> Yiyus' works for me, so I doubt this bug was the culprit for me. More
>> like a 64 bits issue as Yiyus mentionned earlier, no?
>
> well, actually, it's more like yiyus forked mine long ago and then we
> trade patches ... so it's not clear what's going on here. Did you look
> to see if yiyus took that patch?

Yes I looked, it doesn't have it.
https://bitbucket.org/yiyus/vx32/src/398d27a1f253/src/9vx/a/fmt.c

> I run 9vx on 64-bit boxes all the time. One thing I do know is that
> ubuntu keeps adding things to the libraries and compiler, so: what
> version of ubuntu?

10.04.2

> I tend to trust Christoph's diagnosis on this one but ...

and you were right to, because I've just tried it and it also works.
so both yours with Christoph's patch and yiyus's without it do, 2
different ways to fix the problem. :)

[9fans] problem with rminnich's 9vx

[Charles Forsyth]

>+	n = vsnprint(buf, 65536, fmt, args);
	...
>Note the len = 1 << 30; why was that ever done? I never figured that out

there is nothing to limit the length of a string to 64k bytes

[9fans] problem with rminnich's 9vx

[yy]

2011/3/29 ron minnich <rminnich at gmail.com>:
> On Tue, Mar 29, 2011 at 8:42 AM, Mathieu Lonjaret
> <mathieu.lonjaret at gmail.com> wrote:
>> Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that
>> patch, I think that means Yiyus' doesn't have it either. And yet,
>> Yiyus' works for me, so I doubt this bug was the culprit for me. More
>> like a 64 bits issue as Yiyus mentionned earlier, no?
>
> well, actually, it's more like yiyus forked mine long ago and then we
> trade patches ... so it's not clear what's going on here. Did you look
> to see if yiyus took that patch?
>

I didn't merge your last changes to force 32 bits. I planned to do it
but I didn't. That's the only difference between your repository and
mine, and somebody in irc said he had seen problems in 64 bits with
your last version, so I thought there could be something wrong.

I agree we have to arrange things better.


-- 
- yiyus || JGL .

[9fans] problem with rminnich's 9vx

[Charles Forsyth]

in fact, even 64k might be too big a value for the given buf if it's near the
top of memory (eg, a local variable on a stack that's in high memory);
the PowerPC reference in the original comment is misleading because that
was just a particular system where the general problem appeared.

[9fans] problem with rminnich's 9vx

[ron minnich]

My bet here is that if you build yiyus or ron tree and force 32-bit,
it will fail on a 64-bit system, no idea why. if you build with 64-bit
on yiyus tree, it will work.

In other words, I think the issue crops up on 32-bit 9vx on 64-bit
environments. At least that is how it seems to work.

I'm still not sure a length limit on the string of 1 Gbyte makes
sense, and I have no idea if 64K is too low, but the 64k-limit patch
does make it all work. I'm going to try to apply it tomorrow and see
what shakes.

ron

[9fans] problem with rminnich's 9vx

[erik quanstrom]

On Tue Mar 29 12:48:21 EDT 2011, forsyth at terzarima.net wrote:
> in fact, even 64k might be too big a value for the given buf if it's near the
> top of memory (eg, a local variable on a stack that's in high memory);
> the PowerPC reference in the original comment is misleading because that
> was just a particular system where the general problem appeared.

if that's the case, isn't this already a bug.  the stack doesn't go past
the end of memory, so how could sprint(buf, "x") not overwrite junk
past the end of the stack anyway?

also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach)
structure (depending on if up is set or not), so the maximum sprint
to something on the stack is always going to be < 4k.

- erik

[9fans] problem with rminnich's 9vx

[ron minnich]

On Tue, Mar 29, 2011 at 12:05 PM, erik quanstrom
<quanstro at labs.coraid.com> wrote:
> On Tue Mar 29 12:48:21 EDT 2011, forsyth at terzarima.net wrote:
>> in fact, even 64k might be too big a value for the given buf if it's near the
>> top of memory (eg, a local variable on a stack that's in high memory);
>> the PowerPC reference in the original comment is misleading because that
>> was just a particular system where the general problem appeared.
>
> if that's the case, isn't this already a bug. ?the stack doesn't go past
> the end of memory, so how could sprint(buf, "x") not overwrite junk
> past the end of the stack anyway?
>
> also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach)
> structure (depending on if up is set or not), so the maximum sprint
> to something on the stack is always going to be < 4k.

This discussion is why I did not want to apply that patch, even though
it helps. I just want to make sure I understand the issues and was not
convinced I did.

ron

[9fans] problem with rminnich's 9vx

[ron minnich]

On Tue, Mar 29, 2011 at 1:25 PM, Charles Forsyth <forsyth at terzarima.net> wrote:
>one question is: why does the 9vx environment
> make the original version of sprint fail?

I'm glad you asked that question :-)

I ran out of time to track it down. It's got something to do with how
the address space is set up in 32-bit 9vx running in 32-bit emulation
on 64-bit ubuntu, and that's as much as I had time for. Note there is
no issue on osx, for example.

I've gotten used to ubuntu causing these kinds of weird issues over
the last five years since they unilaterally started doing things that
broke builds for embedded software. But it would still be nice to know
what's going on. So if someone can find out ...

But the proposed patch, while it works, just feels like the wrong
approach to me. I'd rather know more.

ron

[9fans] problem with rminnich's 9vx

[Charles Forsyth]

>also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach)
>structure (depending on if up is set or not), so the maximum sprint
>to something on the stack is always going to be < 4k.

that's fine, but the sprint is the one from the c library
which needs to support more than that. the normal kernel doesn't use
a special one, which is part of the answer to ron's question.
-------------- next part --------------
An embedded message was scrubbed...
From: erik quanstrom <quanstro at labs.coraid.com>
Subject: Re: [9fans] problem with rminnich's 9vx
Date: Tue, 29 Mar 2011 15:05:06 -0400
Size: 2365
URL: <http://mail.9fans.net/private/9fans/attachments/20110329/ebf02fb7/attachment.mht>

[9fans] problem with rminnich's 9vx

[Charles Forsyth]

>I'm still not sure a length limit on the string of 1 Gbyte makes
>sense, and I have no idea if 64K is too low, but the 64k-limit patch
>does make it all work. I'm going to try to apply it tomorrow and see
>what shakes.

at some point, a value
	ep = bp + lim
will be formed. if bp+lim is too big, ep will be too small,
which will be bad, because the formatting functions will stop too soon.
that's why the test is there. one question is: why does the 9vx environment
make the original version of sprint fail?

[9fans] problem with rminnich's 9vx

[erik quanstrom]

On Tue Mar 29 16:07:39 EDT 2011, forsyth at terzarima.net wrote:

> >also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach)
> >structure (depending on if up is set or not), so the maximum sprint
> >to something on the stack is always going to be < 4k.
> 
> that's fine, but the sprint is the one from the c library
> which needs to support more than that. the normal kernel doesn't use
> a special one, which is part of the answer to ron's question.

i guess i should have asked more directly, why not pass in
an n such that buf+n = largest possible address.  e.g
~(uintptr)buf.

- erik