USBIO Timeout with BIO2 > IO2/C02 styles #82

Closed icex2 closed 1 year ago

In GitLab by @Corin on Jul 4, 2021, 02:20

Summary

Using the BIO2 > IO2 compatibility stuff to play older styles; on boot with an older title (tricoro > sinobuz tested only) there is roughly a 50% change the USBIO will timeout on startup.

Expected behavior

USBIO should pass boot checks without issue and operate as normal

Current behavior

Occasionally USBIO will timeout on boot causing it to fail

Detailed Description

Basically same as the summary, USBIO will keep going up and you can generally tell it's going to fail because it takes longer than normal.

Unfortunately after we've enabled logging, we're unable to replicate this issue so logs will hopefully follow up soon when it happens again.

This has not been tested with any games under tricoro yet.

Steps to reproduce

Using the BIO2 > IO2 compatibility hooks for older styles, load up an older style (such as tricoro)
Boot the game
Wait for the USBIO check to finish
If it passes, reboot the game, it'll happen eventually

Context (Environment)

Bemanitools version(s) affected

5.35 (tested due to reader fixes included in this build) 5.34

Game(s) and version(s) affected

IIDX 20 tricoro
IIDX 21 SPADA
IIDX 22 PENDUAL
IIDX 23 copula
IIDX 24 SINOBUZ

Log output

See attatched logs! _7th_boot_usbio_error__log.txt

_8th_boot_usbio_error__log.txt

_boot_ok_card_ok__log.txt

_crash_before_boot__log.txt

Configuration files

See attatched iidxhook-20.conf iidxhook-20.conf

Command line arguments

See attatched gamestart-20.bat gamestart-20.bat

OS version

Windows 7 embedded

Hardware specs

CPU: AMD A10-9700
RAM: 4GB DDR4-2400
GPU: Onboard R7
Controllers/IO: BIO2 clone board (1:1)

In GitLab by @xyen on Jul 9, 2021, 07:31

Are you using any sort of multi / launcher? (ex: SGL that uses iidxio)

In GitLab by @Corin on Jul 9, 2021, 15:18

Nope, nothing like that, literally a gamestart.bat launch job

In GitLab by @xyen on Jul 10, 2021, 06:38

@Corin weird, can I get a log, I've been looking into this, but haven't been able to pin down why.

I thought it was related to the reset sequence not working correctly on BIO2, but if you're doing it from a fresh boot, that shouldn't be it.

In GitLab by @Corin on Jul 10, 2021, 17:12

@xyen sorry this took so long, just uploaded all the logs/command line stuff now!

FYI many people have reported similar issues in the past already. However, I also heard many positive reports that the C02/IO2 emulation works fine.

The game that caused a lot of trouble in particular was 10th style. I am fairly confident that these issues are somewhat connected with the janky ezusb code in the first few generations of games which rely heavily on sleeps and specific timings. The code checkpoints on various occasions if certain operations were finished within hardcoded deadlines. Depending on your setup, these timings might vary.

I don't have any proof for this, unfortunately, but I was able to reproduce very similar symptoms when running the games in a virtual machine, especially with a real IO connected.

In GitLab by @xyen on Jul 11, 2021, 11:14

@Corin try replacing the thread block in avs-config.xml with:

  <thread>
    <nr_thread __type="u16">256</nr_thread>
    <nr_semaphore __type="u16">64</nr_semaphore>
    <nr_mutex __type="u16">1024</nr_mutex>
    <nr_event __type="u16">64</nr_event>
    <pool>
      <affinity_mask __type="u64">0</affinity_mask>
    </pool>
  </thread>

In GitLab by @Corin on Jul 12, 2021, 20:54

@xyen will try this weekend, testing etc might be a bit slow because only time I can do testing is saturdays, sorry about that!

In GitLab by @Corin on Jul 20, 2021, 20:53

Update on this, unfortunately we didn't get time last weekend, we're going to try it this weekend instead, sorry again! :(

In GitLab by @xyen on Jul 21, 2021, 21:58

Instead of the above values, try nr_thread=64, nr_mutex=128 instead of nr_thread=256, nr_mutex=1024

In GitLab by @Corin on Jul 24, 2021, 14:37

Tested using those values and it IO timeouts's every time: 5 1503 0007

In GitLab by @xyen on Jul 25, 2021, 12:01

logs? but also hm, weird

Timeouts are caused by data races in konami's non-thread safe ezusb implementation. The PR "fixes" these issues as good as they can be fixed from bemanitools' perspective. Testing has shown that the timeouts are now gone (or the chance is very low to get them) on ADE-6291 hardware.

djhackersdev / bemanitools