winedos interrupts getting lost.

[Peter Dons Tychsen]

Hello.

It starting with me trying to figure out why i was loosing keyboard
events in winedos.

1) I then traced the keyboard events to a call to signal(SIGUSR2) in
function DOSVM_QueueEvent().

2) The signal() triggers code in ntdll, which generates an exception
EXCEPTION_VM86_STI for the current vm86 context.

3) The exception is supposed to trigger exception_handler(), which will 
then handle the keyboard event, by kicking the event queue.

This never happens however, as the mechanism stops working very quickly.

I found out the code gets to raise_vm86_sti_exception in ntdll, and then
stops. ntdll_get_thread_data()->vm86_ptr is NULL, so the STI exception
is never signaled.

Does anyone know more about the exception subsystem, and what could be
causing this kind of strange behavior?

I can mention that the system can generate EXCEPTION_VM86_INTx
exceptions successfully, but fails to execute the EXCEPTION_VM86_STI.

Thanks,

/pedro

[Markus Amsler]

Peter Dons Tychsen wrote:
> Hello.
>
> It starting with me trying to figure out why i was loosing keyboard
> events in winedos.
>
> 1) I then traced the keyboard events to a call to signal(SIGUSR2) in
> function DOSVM_QueueEvent().
>
> 2) The signal() triggers code in ntdll, which generates an exception
> EXCEPTION_VM86_STI for the current vm86 context.
>
> 3) The exception is supposed to trigger exception_handler(), which will 
> then handle the keyboard event, by kicking the event queue.
>
> This never happens however, as the mechanism stops working very quickly.
>
> I found out the code gets to raise_vm86_sti_exception in ntdll, and then
> stops. ntdll_get_thread_data()->vm86_ptr is NULL, so the STI exception
> is never signaled.
>
> Does anyone know more about the exception subsystem, and what could be
> causing this kind of strange behavior?
>
> I can mention that the system can generate EXCEPTION_VM86_INTx
> exceptions successfully, but fails to execute the EXCEPTION_VM86_STI.
>
> Thanks,
>
> /pedro

One issue with dos input is (was?), that since 2.6 linux kernel we 
should signal the thread not the process. Have a look at [1]. That patch 
once fixed all my dos input issues, although I haven't looked at this 
stuff for quite some time.
I'm not sure you have the same problem, just a possible hint.

Markus

[1] http://www.winehq.org/pipermail/wine-patches/2004-November/013645.html

[Peter Dons Tychsen]

Hello Markus.

I think this is exactly what is going wrong.
It fits the description of what i am seeing.
The kernel man-pages even go so far as to state:

"The effects of this call in a multi-threaded process are unspecified."
http://linux.die.net/man/2/signal

So i guess using signal() inside wine is a no-go.
I think this patch needs to be applied.

I will try out the patch, and re-sync it if it has come out-of-date.

Thanks,

/pedro


On Mon, 2008-10-20 at 09:44 +0200, Markus Amsler wrote:
> Peter Dons Tychsen wrote:
> > Hello.
> >
> > It starting with me trying to figure out why i was loosing keyboard
> > events in winedos.
> >
> > 1) I then traced the keyboard events to a call to signal(SIGUSR2) in
> > function DOSVM_QueueEvent().
> >
> > 2) The signal() triggers code in ntdll, which generates an exception
> > EXCEPTION_VM86_STI for the current vm86 context.
> >
> > 3) The exception is supposed to trigger exception_handler(), which will 
> > then handle the keyboard event, by kicking the event queue.
> >
> > This never happens however, as the mechanism stops working very quickly.
> >
> > I found out the code gets to raise_vm86_sti_exception in ntdll, and then
> > stops. ntdll_get_thread_data()->vm86_ptr is NULL, so the STI exception
> > is never signaled.
> >
> > Does anyone know more about the exception subsystem, and what could be
> > causing this kind of strange behavior?
> >
> > I can mention that the system can generate EXCEPTION_VM86_INTx
> > exceptions successfully, but fails to execute the EXCEPTION_VM86_STI.
> >
> > Thanks,
> >
> > /pedro
>
> One issue with dos input is (was?), that since 2.6 linux kernel we 
> should signal the thread not the process. Have a look at [1]. That patch 
> once fixed all my dos input issues, although I haven't looked at this 
> stuff for quite some time.
> I'm not sure you have the same problem, just a possible hint.
>
> Markus
>
> [1] http://www.winehq.org/pipermail/wine-patches/2004-November/013645.html