Philippe Gerum wrote:
> Don't you think that, quoting yourself:
> "I have to confess, I do not understand how the patch may relate to our
> crash. But that's because I still only have a semi-understanding of this
> frightening complex RPI code"
> does not fit that well with any kind of strong assertion made later on
> the same topic, not backed by facts?

See, as long as you do not directly explain why my concerns on this
naturally racy construct were not valid (I brought up quite a few
concrete questions), I couldn't help raising them over and over again.
This has, in fact, nothing to do with understanding the RPI code in all
its details. It's about reviewing basic patterns of it. But now that the
critical bit is gone, I'm surely no longer concerned. :)

> So, I'm suggesting that we move on, and end this discussion in a
> positive manner, i.e. by fixing this code. I hear your concerns, like I
> always do, and I'm trying to find a solution that does not paper over
> another issue. I guess we should be able to settle on this.
> I pushed two patches in my for-upstream queue, with lengthy comments to
> explain what they do and why this is needed:
> - the first patch is a plain revert of the commit introducing
> rpi_next(), which caused the bug you observed in SMP mode, and that your
> patch plugged successfully.
> - the second patch is the proper fix for the issue rpi_next() tried to
> address.
> Could you please try them, and report whether this also fixes the issue
> for you? In the meantime, I will be analyzing the RPI code once again,
> to check whether your patch still covers a possible case, or not.

I will try my best, but the issue showed up only once in countless
application runs. We will role out the patches at the next chance (we
already had to push my workaround as we need to deliver the fastsynch
fix, so it may take a while).


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to