search

sifadil / pcsx2-playground

Automatically exported from code.google.com/p/pcsx2-playground
2 stars 0 forks source link

Linux and vtlb #89

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
I must notice, that vtlb is still unable to use systems with over 2GB
addresses, so Linux build is just broken from rev. 458. If nobody fix it,
than the only logical solution is to revert it. I could not properly fix
ZeroGS OGL issues without full debug circle, and debuggin is not very funny
on old versions.

Original issue reported on code.google.com by Zeydl...@gmail.com on 24 Dec 2008 at 2:37

GoogleCodeExporter commented 8 years ago 
I'm pretty sure we can use Linux mmap to get an allocation below 2gb, and that 
should
fix this issue.  So for now it's just a matter of getting that implemented and 
tested.

Original comment by Jake.Stine on 25 Dec 2008 at 12:35

GoogleCodeExporter commented 8 years ago 
r531 has an attempted implementation of vtlb memory allocations using SysMmap.  
Let
me know how it fairs. :)

Original comment by Jake.Stine on 1 Jan 2009 at 5:24

GoogleCodeExporter commented 8 years ago

Original comment by Jake.Stine on 1 Jan 2009 at 5:25

GoogleCodeExporter commented 8 years ago 
Does not work for me. 

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb73426c0 (LWP 24692)]
0x080f0358 in vtlbUnmappedVRead32<0u> (addr=0, data=0x83b2bfc) at vtlb.cpp:211
211     verify(false);

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 11:36

GoogleCodeExporter commented 8 years ago 
That could be because of other bugs introduced in the Linux build since the VTLB
merge.  Failed verify() statements are normally an indication of emulation bugs 
or
badly generated recompiled code (stack errors, unsaved registers, etc).

There could be bugs in the new MTGS, so disable it for now until you get 
everything
else working.

Original comment by Jake.Stine on 1 Jan 2009 at 12:02

GoogleCodeExporter commented 8 years ago 
In recompiller mode I'v got similar trouble: recRecomplile assertion with 
startpc = 0.

So it both cases, cpuRegs.pc == 0, which leads to segfault

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 12:27

GoogleCodeExporter commented 8 years ago 
Sounds like the GUI isn't initializing the emulation state correctly.  
cpuRegs.pc
should be assigned by either cpuReset() or loadElfFile().

Original comment by Jake.Stine on 1 Jan 2009 at 12:40

GoogleCodeExporter commented 8 years ago 
It probably isn't. Getting it to compile after the savefile changes was a hack, 
and I
hadn't had an opportunity to really trace down and get the new code in place. It
compiled, but I actually had a fairly good idea that I'd have to fix it 
properly once
we had the new memory code in.

Until that was in, though, it would have been too difficult to get it fixed 
properly...

Original comment by arcum42@gmail.com on 1 Jan 2009 at 12:45

GoogleCodeExporter commented 8 years ago 
Well, windows version do cpuReset manually at RunExecute. Linux version do not.

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 1:15

GoogleCodeExporter commented 8 years ago 
Right, that was an oversight when fixing the code. I'm in process of reworking 
it
based on WinMain.cpp right now. If you put the cpuReset in the right place, it 
fails
on the assert in _vSourceLog, though.

Original comment by arcum42@gmail.com on 1 Jan 2009 at 1:18

GoogleCodeExporter commented 8 years ago 
Well, for me recompiller mode break at

#0  0x080f035c in vtlbUnmappedVRead32<0u> (addr=1028551664, data=0x8866f50) at
vtlb.cpp:212

from cpuExecuteBios 

and interpreter one

[Switching to Thread 0xb73b96c0 (LWP 28599)]
0x08155d15 in SuperVUInit (vuindex=0) at iVUzerorec.cpp:333
333         jASSUME( vuindex < 0 );
(gdb) bt
#0  0x08155d15 in SuperVUInit (vuindex=0) at iVUzerorec.cpp:333
#1  0x08089dad in vu0Init () at VU0micro.cpp:118
#2  0x08082ff9 in cpuInit () at R5900.cpp:109
#3  0x0806de72 in SysInit () at LnxMain.cpp:412
#4  0x0806e9ce in main (argc=1, argv=0xbfbd7a94) at LnxMain.cpp:179

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 1:34

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Yeah, that's about where it's going after my last changes. I'll go ahead and 
commit
them after I check them over a bit, just so the execute code isn't as badly 
broken as
it is now, though.

