Unknown mbox type 0

[Davide Libenzi]

I get this when I try to run Akaros (run bb from ^G, that is) on a single core mode.

Is it expected?

[Kevin Klues]

Well, this particular bug comes from the fact that we never set up an
mbox for vcore0 if max_vcores() == 0 (which it is if you only give the
machine 1 core).

https://github.com/brho/akaros/blob/master/user/parlib/vcore.c#L175

I have feeling that there are more consequences than this though.

> --
> You received this message because you are subscribed to the Google Groups
> "Akaros" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akaros+un...@googlegroups.com.
> To post to this group, send email to aka...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
~Kevin

[Davide Libenzi]

OK, thanks Kevin.

[Kevin Klues]

Actually, looking a little closer, the fix is pretty easy:

https://github.com/brho/akaros/compare/1ed63f9...a4a554e

I'll defer to Barret to check if I missed anything.

On Wed, Nov 11, 2015 at 6:51 PM, 'Davide Libenzi' via Akaros

[Kevin Klues]

By the way, this is on a branch called klueska/always-init-vcore0s-mbox

The changes in this request can be viewed online at:

    https://github.com/brho/akaros/compare/1ed63f9...a4a554e

The following changes since commit 1ed63f9f8e25820f7eb217727d4ee88efe827d41:

  Migrated Akaros code to use pragma once (XCC) (2015-11-11 11:37:59 -0500)

are available in the git repository at:

  g...@github.com:klueska/akaros always-init-vcore0s-mbox

for you to fetch changes up to a4a554e96a77afafba44ebc09b6f2909b3838c0d:

  Setup vcore 0's mbox even if max_vcores() == 0 (2015-11-11 18:50:28 -0800)

----------------------------------------------------------------

Kevin Klues (1):

      Setup vcore 0's mbox even if max_vcores() == 0

 user/parlib/vcore.c | 5 +++--

 1 file changed, 3 insertions(+), 2 deletions(-)

[Barret Rhoden]

On 2015-11-11 at 18:52 Kevin Klues <klu...@gmail.com> wrote:
> Actually, looking a little closer, the fix is pretty easy:
>
> https://github.com/brho/akaros/compare/1ed63f9...a4a554e
>
> I'll defer to Barret to check if I missed anything.

> + int nvcores = max_vcores() ? max_vcores() : 1;

That's probably enough. I'll think over it a little more and see if
there are any other gotchas.

Barret

[Barret Rhoden]

On 2015-11-12 at 09:30 Kevin Klues <klu...@gmail.com> wrote:
> By the way, this is on a branch called
> klueska/always-init-vcore0s-mbox

that fixes davide's bug, but there are a host of others just like it,
due to the how userspace SCPs think they have a vcore, and max_vcores()
tells them how many.

i put together a fix, patch forthcoming. let me know if you see
anything wrong with it.

thanks,

barret

[Barret Rhoden]

This popped up if you ran Akaros on a single core machine. In that case, you'd
have 0 CG cores, which means the kernel gives you 0 vcores. However, SCPs
think they have one vcore. If a process runs at all, it needs to think it has
at least one vcore.

Rebuild busybox.

Signed-off-by: Barret Rhoden <br...@cs.berkeley.edu>
---
user/parlib/include/vcore.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/parlib/include/vcore.h b/user/parlib/include/vcore.h
index 66b6b8134291..05e538ade7d5 100644
--- a/user/parlib/include/vcore.h
+++ b/user/parlib/include/vcore.h
@@ -77,7 +77,7 @@ bool check_vcoreid(const char *str, uint32_t vcoreid);
/* Static inlines */
static inline uint32_t max_vcores(void)
{
- return MIN(__procinfo.max_vcores, MAX_VCORES);
+ return MAX(1, MIN(__procinfo.max_vcores, MAX_VCORES));
}

static inline uint32_t num_vcores(void)
--
2.6.0.rc2.230.g3dd15c0

[Kevin Klues]

I thought about this, and it seems reasonable so long as we never use
max_vocres() == 0 as a proxy for in_multi_mode() (i.e.
__procinfo.is_mcp) anywhere. We may have done this in old code
somewhere. Did you do a survey of all uses of max_vcores()?

[Barret Rhoden]

On 2015-11-13 at 13:04 Kevin Klues <klu...@gmail.com> wrote:
> I thought about this, and it seems reasonable so long as we never use
> max_vocres() == 0 as a proxy for in_multi_mode() (i.e.
> __procinfo.is_mcp) anywhere. We may have done this in old code
> somewhere.

that'd be super buggy, since on any machine with > 1 pcore you'd
always have max_vcores = at least 1. it might be more reasonable to
have done num_vcores == 0 for is_mcp or not, but that's buggy too (and
i should have removed those if they existed).

> Did you do a survey of all uses of max_vcores()?

skimmed the list of git grep. it all seemed like "this is how many
vcores i could ever get".

barret

[Kevin Klues]

On Fri, Nov 13, 2015 at 1:32 PM, Barret Rhoden <br...@cs.berkeley.edu> wrote:
> On 2015-11-13 at 13:04 Kevin Klues <klu...@gmail.com> wrote:
>> I thought about this, and it seems reasonable so long as we never use
>> max_vocres() == 0 as a proxy for in_multi_mode() (i.e.
>> __procinfo.is_mcp) anywhere. We may have done this in old code
>> somewhere.
>
> that'd be super buggy, since on any machine with > 1 pcore you'd
> always have max_vcores = at least 1. it might be more reasonable to
> have done num_vcores == 0 for is_mcp or not, but that's buggy too (and
> i should have removed those if they existed).

Yeah, duh, don't know what I was thinking.

[Barret Rhoden]

Thanks, merged to master at a7bd47c1b299..bc87a54562ab (from, to]

You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/a7bd47c1b299...bc87a54562ab