Fiasco.OC: sigma0 stucks in ipc-path
stefan.kalkowski at genode-labs.com
Mon Jun 4 13:21:19 CEST 2012
sorry I got you wrong in the first place. I didn't realized, that sigma0
actually runs on a lower priority than any other thread in the system.
Obviously the donated timeslice from the core-pager gets fully consumed,
and after that it never gets scheduled again, because at any time
another thread is active (which is a condition I actually build in with
intention to trigger the "bug").
I raised the priority of sigma0 and then it worked.
So it seams to be no problem in the Fiasco.OC kernel at all.
Nevertheless, it raises the question, whether it would be more
reasonable to execute sigma0 on a higher priority by default?
On 03.06.2012 17:54, Stefan kalkowski wrote:
> Hi Adam,
> On 03.06.2012 16:36, Adam Lackorzynski wrote:
>> On Thu May 31, 2012 at 18:30:07 +0200, Stefan kalkowski wrote:
>>> I think I came along a problem in the IPC-path of Fiasco.OC sometimes in
>>> the past, but it was somehow hard to reproduce. But now I've an example
>>> that quite reliable triggers the issue.
>>> The symptom in the past, and in the concrete example was that our
>>> roottask in Genode (called core) was requesting memory from sigma0,
>>> either implicitly just by touching some memory-area, like a ROM-module
>>> loaded by the bootloader, or explicitly by using the sigma0-protocol,
>>> e.g. to request I/O memory for the framebuffer. After that the request
>>> was received by sigma0, and also processed, but the answer never reached
>>> the faulter/client in this case the core-pager thread. The typical
>>> picture in the kernel-debugger then looks like the following:
>> I'm wondering how the higher-prio and ready 'pthread' thread relates to
>> that. Is it always ready and doing something?
> Yes, that's strange. The sigma0 thread is always marked as being ready
> in the kernel-debugger, but obviously isn't doing progress anymore.
> Nevertheless, although sigma0 is marked as ready, and has the highest
> priority, other thread's are still doing progress. For instance, two
> threads that are using the timer-service are still doing ping-pong IPC
> with it (can be observed, when enabling IPC-logging after sigma0 stucked).
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
More information about the l4-hackers