Original comment by arcum42@gmail.com on 1 Jan 2009 at 1:40

GoogleCodeExporter commented 8 years ago 
In fact, my mistake. _vSourceLog is without the mtgs code. vtlbUnmappedVRead32 
is
with it.

Original comment by arcum42@gmail.com on 1 Jan 2009 at 1:44

GoogleCodeExporter commented 8 years ago 
This may give you a better idea of what it currently does, Jake. This is what 
the log
shows when I try to run Kingdom Hearts 1 without MTGS:

    F1 - save state
    (Shift +) F2 - cycle states
    F3 - load state
    F10 - dump performance counters
    F11 - save GS state
    F12 - dump hardware registers

PCSX2 Playground (beta) - compiled on Jan  1 2009

Savestate version: 8b400001

EE pc offset: 0x2a8, IOP pc offset: 0x208

x86Init:
    CPU vender name =  AuthenticAMD
    FamilyID  =  2
    x86Family =  AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
    CPU speed =  2.902 Ghz
    Cores     =  2 physical [2 logical]
    x86PType  =  Standard OEM
    x86Flags  =  178bfbff 00002001
    x86EFlags =  ebd3fbff

Features:

    Detected MMX
    Detected SSE
    Detected SSE2
    Detected SSE3
    Not Detected SSE4.1

 Extended AMD Features:

    Detected MMX2
    Detected 3DNOW
    Detected 3DNOW2

EE Recompiler data reset

vtlb/mmap: Block Tracking reseted ..

Bios Version 1.70

**************
rom1 NOT FOUND
**************

**************
rom2 NOT FOUND
**************

**************
erom NOT FOUND
**************

Framelimiter rate updated (UpdateVSyncRate): 59.94 fps

IOP Recompiler data reset

_openfile /mnt/lumin/mediashare/isos/kh1.iso 0
detected blocksize = 2048
isoOpen: /mnt/lumin/mediashare/isos/kh1.iso ok
offset = 0
blockofs = 24
blocksize = 2048
blocks = 1478048
type = 2
ZeroGS: creating
ZeroGS: Got Doublebuffered Visual!
ZeroGS: glX-Version 1.3
ZeroGS: Depth 24
ZeroGS: you have Direct Rendering!
ZeroGS: Disabling MRT depth writing
ZeroGS: Creating effects
ZeroGS: Creating extra effects
ZeroGS: using accurate shaders
ZeroGS: initialization successful
[New Thread 0xeec68b90 (LWP 4296)]

* PCSX2 *: ExecuteBios

MAP TLB 0: 70000000-> [00000000 00000000] S=-2147483648 G=1 ASID=0 Mask= 000

OMG SPRAM MAPPING 70000000 00000000

[Thread 0xeec68b90 (LWP 4296) exited]
# Initialize memory (rev:3.63, ctm:393Mhz, cpuclk:295Mhz detected)

MAP TLB 0: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 1: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 2: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 3: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 4: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 5: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 6: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 7: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 8: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 9: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 10: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 11: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 12: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 13: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 14: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 15: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 16: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 17: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 18: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 19: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 20: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 21: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 22: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 23: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 24: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 25: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 26: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 27: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 28: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 29: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 30: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 31: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 32: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 33: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 34: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 35: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 36: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 37: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 38: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 39: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 40: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 41: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 42: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 43: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 44: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 45: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 46: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 47: 00000000-> [00000000 00000000] S=0 G=0 ASID=0 Mask= 000
MAP TLB 0: 70000000-> [00000000 00000000] S=-2147483648 G=1 ASID=0 Mask= 000

OMG SPRAM MAPPING 70000000 00000000

