Emulator Issues #11470
Paper Mario TTYD, complete system Hardlock after entering a pipe in great tree
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 https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds 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: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer
[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 X.org 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)
- 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.
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 https://en.wikipedia.org/wiki/Magic_SysRq_key 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.
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?)