speakup-r lockup analysis so far

[Okash Khawaja]

On 23 Aug 2017 12:45 pm, "John Covici" <covici at ccs.covici.com> wrote:

So, what is the difference if you don't start with an empty line --
what is the call flow then?


It's the same until read_all_doc but read_all_doc doesn't call
kbd_fakekey2. It goes to else part of 'if (get_sentence_buf()==-1)' check.



On Wed, 23 Aug 2017 07:21:29 -0400,
Okash Khawaja wrote:
>
> Hi,
>
> This is my analysis of speakup-r empty line lockup so far.
>
> The call chain that leads is:
>
> cursor on an empty line --> user hits speakup-r --> (everthing from here
> on will be in interrupt context) --> keyboard_notifier_call(code == 4
> == KBD_KEYSYM) --> speakup_key() --> do_spkup() --> spkup_handler(value
> ==47==index of read_all_doc) --> read_all_doc --> kbd_fakekey2()
>
> Now, inside kbd_fakekey2(), speakup_fake_down_arrow() causes the lockup.
> And inside speakup_fake_down_arrow(), input_sync() causes the lockup.
>
> I'm pretty sure keyboard_notifier_call is not invoked again, after
> input_sync() when the lockup happens. So either lockup happens inside
> input_sync() or some callback that is invoked as a result of
> input_sync's execution.
>
> From tests that John ran, we can say that speakup_fake_down_arrow itself
> is correct. It's only when it is called as a result of above call chain
> that the lockup happens. Also worth noting is the fact that above
> sequence is all inside interrupt context.
>
> Any ideas or suggestions about line of investigation will be helpful.
> Until then, I'll continue to explore this.
>
> Thanks,
> Okash

--
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici at ccs.covici.com