Frequent cable errors from TI-84 + CE about tilp_and_gfm HOT 5 OPEN

Nope, that is clearly not intended functionality... when communication fails at such a rate, libti*+tilp are not usable. However, the thing is, I don't know what happens. It's news to me that it can happen on an older, non-Python Edition TI-eZ80 calculator.
It's not that libticalcs is talking garbage to the calculator, or failing to understand what the calculator returns, since communication is reliable for most non-Python Edition TI-eZ80 calculators (my older 83PCE is in that set), and even on affected calculators (my 83PCE EP is in that set), the desired operations eventually work. It shouldn't be the USB cable's fault, since the same cable has never triggered issues with other calculators.
If the issue happens at a lower level, software USB analyzers such as usbmon on Linux might help debugging the issue, but if they don't, I don't have an external USB analyzer...

Did you try using another USB port on the computer, or (not to) plug on your calculator on some form of external USB hub, if you have that ? I know that this can impact communication, since my 89 Titanium does not work at all when plugged into a USB 3 port (it's not even detected at the USB level, so libticables doesn't get a chance to see it in the first place), but it works flawlessly, with the same USB cable, when plugged into an external USB 1.1 hub or a 2.0 port.

from tilp_and_gfm.

Hmm, I have tried using different USB ports, but the error persists. Thanks for the help, I'll probably end up trying out some USB analyzers.

from tilp_and_gfm.

Well, it seems I have fixed this problem after resetting my kernel configuration. Although I changed a multitude of settings, one that stands out to me as a possible solution is disabling CONFIG_SCSI_SCAN_ASYNC. I haven't had the time to test whether it was specifically this kernel configuration, but I can probably soon.

from tilp_and_gfm.

I also get similar issues (though with much higher error rates than 1 in 3… more like 6 in 7 times) on my TI-84 Plus when attempting to restore a backup. Specifically, it gets all of the variable names and, at the very end, the PC sends a Request to Send, at which point it hangs for a few seconds and times out on the operation slv_bulk_read (see pic below for graphical error message; I can provide more extensive logs if desired). I've found that spamming the "List calculator content" button a bit before restoring can sometimes improve the error rates, though this is also inconsistent.

I am on Linux (Arch), and disabling CONFIG_SCSI_SCAN_ASYNC in the kernel does not change anything for me. I have a couple kernels installed (both xanmod-edge and regular linux from the Arch repos) and this issue occurs on both. I've also tried this both with just leaving the calculator on and with setting it to "Receive" mode (2nd → X,T,θ,n (Link) → > → 1), all to no avail.

Note that this only happens when restoring backups, and regularly sending files or listing contents works fine for me (there may be other broken operations but I have yet to find them). If you need any additional info or have anything I should test please let me know.

System info:

• PC:
  • Kernel: 5.16.1
  • TiLP2 v1.18 (cables=1.3.5, files=1.1.7, calcs=1.1.9, conv=1.1.5)
  • ^ All built from source using the AUR packages tilp, libticalcs, libticables, libtifiles, and libticonv (I tried to use the -git versions that compile from the latest commits to the repository but I was having other issues with it running due to incompatible library versions and stuff, but I'll try it again later)
• Calculator:
  • TI-84 Plus (not CE, not Silver)
  • Running OS version 2.55MP (afaik the latest)

Graphical error message:

from tilp_and_gfm.

Thanks for the report. It's interesting that the issue occurs on a 84+ as well.

It reminds me of a corner case of multi-file transfers I fixed a while ago, long after fixing single file transfer of specific sizes on multiple models. The current commit ID for the fix I'm talking about is debrouxl/tilibs@36e7d8f . I never integrated it onto the main branch because of insufficient regression testing on other models.
However, that issue and this one should be different, because that communication issue is deterministic, AFAICT.

from tilp_and_gfm.