search

sarah-walker-pcem / pcem

PCem
http://pcem-emulator.co.uk
GNU General Public License v2.0
1.54k stars 217 forks source link

Segfault in vNext on Raspberry PI 5 when using Voodoo card #272

Open Mr-Shibari opened 2 months ago

Mr-Shibari commented 2 months ago

Describe the bug On the Raspberry PI 5 PCEM vNext (dev) crashes randomly when using a Voodoo card and playing 3D games. The crashes are random; sometimes the game runs for half an hour and sometimes it crashes after few seconds.

I am using the 64-bit version of Ubuntu 24.04 LTS (Noble Numbat) and also tried with Raspbian (Bookworm), both crash the same way. Also tried to compile on 32-bit Raspbian but that gave me errors while compiling and I gave up on that.

The type of the Voodoo card does not matter, got crashes on all of them.

The emulated OS is Windows 98, games I tried were Unreal Return to Napali and Half Life original.

To Reproduce Compile PCEM on the PI5 using the Ninja method, then spin up a Windows 98 machine on a PI5 and play a 3D game using the accelerator. My config was Intel Pentium 100/66 on a [Super 7] FIC VA-503+ MB with SB16 and a Voodoo 2. As mentioned, the type of the card does not matter, Voodoo 3 2000/3000 also crash PCEM.

Expected behavior Uninterrupted play of great retro games.

Emulator configuration

Host machine

Additional context Backtrace:

Core was generated by `./pcem'. Program terminated with signal SIGSEGV, Segmentation fault.

0 readmemb (a=161623) at /home/pi/pcem/pcem/src/cpu/808x.c:63

63 return (uint8_t )(readlookup2[(a) >> 12] + (a)); [Current thread is 1 (Thread 0xffff54c0ed40 (LWP 14648))] (gdb) bt full

0 readmemb (a=161623) at /home/pi/pcem/pcem/src/cpu/808x.c:63

1 0x0000aaaabdf5f12c in dumpregs () at /home/pi/pcem/pcem/src/cpu/808x.c:554

    c = 161623
    d = 0
    e = 0
    f = 0xffff28000b70

2 0x0000ffff885da238 in fatal

(format=0xaaaabe21b0f8 "Bad CMDFIFO packet %08x %08x\n")
at /home/pi/pcem/pcem/src/plugin-api/logging.c:94
    buf = "Bad CMDFIFO packet 4b615b4e 0028d010\n", '\000' <repeats 339 times>...
    ap = {__stack = 0xffff54c0e400, __gr_top = 0xffff54c0e400, __vr_top = 0xffff54c0e3c0, __gr_offs = -56, __vr_offs = -128}

3 0x0000aaaabe133ee8 in voodoo_fifo_thread (param=0xaaab008cafd0)

at /home/pi/pcem/pcem/src/video/vid_voodoo_fifo.c:454
    start_time = 8797239092367
    mask = 0
    num_verticies = -1
    v_num = 4
    end_time = 8797239092312
    header = 1264671566
    addr = 129792
    smode = 9
    num = -1
    voodoo = 0xaaab008cafd0

4 0x0000ffff87d3597c in start_thread (arg=0xffff885c9760)

at ./nptl/pthread_create.c:447
    ret = <optimized out>
    pd = 0xffff885c9760
    out = <optimized out>
    unwind_buf = {cancel_jmp_buf = {{jmp_buf = {281472095289344, 8388608, 281472103671160, 281472969512800, 281472960517632, 2, 281472095223808, 281472961740800, 281472969510944, 281472095223808, 281472103671248, 3967263087303992652, 0, 3967263090811442940, 0, 0, 0, 0, 0, 0, 0, 0}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
    not_first_call = 0

5 0x0000ffff87d9ba4c in thread_start ()

at ../sysdeps/unix/sysv/linux/aarch64/clone3.S:76
JosepMaJAZ commented 1 month ago

Just adding some information.

It seems it received a cmd that it doesn't recognise, concretely Bad CMDFIFO packet 4b615b4e 0028d010 And happens when header & 7 is 6 or 7 ( and 4b615b4e is 6) https://github.com/sarah-walker-pcem/pcem/blob/f6132a2a124b9265550ff8c99a334fd5e8904ac2/src/video/vid_voodoo_fifo.c#L454

Since this is a fatal, this causes the application to stop, reporting information.

But then, there is an additional problem where it crashes while saving a memory dump to disk (rram), when compiled in debug (or basically without the RELEASE_BUILD compile time define) :

_dumpregs();

https://github.com/sarah-walker-pcem/pcem/blob/f6132a2a124b9265550ff8c99a334fd5e8904ac2/src/cpu/808x.c#L557

Does a loop and crashes doing :

return *(uint8_t *)(readlookup2[(a) >> 12] + (a));

With loop value 161623

So you need to find out why or when it receives that unknown cmd. You might initially try just logging (pclog) instead of doing fatal on those default cases to check if the program can continue without important glitches ( since it would log the message, you could know if it happened)

Fixing the dumpregs would be a separate issue. You could open it referencing this issue in order to track it.