Re: freezes when not emulating CPU (was: MIDI input patch)

Re: freezes when not emulating CPU (was: MIDI input patch)

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
 > exception happens -- I guess that was just meant for debugging).
 > Thanks (to Stas also),
The "SB16 fixes from Stas Sergeev via x.zupftom@web.de on linux-msdos."
is actually also the related FPU fix.
There was a division by zero there in
pcm_samp_period() (when called without
the necessary checks), which I became
aware of, because it started to produce
SIGFPE when I played with vm86_fpu_state
struct. Which means that the comment in
do_vm86.c about fnsave is wrong, and the
code that restores the dosemu FPU state
should likely to be returned. You can,
for example, memset the vm86_fpu_state
to 0 in fpu_reset() and see the SIGFPE
coming from all around the sound code
(no other code use FPU in dosemu).
Also, I found no docs about this FPU
init/reset stuff, so everything in this
patch is just a wild guesses based on
a look into a bochs code.
Also, there is a need to add the handling
for exception 0x13 (SIMD FPE), which is
what the SIGFPE is about today. I mean,
at least print_exception_info() should
write something meaningfull about SIGFPE
instead of "Unknown exception".
So I guess this patch needs more work,
but it should be harmless in its current
form too.

Re: freezes when not emulating CPU (was: MIDI input patch)

[Bart Oldeman]

Hello Stas,

> Which means that the comment in
> do_vm86.c about fnsave is wrong, and the
> code that restores the dosemu FPU state
> should likely to be returned. You can,
> for example, memset the vm86_fpu_state
> to 0 in fpu_reset() and see the SIGFPE
> coming from all around the sound code
> (no other code use FPU in dosemu).

