On Sun, 2008-11-09 at 23:27 +0800, Alexey Starikovskiy wrote:
> Yakui,
>
> Please take a look at the subject of the thread -- notice words "fatal"
> and "(EC transaction is done in interrupt context)".
> Looks horrible, isn't it? Now we begin to get into details, and it appears
> that it is not fatal, introduced 3.5 years ago, and has nothing to do with
> interrupt context transaction patch.
> So, the whole point of your message is to spread FUD about "fast
> transaction" patch,
> and show how great you are. I would guess that you've failed in
> achieving both goals.
I won't argue with you about this issue.
In your patch the program logic states that the EC transaction is
already finished. But in fact the EC transaction is not really finished.
They are inconsistent. Why can't call this a fatal logic error?
The more important is that the failure in EC transaction can't be
detected in time.
Why can't call this a fatal logic error?
If this is not a fatal logic error, what can be called fatal? Like that
Several commits are reverted each other as the following three commits.
a.7c010de7506954e973abfab5c5999c5a97f7a73e
b.4c611060660f0de3e9b8f02df207312bc6f5c331
c.f9319f903f898dd4b15dbc386499725ce6c59776
If you still reply the subject so impolitely, Don't blame that I will
forward the similar error to wider range.
>
> If you cry "wolf!" too often, you'll get ignored, when the real wolf
> appears.
>
> Now, for a positive example, the same message without exclamation marks...
> ---------------------------------------------------------------------------------------------------------------------------------
> Subject: difference in EC transaction protocol
> Hi Alex,
> I've noticed difference in EC transaction protocol for write and
> burst-disable commands,
> namely all that end with writing byte to EC -- they don't wait for last
> confirmation interrupt and
> next transaction might start before current one completes.
> May be this is the "root cause" we are looking for.
> Regards,
> Yakui
> ---------------------------------------------------------------------------------------------------------------------------------
> Note that this message is shorter, and is not offensive.
> Smile, and people may start to like you...
>
> Regards,
> Alex.
>
> P.S. And I don't agree with your analysis as you still believe that
> before the fast transaction mutex was
> not released at the same time as it is now.
>
> Zhao Yakui wrote:
> > On Sun, 2008-11-09 at 00:47 +0800, Alexey Starikovskiy wrote:
> >
> >> Yakui,
> >> This is not about my patch, this is about your ego...
> >>
> > Thanks for the reply. I know that this is not introduced by your patch.
> > In the previous kernel the EC transaction is explicitly divided into
> > several phases. Only when EC transaction is really finished, the EC
> > mutex lock is released. In such case the previous EC transaction is
> > already finished when OS begins another EC transaction. So the issue
> > about "1 microsecond" won't appear.
> No. No matter how many phases, transaction is done and EC mutex is released
> as soon as last write happens. EC driver never waited for confirmation
> for last written byte.
> > But in your patch(EC transaction is
> > done in interrupt context) when EC mutex is released , maybe the
> > previous EC transaction is not really finished. In such case the issue
> > of "1 microsecond" will appear.
> > Is what I said right?
> No. my patch has same "optimization" as appeared in EC driver since
> introduction of interrupt mode.
> May be it is more visible now, and you managed to notice it, while still
> failing to see it in earlier EC driver versions?
> I agree that there are some benefits in not doing this optimization,
> thus I made the patch to drop it.
> >
> >
> >> My patch did not introduce this behaviour, it was there since "burst mode" was introduced, and may be even earlier. You may ask Luming Yu, why he was so optimistic about 1 microsecond (is he still around? you did not include him into CC yet...).
> >>
> Actually, I gave too much credit to Shanghai office... Interrupt mode patch was written by Dmitry Torokhov, not Luming Yu.
>
> > In my email what I said is only to point out the logic error. Maybe
> >
> No, see above.
> > there is no problem that the EC mutex is released before EC transaction
> > is really finished. IMO this is still a logic error. The program logic
> > states that EC transaction is already finished but the EC transaction is
> > not really finished. They are inconsistent..
> > The more important is that the failure in EC transaction can't be
> > detected in time.
> >
> > Do you agree with my analysis?
> >
> >
> No, see above.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
