#218 Problems restoring a specific backup
Hello,
I had a problem with a backup. I tried to restore it to my calculator (a Voyage 200) and got the following error message after some time:
Msg: timeout occured while writing to the device.
Cause: check that link cable is plugged and/or the calculator is ready.
System: Die Ressource ist zur Zeit nicht verfügbar (errno = 11)
I stripped the backup down to the problematic file. You can find it attached. The output of tilp is also attached. I think that it is a problem with the specific size of the file in the backup. The last message I get from tilp is the following
(tilp:2030): ticables-CRITICAL **: ticables_cable_send: len = 0
So it seems that a package with the length of 0 should be send. With the SilverLink attached, it seemed that there is no ACK send to this package and therefore the software timed out waiting for it.
I was able to reproduce the problem with a real Voyage 200 connected via SilverLink as well as with tiemu connected via the "TiEmu" cable. The attached output is with tiemu connected.
It seems that the problem is independend from the host operating system (Linux or Windows). I'm using an Arch-Linux with the tilp packages build from AUR in the following versions:
- libticables-1.3.4-2
- libticalcs-1.1.8-2
- libticonv-1.1.4-2
- libtifiles-1.1.6-2
- gfm-1.07-2
- tiemu-3.03-4
- tilp-1.17-3
For testing with Windows I used a tilp Version 1.16 with my real calculator.
The OS on the Voyage is the following (from About screen of the emulator)
Voyage(TM) 200 PLT
OS Version 3.10, 07/18/2005
Advanced Mathematics Software
Hardware Version 2.00
Product ID: 08-2-D-3F
I'm not sure if this bug is related to the still open one #157. But it seems simmilar.
Please tell me, if I can give you any further informations. I'm not sure if I'm allowed to append a saved state of the emulator or if this would be a copyright violation because there is the OS in it. Therefore I would prefere to send it via email if necessary.
Kind regards,
Christian
Under Debian sid amd64, I've been able to successfully transfer your backup.tig file to my real 89T running AMS 3.10, through SilverLink, 5/5 times, and subsequently, the embedded file 1/1 time. The 89T was forcefully treated as V200 through manual configuration. The V200 is one of the few TI calculator models I don't have, but all TI-68k models are very similar anyway from a linking POV.
However, TIEmu running V200 AMS 3.10 fails to receive either backup.tig, or the file it contains, through either the TIEmu or the VTI link cables. This happens even after re-enabling the early exit upon len = 0 in ticables_cable_send() for testing purposes, which would break file transfer through DirectLink on real 84+SE & 89T, so it's not that the virtual cables can't cope with a zero-length write being passed further down the stack.
Another emulator based on the libti* code receives the file embedded in backup.tig correctly.
Therefore, from your tests and my tests, the cause of the issue you're seeing, and which I can only partially reproduce, is not obvious...
Thanks for the answer. With your information, it seems to be a problem specific for the Voyage200. Like I said, I had the bug with real hardware as well as with the simulator.
If I find time, I will try to find out a little bit more about the bug at the weekend.
Is there anything specific, that I could do to help you finding the bug?
PS: Just to be clear: It is not really a horrible bug for me. It was just annoying because I have invested half a day for finding out, that this specific file is the problem with my backup. There is a newer version of the application that loads without a problem, so I probably won't have any problems with future backups. I just reported it because in my experience, some bugs are just difficult to reproduce and normally every develloper is happy if he can reproduce a bug more or less reliably.
I have tried to investigate the problem a little further. But I'm still working on it. At least I had to learn some basics about the protocoll taken from here:
http://www.ticalc.org/archives/files/fileinfo/113/11382.html
I have logged the data on the wire with help of a Saleae logicanalyzer and a self written protocoll analyzer plugin. With this I was able to get the two attached logs. (I can also provide the raw data if they are usefull for someone. Just ask.)
The one log is made with the official TI Connect software and the other with tilp2. In both cases I tried to just log the transfer of the problematic file. In the case of the TI-Connect software, I got some more communication at the beginning.
You can get just the data without time information with a simple
cut -f2 -d"," TI-Connect.txt
and compare them with a diff.
I've also appended a perl script that can format the output into a more human readable output. It's a quick and dirty script and at the moment it does not really interprete the communication well (i.e. the check sums seem to be interpreted as an extra (invalid) packet) but it does more or less, what I need: Split the data into packets.
I'm not sure if it runs on Windows. I use it on a Linux terminal. Just use it with something like
cat TI-Connect.txt | ./evaluate.pl
It seems that there is not really much difference.
The interesting part seems to be RTS some lines before the big DATA block. tilp sends the following packet:
PC: 08 RTS (C9) 11 00 6E 23 00 00 27 0A 77 6F 72 6B 5C 62 6F 64 65 78 00
While TI Connect sends the following one:
PC: 08 RTS (C9) 11 00 72 23 00 00 26 0A 77 6F 72 6B 5C 62 6F 64 65 78 00
I think that the first bytes that are different (6E vs 72) give the length of the variable. The second bytes (27 vs 26) tell the calculator if it should store the variable into the ram or flash. TI Connect stored it into the RAM while tilp2 used the flash. I will try to convince one of the two to use the other one in my future investigation. But for the moment I just wanted to give a short status report.
Beneath that it seems only that tilp2 does not react onto the
CALC: 88 ACK (56)
after the main transmission while TI Connect sends a
PC: 08 EOT (92)
for an answer.
I will tell you more, as soon as I find the time to look deeper into the problem. Hopefully that will be next weekend but it can even need some more time.
Kind regards,
Christian
I've found a fix that works at least for my real calculator.
It seems that libusb1.0 doesn't like a libusb_bulk_transfer with a length of 0. With the given variable, such a call is issued at the end of the transfer. If I prevent the call with size 0, everything works fine. You can find a patch for libticables attached to this report.
A simmilar patch for the tiemu part of the libticables doesn't work (the write in tie_put in src/linux/link_tie.c). But I would think that the problem could be simmilar. The mentioned write is called with a length of 0. The man-page of write (i.e. here: http://linux.die.net/man/3/write) tells that "If nbyte is zero and the file is not a regular file, the results are unspecified."
I'm not sure if I'm able to trace down the problem any further. It seems that you introduced the zero-length writes for a specific reason (at least the comment in link_xxx.c line 210) states so. Eventually it would be necessary to allow the writes only for some calculators?
Thanks for your investigation :)
Passing zero-length writes down the chain was indeed required for 84+/84+SE (and probably 84+CSE, which came later ?) and 89T DirectLink computer -> calculator transfers not to fail for files of peculiar sizes. Those sizes were precisely determined through testing after bug reports, and they are written in the code base. In those tests, the libusb 0.1 backend was used.
Until now, I had received no reports that passing 0-length writes down the chain broke something (from the moment the workaround was made at the proper location, that is), but by now, it seems clear that it does...
I guess I need to make a new round of testing on the 84+(SE) and 89T, using both SilverLink and DirectLink, both libusb 0.1 and 1.0 backends, and both regular file transfers and direct USB ROM dumping. I kept the testing files from last time. Then, depending on the results, we'll see how to proceed.
As a guess which may be invalidated by further testing: have all CableFncts.send functions, one level down from ticables_cable_send(), silently reject 0-length writes early, except the ones from the libusb 0.1 backend, where 0-length writes should remain unconditionally allowed, and possibly conditionally reject such writes in the libusb 1.0 backend.
Thanks for the response. Just tell me, if I can help any further.
Just to be clear: I'm still not sure if it is the same for the tiemu "cable". Like I said, even if I did not allow a 0-length write to it, it didn't work. It seemed that the read following this write (the one waiting for an ACK) had problems with the read-filehandler and returned a -1. Errno was set to 11 (like stated in the error message in my first post) which roughly translate to something like "resource temporary not available". 11 could be eventually a EAGAIN but I'm not sure about that - gdb just printed the value.