speakup-r lockup analysis so far

[Okash Khawaja]

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