MAP TLB 1: 00000000-> [00000000 01000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 2: 02000000-> [02000000 03000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 3: 04000000-> [04000000 05000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 4: 06000000-> [06000000 07000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 5: 08000000-> [08000000 09000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 6: 0a000000-> [0a000000 0b000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 7: 0c000000-> [0c000000 0d000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 8: 0e000000-> [0e000000 0f000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 9: 10000000-> [40000000 41000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 10: 12000000-> [42000000 43000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 11: 14000000-> [44000000 45000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 12: 16000000-> [46000000 47000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 13: 18000000-> [48000000 49000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 14: 1a000000-> [4a000000 4b000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 15: 1c000000-> [4c000000 4d000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 16: 1e000000-> [4e000000 4f000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 17: 20000000-> [50000000 51000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 18: 22000000-> [52000000 53000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 19: 24000000-> [54000000 55000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 20: 26000000-> [56000000 57000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 21: 28000000-> [58000000 59000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 22: 2a000000-> [5a000000 5b000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 23: 2c000000-> [5c000000 5d000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 24: 2e000000-> [5e000000 5f000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 25: 30000000-> [60000000 61000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 26: 32000000-> [62000000 63000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 27: 34000000-> [64000000 65000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 28: 36000000-> [66000000 67000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 29: 38000000-> [68000000 69000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 30: 3a000000-> [6a000000 6b000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 31: 3c000000-> [6c000000 6d000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 32: 3e000000-> [6e000000 6f000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 33: 40000000-> [70000000 71000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 34: 42000000-> [72000000 73000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 35: 44000000-> [74000000 75000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 36: 46000000-> [76000000 77000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 37: 48000000-> [78000000 79000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 38: 4a000000-> [7a000000 7b000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 39: 4c000000-> [7c000000 7d000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 40: 4e000000-> [7e000000 7f000000] S=0 G=1 ASID=0 Mask= FFF
MAP TLB 41: 7fffe000-> [00000000 00000000] S=0 G=1 ASID=0 Mask= 000
MAP TLB 42: 7fffc000-> [00000000 00000000] S=0 G=1 ASID=0 Mask= 000
MAP TLB 43: 7fffa000-> [00000000 00000000] S=0 G=1 ASID=0 Mask= 000
MAP TLB 44: 7fff8000-> [00000000 00000000] S=0 G=1 ASID=0 Mask= 000
MAP TLB 45: 7fff6000-> [00000000 00000000] S=0 G=1 ASID=0 Mask= 000
MAP TLB 46: 7fff4000-> [00000000 00000000] S=0 G=1 ASID=0 Mask= 000
MAP TLB 47: 7fff2000-> [00000000 00000000] S=0 G=1 ASID=0 Mask= 000

loadcore RegisterLibraryEntries (3af0): excepman

vtlb miss : addr 0x7C8083F0, mode 0

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf663f970 (LWP 4287)]
0x080eaa60 in vtlbUnmappedVRead32<0u> (addr=2088797168, data=0x8857610) at 
vtlb.cpp:211
211     verify(false);
(gdb) bt
#0  0x080eaa60 in vtlbUnmappedVRead32<0u> (addr=2088797168, data=0x8857610) at
vtlb.cpp:211
#1  0x0d014e02 in ?? ()
#2  0x081b75c0 in execute () at ix86-32/iR5900-32.cpp:1686
#3  0x081b75d8 in recExecuteBlock () at ix86-32/iR5900-32.cpp:1717
#4  0x08080171 in cpuExecuteBios () at R5900.cpp:661
#5  0x0806ad0a in RunExecute (elf_file=0x0, use_bios=false) at GtkGui.cpp:199
#6  0x0806ae56 in OnFile_RunCD (menuitem=0x887c188, user_data=0x0) at 
GtkGui.cpp:226
#7  0xf7a95f81 in g_cclosure_marshal_VOID__VOID () from 
/usr/lib/libgobject-2.0.so.0
#8  0x0887c188 in ?? ()
#9  0x00000000 in ?? ()

Original comment by arcum42@gmail.com on 1 Jan 2009 at 2:13

GoogleCodeExporter commented 8 years ago 
Unfortunately it doesn't mean much to me. :(

It's getting further into the init process now at least.  All of the Map Tlb 
logs are
correct, and the excepman also.  So it looks like the emulation state is at 
least
correct enough to start emulation now.

There's another problem even once you get that working.  VTLB, like VM, requires
SIGSEGV handling.  It has to be able to intercept the SIGSEGV and return 
control to
the emulator in certain situations.  It's possible, I was reading a little bit 
about
it earlier.

But that's not the problem here (yet).  The first "official" SIGSEGV shouldn't 
happen
until after all the initial libraries are loaded and the EE does its hardware
initialization procedure.

Original comment by Jake.Stine on 1 Jan 2009 at 2:35

GoogleCodeExporter commented 8 years ago 
Oh well, I hoped. I can give you more of the logging, btw. I didn't have most 
of the
log checkmarks checked when I ran it that time.

And as far as SIGSEGV handling, I suppose we could run signal(SIGSEGV, 
SegHandler) or
the like, though expecting the code to segfault at a point seems odd...

And it looks like I'm not going to do the commit I'd planned tonight, as I'm 
about
ready to get to bed at this point...

Original comment by arcum42@gmail.com on 1 Jan 2009 at 2:59

GoogleCodeExporter commented 8 years ago 
>> And as far as SIGSEGV handling, I suppose we could run signal(SIGSEGV, 
SegHandler)
or the like, though expecting the code to segfault at a point seems odd...

Yup, that's the idea.  And it's not odd.  It's a speedup -- the alternative is 
to
manually heck *every* read/write the PS2 does for validity.  It's easier/faster 
to
use the x86's built-in memory protection features to trap those memory accesses 
and
handle them in the appropriate way.

But I'm bothered that the emu isn't getting very far.  Does the Interpreter 
have the
same problem?

Original comment by Jake.Stine on 1 Jan 2009 at 3:20

GoogleCodeExporter commented 8 years ago 
Well, for interpreter mode I'v got:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb733f6c0 (LWP 32718)]
0x080f0530 in vtlbUnmappedVRead32<0u> (addr=1040290800, data=0xbfe5edac) at 
vtlb.cpp:212
212     verify(false);
(gdb) bt
#0  0x080f0530 in vtlbUnmappedVRead32<0u> (addr=1040290800, data=0xbfe5edac) at
vtlb.cpp:212
#1  0x080eedd8 in vtlb_memRead32 (mem=3154117616, out=0xbfe5edac) at 
vtlb.cpp:105
#2  0x080cf1c3 in EE::Interpreter::OpcodeImpl::LW () at Interpreter.cpp:522
#3  0x080d02d5 in intExecuteBlock () at Interpreter.cpp:129
#4  0x08082ba5 in cpuExecuteBios () at R5900.cpp:661
#5  0x0806d42e in RunExecute (elf_file=0x0, use_bios=false) at GtkGui.cpp:199
#6  0x0806d576 in OnFile_RunCD (menuitem=0x9960988, user_data=0x0) at 
GtkGui.cpp:226
#7  0xb79ed054 in g_cclosure_marshal_VOID__VOID () from 
/usr/lib/libgobject-2.0.so.0
#8  0xb79df90b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#9  0xb79f2e5d in ?? () from /usr/lib/libgobject-2.0.so.0
#10 0x099e5928 in ?? ()
#11 0x00000000 in ?? ()

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 3:33

GoogleCodeExporter commented 8 years ago 
And last code output was:

or  a2, a2, a1
andi    a3, a3, 0x0700
or  a2, a2, v0
ori a0, a0, 0x0040
sll t0, t0, 0x09
lui v1, 0xB000
sw  a2, 0x0050(sp)
or  a0, a0, a3
andi    t0, t0, 0x3800
ori v1, v1, 0xF400
lui v0, 0xB000
or  s0, a0, t0
sw  a2, 0x0000(v1)
ori v0, v0, 0xF420
sw  s0, 0x0000(v0)
jal 0x0FC439A0
daddu   s0, zero, zero
addiu   sp, sp, 0xFFF0
sd  ra, 0x0000(sp)
jal 0x0FC43950
addiu   a0, zero, 0x0002
lui a1, 0xBC00
Ошибка сегментирования

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 3:39

GoogleCodeExporter commented 8 years ago 
o'k, and I see something interesting with this LW instructions:

addr Oxb000f430 ,  Imm 0 , RS 2 
   hand 6, 0xe0000006 :x 720911
addr Oxb000f400 ,  Imm 0 , RS 17 
   hand 6, 0xe0000006 :x 720911
addr Oxb000f430 ,  Imm 0 , RS 9 
   hand 6, 0xe0000006 :x 720911
addr Oxb000f430 ,  Imm 0 , RS 2 
   hand 6, 0xe0000006 :x 720911
addr Ox70003e64 ,  Imm 4 , RS 29 
addr Oxbc0003f0 ,  Imm 1008 , RS 5 
   hand 0, 0x02055000 :x 770048

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb73a86c0 (LWP 2770)]

So before segfault we have vmv = 2055000 -- it's seems that somewhere vmap got
incorrectly shifted value.

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 4:20

GoogleCodeExporter commented 8 years ago 
I think I found source of trouble: psxM is still negative. 

    vtlb_MapBlock(psxM,0x1c000000,0x00800000);

It's from  where LW op want to read (I am shure, 770048 = 0xbc000, paddr = 
0x1c000000)

But psxM == 0xb600d000, so it is not good!

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 6:13

GoogleCodeExporter commented 8 years ago 
I was able to start pcsx2 interpreter mode with following patch. It doing the 
same
magic, that in r531 but with pcxMem.cpp memory variables. And P3FES works at 
5-7 FPS.

But there is also memory mapping in VU0micro and VU1micro and EERec's version 
still
segafaulted.

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 6:58

Attachments:

GoogleCodeExporter commented 8 years ago 
The memory mapping in the VUmicro code shouldn't matter, I think.  Those use 
their
own memory addressing which is not a TLB system.  When does the EERec version
segfault?  Please post the last 4-6 lines of the console log.  If it's right 
after
the EE init sequence then it's because we need to implement a SIGSEGV handler.  
The
sequence looks like this in the console:

# EE Initialization
# Initializing GS.
# Initializing VIF.
...etc.

It's shortly after that when the first "natural" SIGSEGV occurs.  So if that's 
where
you're crashing in the EERecs that's "good" news.  Once we have a proper 
handler in
place we should be that much closer to getting it running :D

Original comment by Jake.Stine on 1 Jan 2009 at 8:06

GoogleCodeExporter commented 8 years ago 
Well, EERec version Segfaulted after Bios call 3c (it's in interpreter.cpp), 
but not
in this call, seems that in next ops.

E/8000e3f8 00f66fe1: INTC_STAT Write 32bit 0
E/8000e3f8 00f66fe1: INTC_MASK Read  32bit 1002
E/8000e3f8 00f66fe1: INTC_MASK Write 32bit 0
# Initialize VIF0 ...

E/8000e220 00f6737b: Recompiling COP2:8000e220 4848e000:8000e220 
4848e000:8000e220
4848e000:CFC2   ,00000002 (t0),00000000 (FBRST),
E/8000e220 00f6737b: Recompiling COP2:8000e220 48c8e000:8000e220 
48c8e000:8000e220
48c8e000:CTC2   ,00000000 (FBRST),00000002 (t0),
E/8000e3f8 00f6739e: INTC_STAT Write 32bit 0
E/8000e3f8 00f6739e: INTC_MASK Read  32bit 1002
E/8000e3f8 00f6739e: INTC_MASK Write 32bit 0
# Initialize IPU ...

E/8000ded8 00f67714: IPU1dma 1
E/8000e3f8 00f677c1: INTC_STAT Write 32bit 100
E/8000e3f8 00f677c1: INTC_MASK Read  32bit 1002
E/8000e3f8 00f677c1: INTC_MASK Write 32bit 0
E/8000e3f8 00f677d7: INTC_STAT Write 32bit 0
E/8000e3f8 00f677d7: INTC_MASK Read  32bit 1002
E/8000e3f8 00f677d7: INTC_MASK Write 32bit 0
# Initialize FPU ...

# Initialize User Memory ...

# Initialize Scratch Pad ...

# Initialize Done.

EE DECI2 Manager version 0.06 Feb  7 2002 16:41:20

  CPUID=2e20, BoardID=0, ROMGEN=2002-0207, 32M

E/80000940 01f2ffce: DMAC_STAT Read  32bit 0
E/80000960 01f2ffd5: DMAC_STAT Write 32bit 800000
E/8000fd84 01f2fff7: Unknown Hardware Read 32 at 1000e000, ret 1
E/8000fd84 01f2fff7: DMAC_CTRL Write 32bit 1
E/8000fd84 01f2fff7: SIF2dma 0
E/800062ac 01f3016b: SIF0dma 0
E/800062ac 01f3016b: SIF1dma 0
E/80006348 01f3017b: SIF0dma 0
E/80006348 01f3017b: Unknown Hardware write 32 at 1000c020 with value 0 
(70030c13)
E/80006348 01f3017b: SIF0dma 184
E/80006348 01f3017b: Unknown Hardware Read 32 at 1000c000, ret 184
E/800063b0 01f3019d: SIF1dma QWC = 0
E/800063b0 01f3019d: SIF1dma TADR = 211c0
E/80006304 01f301c1: iop Sif reg write bd000040 value 40
E/80006304 01f301c1: iop Sif reg write bd000010 value 0
E/80006304 01f301c1: iop Sif reg write bd000030 value 10000
E/80005510 01f33234: iop Sif reg write bd000010 value 1

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 8:15

GoogleCodeExporter commented 8 years ago 
E/800063b0 01f3019d: SIF1dma TADR = 211c0
E/80006304 01f301c1: iop Sif reg write bd000040 value 40
E/80006304 01f301c1: iop Sif reg write bd000010 value 0
E/80006304 01f301c1: iop Sif reg write bd000030 value 10000
E/80005510 01f33234: iop Sif reg write bd000010 value 19600
E/00082068 01f51ba2: Bios call: RFU060 (3c)

Always after Bios call -- segafault in EE rec, but not in interperter

And MGTS segfaulted because m_WritePos is not aligned by 16 -- it's 
0xb5e25008,

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 8:17

GoogleCodeExporter commented 8 years ago 
Ok, that's good.  That's right where it would crash normally on the Win32 build
without the exception handler.  So SIGSEGV implementation is our next step. :)

As for MTGS, m_WritePos ... the SendSimplePacket function does this for example:

*((u32*)m_WritePos+4) = param0;
*((u32*)m_WritePos+8) = param1;
*((u32*)m_WritePos+12) = param2;

... is that where it's crashing?  That should be the only time m_WritePos 
writes are
unaligned, but then I'm not sure why that'd cause a segfault anyway... :/

Original comment by Jake.Stine on 1 Jan 2009 at 8:35

GoogleCodeExporter commented 8 years ago 
No, on first step -- after initialization m_WritePos is not aligned

Original comment by Zeydl...@gmail.com on 1 Jan 2009 at 8:44

GoogleCodeExporter commented 8 years ago 
Hmm.. so that means the m_RingBuffer array is not being aligned either?  Does 
GCC not
support the attribute for alignment on class members?

Original comment by Jake.Stine on 1 Jan 2009 at 8:47

GoogleCodeExporter commented 8 years ago 
Well, it seems that alignment is not working.

Original comment by Zeydl...@gmail.com on 2 Jan 2009 at 3:24

GoogleCodeExporter commented 8 years ago 
Hrm.. well at least it's easy enough to change it over to a dynamic allocation. 
 I
just figured that since it's a fixed length might as well make it an array part 
of
the class save an extra block allocation. :)

Original comment by Jake.Stine on 2 Jan 2009 at 6:01

GoogleCodeExporter commented 8 years ago 
Then VU0.Mem and VU1.Mem hacks (that's should not be negative too). And a 
question:

in R5900.cpp:645 there is 
        Cpu->ExecuteBlock();
But where is Cpu is initialized? It's Null for me, and I have no idea, why this 
code
working?

Original comment by Zeydl...@gmail.com on 24 Jan 2009 at 12:15

Attachments:

GoogleCodeExporter commented 8 years ago 
Aha, it's now in SysResetExecutionState()! So windows RunExecute call it, but 
Linux
one does not. Good.

Original comment by Zeydl...@gmail.com on 24 Jan 2009 at 12:35

GoogleCodeExporter commented 8 years ago 
Since Linux works with vtlb, though buggily, closing.

Original comment by arcum42@gmail.com on 4 Feb 2009 at 1:18