Segfault in vNext on Raspberry PI 5 when using Voodoo card

[Mr-Shibari]

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

• Machine: [Super 7] FIC VA-503+
• CPU: Intel Pentium 100/66
• Graphics/sound cards: Voodoo 2/SB16
• Installed OS: Windows 98 SE

Host machine

• OS: Ubuntu 24.04 LTS (Noble Numbat) 64-bit
• vNext dev [2e87d35]
• Raspberry PI 5 (overclocked to 3GHz but also crashes on stock speed)

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 =
pd = 0xffff885c9760
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]

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)

pcem/src/video/vid_voodoo_fifo.c

Line 454 in f6132a2

fatal("Bad CMDFIFO packet %08x %08x\n", header, voodoo->cmdfifo_rp);

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();

pcem/src/cpu/808x.c

Line 557 in f6132a2

putc(readmemb(c), f);

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.