Fiasco.OC: sigma0 stucks in ipc-path

[Norman Feske]

Hi Adam,

> Yes, that's a good question. This cannot really happen within L4Re due
> to the eager memory allocation of moe, so it was never an issue there.

I thought so too because Genode's core pre-allocates all memory from
sigma0 at boot time. There are, however, rare cases where the sigma0
protocol is invoked anyway. For example, for handing out MMIO regions to
user-level device drivers (roottask doesn't know about those physical
regions at boot time) and handing out boot modules.

Because the use of the sigma0 protocol at runtime is extremely rare, and
the chance for the time slice running out while a sigma0 request is
processed even more so, and the chance to have a fully saturated system
even more more so, this problem triggered only sporadically. Circa once
in a month, and only in highly complex/dynamic scenarios. We have
observed it the first time more than 6 months ago. It took us until now
to come up with a stable test case that pinpoints the problem.

> I do not really have an opinion on that right now but I'll try to get
> one.

To me the problem looks like a school-book example for priority
inversion, which just happened to got covered up pretty nicely by
Fiasco's time-slice donation optimization. Do you have an alternative
way to fix it other than boost the priority of sigma0?

You say that L4Re does not use the sigma0 protocol at runtime. Is there
a compelling reason for keeping this little guy called sigma0 lurking
around in the system then? If not, getting rid of sigma0 (as done by
OKL4 or NOVA, btw) would certainly be the cleanest way to fix our
problem. .-)

Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth