Poole, Bryce wrote:
> I am using a combination of DirectFB-1.0.1 and fusion 3.2.5 on my 2.6.23
> kernel. The first application that I run, I get:
>
>
>
> (!) FUSION_CALL_RETURN --> Input/output error
>
> (-) [ 645: -STACK- ]
>
> #0 0xb7e87ef0 in _fusion_call_process () from
> /usr/local/lib/libfusion-1.0.so.0 [0xb7e83000]
>
> #1 0xb7e8a4b8 in ?? () from /usr/local/lib/libfusion-1.0.so.0
> [0xb7e83000]
>
> #2 0xb7e67f5b in direct_thread_main () from
> /usr/local/lib/libdirect-1.0.so.0 [0xb7e55000]
>
>
>
> From what I understand a fusion “call” is a Remote Procedure Call
> (RPC). The RPC can return a value early while it continues to process
> the function call. When fusion_call_execute is called, it generates a
> FUSION_CALL_EXECUTE ioctl. This generates an “execution” inside fusion
> that is serialized and set as the “last” execution in the call object.
> In my case, the fusionee is NULL and it skips creating an “execution”.
> The RPC is allowed to call fusion_call_return to set the return value
> before it is finished executing. When this happens, a
> FUSION_CALL_RETURN ioctl is generated, fusion takes the last
> “exectution” in the call object and returns the value in it. However,
> when I run, that “last” field is blank and it returns the error above
> “FUSION_CALL_RETURN à Input/output error”. The call in question seem to
> be generated by the pools to search for zero-referenced objects and
> destroy them.
Since 3.2.5 the code dealing with executions and returns has changed quite
a bit and the bug has been fixed. It should be possible to port DirectFB 1.0.1
to linux-fusion 8.0.2 and maybe have a 1.0.2 release with maybe a bunch of
fixes pulled from 1.1.x and 1.2.x branches.
...a while (and a few commits) later...
I compared calls in 3.2.5 and 8.0.2. The major difference is the serial number
associated with each call now. Any out of order return is handled properly and
no more invocation can return for another.
The actual issue was still there, but the code did not return an error anymore
when the execution could not be found.
I changed the code to only provide a serial number, if there's an execution that
needs a return ioctl, otherwise the reserved zero serial will indicate to user
space that no return should be made.
commit 43196188dcbab64e3c3adefd1feb60d48821b9c7
Author: Denis Oliver Kropp <[EMAIL PROTECTED](none)>
Date: Sat Oct 18 03:11:48 2008 +0200
[call] Use zero serial number to indicate call without return. Fail upon
invalid return again.
Return EOPNOTSUP if FUSION_CALL_RETURN is attempted with a zero serial.
Return ENOMSG if serial number has not been found.
I'd still propose to port DirectFB 1.0.1 to linux-fusion 8.0.2 (8.0.3).
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
