Emulator Issues #11470

Paper Mario TTYD, complete system Hardlock after entering a pipe in great tree

Added by cyberpunkspike 13 days ago. Updated 12 days ago.

% Done:


Operating system:
Issue type:
Relates to usability:
Relates to performance:
Relates to maintainability:
Regression start:
Fixed in:


Game Name?

Paper Mario: The Thousand-Year Door

Game ID? (right click the game in the game list, properties, info tab)


MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)

[Put MD5 Hash here]

What's the problem? Describe what went wrong.

A complete system hardlock. Once in the lock, a power cycle is required.

What steps will reproduce the problem?

After entering the great tree, the second pipe to go through wipes the screen, the lock occurs once the screen is wiped black but before any new screen is created.

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

Tried it from multiple versions, the git HEAD,
and from the newest flatpak, which is revision 22ddd11573fd8d3e43a879804e7a64e50928435d.

Is the issue present in the latest stable version?

I cannot determine, as I cannot get a working 5.0 version on Fedora 28. The available RPM has non functional controllers.

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool and anyone who is building Dolphin on their own can use git bisect.)

I'd love to know, as I'd be able to play the game.

If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here:

[Attach any fifologs if possible, write a description of fifologs and screenshots here to assist people unfamiliar with the game.]

What are your PC specifications? (CPU, GPU, Operating System, more)

System:    Host: workstation01 Kernel: 4.19.5-200.fc28.x86_64 x86_64 bits: 64 Desktop: Gnome 3.28.3 
           Distro: Fedora release 28 (Twenty Eight) 
Machine:   Type: Desktop Mobo: ASUSTeK model: KGP(M)E-D16 v: Rev 1.xxG serial: <root required> BIOS: American Megatrends 
           v: 3309 date: 06/16/2016 
CPU:       8-Core: AMD Opteron 6366 HE type: MT MCP speed: 889 MHz min/max: 1000/1800 MHz 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Ellesmere [Radeon Pro WX 5100] driver: amdgpu v: kernel 
           Display: x11 server: Fedora Project 1.19.6 driver: amdgpu resolution: 3840x2160~60Hz 
           OpenGL: renderer: AMD Radeon Pro WX 5100 Graphics (POLARIS10 / DRM 3.27.0 / 4.19.5-200.fc28.x86_64 LLVM 6.0.1) 
           v: 4.5 Mesa 18.0.5 
Network:   Device-1: Qualcomm Atheros AR93xx Wireless Network Adapter driver: ath9k 
           Device-2: Intel 82574L Gigabit Network driver: e1000e 
           Device-3: Intel 82574L Gigabit Network driver: e1000e 
Drives:    Local Storage: total: 3.86 TiB used: 1.25 TiB (32.3%) 
Info:      Processes: 395 Uptime: 18m Memory: 31.39 GiB used: 2.48 GiB (7.9%) Shell: bash inxi: 3.0.28 

The inxi diag is incorrect on the 6366 HE's core numbers, it is a 16-core, as reported via /proc/cpuinfo.

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

MemoryCardA.USA.raw.xz (8.54 KB) MemoryCardA.USA.raw.xz My Memory card, XZ compressed. cyberpunkspike, 12/03/2018 02:37 AM
dolphin-emu_config.tar.gz (4.65 KB) dolphin-emu_config.tar.gz A tarball of dolphin-emu config directory, includes all ini files. cyberpunkspike, 12/03/2018 02:39 AM


#1 Updated by cyberpunkspike 13 days ago

I also forgot to mention, I encountered the hardlock on both Vulkan and OpenGL, and when running under Wayland and Xorg. I'm ready to provide more info if needed, or anything else that would help debug.

#2 Updated by JMC4789 13 days ago

Likely a driver bug, or at least, Dolphin doing something the driver doesn't handle well.

#3 Updated by cyberpunkspike 13 days ago

Even on all those options? Just where could such a bug be? If it happens under every possible graphical combination? Wayland, X11, Vulkan and OpenGL... those are radically different code paths.

#4 Updated by cyberpunkspike 13 days ago

Also why would the game work otherwise pretty great, for the entire chapter... and then have a problem in the same place as the puny's, which was historically where prior dolphin-emu bugs were identified in Paper Mario TTYD.

#5 Updated by JMC4789 12 days ago

Yes, but dolphin shouldn't be able to hardlock the system. Do you know what can? Graphics drivers.

That's why I'm saying that the graphics drivers are probably doing something wrong, even if Dolphin is doing something they don't like.

#6 Updated by cyberpunkspike 12 days ago

That would make sense, how can we narrow it down?

#7 Updated by JMC4789 12 days ago

  • Status changed from New to Questionable

You could try turning off bounding box emulation after starting the game. That would tell us if it's related to SSBOs.

I can't reproduce the issue, so I'm marking this as questionable for right now, but, hopefully we can narrow down the behavior. I'm guessing you can't really get a stacktrace if the whole kernel locks up.

#8 Updated by JonnyH 12 days ago

If it's just a graphics wedge and not a panic, the system is still up and you just can't see anything, so there's a good chance there's going to be lots of amdgpu debug info in the syslog.

Hopefully if you sync and do a (relatively) graceful reboot by one of:
- short pressing the power button (assuming your distro handles the ACPI event to shutdown and turn off)
- sysrq (depending on on how your distro is setup you may need to enable it first, then see and use the "REISUB" sequence)
- ssh in from another machine and run 'reboot'
- or just wait long enough for the disk cache to be flushed (probably not reliable, and depending on settings may be be minutes, or even "never" :)

Then please report this to the mesa/dri people, as it's their drivers with the issue. Nothing from userspace should be able to kill the drivers like this, so even if dolphin is doing something "wrong" it's a bug on them that it takes down the system. So even if dolphin "fixes" this, it's worth reporting it there too.

#9 Updated by JonnyH 12 days ago

Also, there's newer versions of mesa available with a number of fixes (the latest is 18.2.6) - is there any way you can test with that? It seems that your 18.0.5 is the latest released version for FC28 (FC29 contains the newer 18.2.4 - maybe you could try that? Or you can backport the packages?)

Also available in: Atom PDF