I've been looking at this. The SIGFPEs don't happen for i386 (default
FP), only for x86-64 or when explicitly compiling with SSE floating
point (using gcc -msse2 -mfpmath=sse). The "fnsave" instruction really
re-initializes the FPU (it's documented), but with SSE one needs to
use "fxsave" and "fninit", and that still doesn't reinitialize the
SIMD part. Adding an "ldmxcsr" instruction solved that problem.

I still think that a simple FPU environment reset is sufficient, no
need to restore all the registers, because the DOSEMU FPU code is not
interrupted by DOS code.

The fpu save/restore operations aren't cheap, so perhaps one could
only use them around the sound code instead of for every vm86 call.
Though that could be messy.

> Also, I found no docs about this FPU
> init/reset stuff, so everything in this
> patch is just a wild guesses based on
> a look into a bochs code.
> Also, there is a need to add the handling
> for exception 0x13 (SIMD FPE), which is
> what the SIGFPE is about today. I mean,
> at least print_exception_info() should
> write something meaningfull about SIGFPE
> instead of "Unknown exception".

I've done that now.

Bart

Re: freezes when not emulating CPU

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
> I've been looking at this. The SIGFPEs don't happen for i386 (default
> FP), only for x86-64 or when explicitly compiling with SSE floating
> point (using gcc -msse2 -mfpmath=sse).
OK, but the point is that I haven't specified
these flags by hands, so they might be a default
for dosemu right now. So it have to became sse-safe.

> The "fnsave" instruction really
> re-initializes the FPU (it's documented),
I know it does, but the comment I was referring to,
also says:
---
which is good enough for calling FPU-using routines.
---
and that appeared to be false.

> but with SSE one needs to
> use "fxsave"
Hmm, why does'n it use fxsave right now?

> and "fninit", and that still doesn't reinitialize the
> SIMD part. Adding an "ldmxcsr" instruction solved that problem.
I guess this might be a good work-around, at
least till they invent yet another FP technique. :)

> I still think that a simple FPU environment reset is sufficient, no
> need to restore all the registers, because the DOSEMU FPU code is not
> interrupted by DOS code.
What if the DOS code (by some crazy chance) also
uses sse?

> The fpu save/restore operations aren't cheap, so perhaps one could
> only use them around the sound code instead of for every vm86 call.
> Though that could be messy.
Indeed - so what was the problem with fninit/ldmxcsr then?
Looks like it would load only the control/status word, so
that might not be as expensive as the full reload?
Also, I think fxrstor doesn't wait for completion, so
the careful implementation may not be too expensive.
There are also some tricks possible, like, for example, set
FPU to something that will SIGFPE on any FP, and initialize
it properly in a signal handler, but I guess this would
be an overkill.

>> Also, I found no docs about this FPU
>> init/reset stuff, so everything in this
>> patch is just a wild guesses based on
>> a look into a bochs code.
Have you had a look into that? I only zero out a
few fields, I guess more should be re-set on a
hardware reset (or via port I/O). I even thought
this ought to be entire bzero() except for the few
fields with pre-defined values, but it appears
not, which I don't quite understand... and found
no docs.

>> write something meaningfull about SIGFPE
>> instead of "Unknown exception".
> I've done that now.
Any idea why I am not receiving the SF e-mails for
a long time now? I thought dosemu is long ago dead,
but instead there might just be some problems with
the notification messages...

Re: freezes when not emulating CPU (was: MIDI input patch)

[Frank Cox]

On Mon, 14 Sep 2009 09:05:25 -0400
Bart Oldeman wrote:

> I still think that a simple FPU environment reset is sufficient, no
> need to restore all the registers, because the DOSEMU FPU code is not
> interrupted by DOS code.

Is there any chance that this issue is related to the bug I describe here:

http://markmail.org/message/bxdsyrzn6cd63fv3

I'm asking because my experimentation with Powerbasic seems to indicate that it
has something to do with the DEFINT A-Z directive in the program written in
Powerbasic -- if I remove that directive it works.  So it may be related to the
integer variable handling somehow?

-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com

Re: freezes when not emulating CPU

[Samuel Bronson]

Whoops, sent this to just Stas the first time ... sorry, Stas!

On Mon, Sep 14, 2009 at 11:26 AM, Stas Sergeev <stsp@aknet.ru> wrote:
> Hello.
>
> Bart Oldeman wrote:

>> The fpu save/restore operations aren't cheap, so perhaps one could
>> only use them around the sound code instead of for every vm86 call.
>> Though that could be messy.
>
> Indeed - so what was the problem with fninit/ldmxcsr then?
> Looks like it would load only the control/status word, so
> that might not be as expensive as the full reload?
> Also, I think fxrstor doesn't wait for completion, so
> the careful implementation may not be too expensive.
> There are also some tricks possible, like, for example, set
> FPU to something that will SIGFPE on any FP, and initialize
> it properly in a signal handler, but I guess this would
> be an overkill.

Well, I believe that's essentially what Intel suggests OSes do on
task-switch -- leave some flag set/cleared that will cause the next FP
operation to give an exception so that it can switch the FP registers
at that time. Whether or not this would be a good idea for DOSEMU
depends on how often you do a vm86 call vs how often the FP registers
are needed, and on how expensive it is to actually enter a state from
which the next FP access will cause a signal compared to just doing
the reload each time.

Re: freezes when not emulating CPU

[Stas Sergeev]

18.09.2009 00:37, Samuel Bronson wrote:
> Well, I believe that's essentially what Intel suggests OSes do on
> task-switch -- leave some flag set/cleared that will cause the next FP
> operation to give an exception so that it can switch the FP registers
> at that time. Whether or not this would be a good idea for DOSEMU
> depends on how often you do a vm86 call vs how often the FP registers
> are needed, and on how expensive it is to actually enter a state from
> which the next FP access will cause a signal compared to just doing
> the reload each time.
dosemu is not interrupted by the DOS
code, so the full reload is never really
needed. You just need the "known good state",
rather than the "full previous state".
If whatever is needed is only fninit/ldmxcsr,
then I guess it is just cool.

Re: freezes when not emulating CPU

[Bart Oldeman]

Hello,

> OK, but the point is that I haven't specified
> these flags by hands, so they might be a default
> for dosemu right now. So it have to became sse-safe.

Yes, dosemu needs to be sse-safe. In fact that was the intent of a
change to cpu.h that I already made in April 2007, using fxsave+fninit
when available. But I forgot about ldmxcsr. So I added the ldmxcsr on
Monday.

>> I still think that a simple FPU environment reset is sufficient, no
>> need to restore all the registers, because the DOSEMU FPU code is not
>> interrupted by DOS code.
>
> What if the DOS code (by some crazy chance) also
> uses sse?

Well, if no DOS code would use SSE we would only need to save and
restore the x87 FPU state, and not the SSE state. It is precisely
because of the use of fxsave/fxrstor (without the forgotten ldmxcsr)
that you saw all these exceptions on x86_64 (where SSE is the
default).

It is however possible though extremely rare to find SSE DOS code:
DJGPP gcc happily generates it and it runs. I tested that for example
with a QEMU CPU tester that I ported to DJGPP to test and fix quite a
few bugs in cpuemu recently (it's in src/tests now -- with a Makefile
changes SSE is enabled).

> Have you had a look into that? I only zero out a
> few fields, I guess more should be re-set on a
> hardware reset (or via port I/O). I even thought
> this ought to be entire bzero() except for the few
> fields with pre-defined values, but it appears
> not, which I don't quite understand... and found
> no docs.

No I have no idea either except from what you did, look at Bochs or
other emulators.

> Any idea why I am not receiving the SF e-mails for
> a long time now? I thought dosemu is long ago dead,
> but instead there might just be some problems with
> the notification messages...

I got some bounces recently for you. I'll forward privately, and will
try to add you again.

Bart

Re: freezes when not emulating CPU

[Bart Oldeman]

Hello,

On Fri, Sep 18, 2009 at 9:32 AM, Gert Koefoed Andersen <gert@kofo.org> wrote:
> Could it be a idea too to make a update update to support for the newer cpu
> as family 16 cpu's like my type there is AMD Athlon(tm) II X2 A3/2+ 245
> Familly 16 Processors.
> The should have been showin date fot 2 kind of newr processors in developper
> lists and some other list for dosemu.

These changes were made in SVN (r1869/1870) in April -- I hope to
release an official update later.

Bart

RE: freezes when not emulating CPU

[Gert Koefoed Andersen]

Hello,

> > Could it be a idea too to make a update update to support for the
> > newer cpu as family 16 cpu's like my type there is AMD
> Athlon(tm) II
> > X2 A3/2+ 245 Familly 16 Processors.
> > The should have been showin date fot 2 kind of newr processors in
> > developper lists and some other list for dosemu.
>
> These changes were made in SVN (r1869/1870) in April -- I
> hope to release an official update later.
>
Then must me Gentoo emerge then found too unstable to it like to add it and
then say 'unknow cpu type' after skipping the patch and not got into my
/dosemu/files dirctory as there only is 2 files in it, and then not do the
update from 1.4.0 to 1.4.0.1 fine.
As I make it by Gentoo portage.

I have my dosemu to run some games as a League Coordinator for 2 games and
lot of bbs igms there is runs, and it dosemu works fine before I got my pc
upgrade from a amd64 AMD Athlon I 3800 2ghz to a AMD Athlon II 2x A3/2+ 245
3ghz processor.
And the pc is the main pc for it all and lot of links is getting league
games from me and this pc.

Gert
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-msdos" in the body of a message to
> majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>

RE: freezes when not emulating CPU

[Gert Koefoed Andersen]

Hello,

> > Could it be a idea too to make a update update to support for the
> > newer cpu as family 16 cpu's like my type there is AMD
> Athlon(tm) II
> > X2 A3/2+ 245 Familly 16 Processors.
> > The should have been showin date fot 2 kind of newr processors in
> > developper lists and some other list for dosemu.
>
> These changes were made in SVN (r1869/1870) in April -- I
> hope to release an official update later.
>
I have just gone through the updates I can find, and it is not on
sourceforge.net to find.
And this is then why dosemu not work on my amd64 pc with AMD Athlon(tm) II
X2 A3/2+ 245 Fam. 16 Processor.

I nned the udate now to run my Leagues games by dosemu.

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 6
model name	: AMD Athlon(tm) II X2 245 Processor
stepping	: 2
cpu MHz		: 2906.206
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs skinit wdt
bogomips	: 5812.40
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 6
model name	: AMD Athlon(tm) II X2 245 Processor
stepping	: 2
cpu MHz		: 2906.206
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs skinit wdt
bogomips	: 5813.23
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate


Gert
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-msdos" in the body of a message to
> majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>