Hey Fernando,
On Wed, Mar 24, 2010 at 08:18:36PM +0100, ext Guzman Lugo, Fernando wrote:
>
> Hi Felipe,
>
> >So, before your patch, the get_message() failed, and the next
> >wait_for_events() succeeded and returned the MMU fault. Now, the
> >get_message() fails, and so does the wait_for_events().
>
> The think is that the now after fatal error and recovery process start
> all bridge ioctl's will fail with -EIO (that was the requirement when
> I did the code)
>
> @@ -496,6 +553,12 @@ static long bridge_ioctl(struct file *filp, unsigned int code,
> union Trapped_Args buf_in;
>
> DBC_REQUIRE(filp != NULL);
> +#ifdef CONFIG_BRIDGE_RECOVERY
> + if (recover) {
> + status = -EIO;
> + goto err;
> + }
> +#endif
>
> So you if you call dsp_node_get_message and then a fatal error
> happens, dsp_node_get_message will failed and if you what to call
> dsp_wait_for_events will fail because we are in recovery process
> (before it was succeeded because wait_for_events ioctl can go through
> and the MMUFault event was already signaled).
>
> To sum up:
> With this patch in order to be notified of fatal errors you need to
> register for those and call dsp_wait_for_events before the fatal error
> occurs. Otherwise dsp_wait_for_events will fail.
>
> So I think you need a dedicate thread to receive fatal errors.
One thread to fetch messages and another thread to receive fatal errors?
Come on, that's overkill... threads are not free.
I'm ok changing gst-dsp code, but let's be clear about this; this is yet
another ABI break.
If I can detect fatal errors in wait_for_events() then I don't need to
register for MMU faults, sys erros and all that stuff. Now, how do I
distinguish a fatal wait_for_events() vs a non-fatal one (timeout).
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
