speakup-r lockup analysis so far

[John Covici]

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

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