Investigate handling of bus settle delay #71
Comments
|
@jcres69 Can you please add detailed information on your setup, e.g. Pi OS version, Pi type, board version and computer type? In case you have more than one SCSI cable, do you have the same problem also with a different cable? How long is your cable? Is it a proper SCSI cable or a cable originally meant to be used for a different purpose, e.g. a centronics cable? Also ensure that your board is terminated. Please also add logging information on trace level, but try to restrict the log to about 30 lines before the warning. Please only attach a hard drive for any further testing, but no other devices. |
|
I'll gather the traces and add below. pi@raspberrypiOS: Debian GNU/Linux 12 (bookworm) aarch64
|
|
@jcres69 Please remember to check that your board is properly terminated. |
|
I verified the rascsi board is terminated... here is the trace file with two warning messages. only one drive was attached, nothing else. [2024-02-22 15:51:34.705] [debug] (ID 6) - Controller is executing READ(10), CDB $28:00:00:18:10:ab:00:00:01:00 |
|
@jcres69 Thank you for the log. It confirms what I have already guessed: A write operation is sometimes interrupted in the middle of sending data to the board. A signal line that should remain unchanged during the transfer has changed. Neither piscsi nor s2p actively change this line during a transfer. This is an outgoing line, and thus I think that the Mac can also not change it. |
|
@uweseimet Sure I can do that, happy to help! |
|
@jcres69 There is an "issue_71" branch now. This branch is identical with the current develop branch, but I removed the delay that I re-added for release 2.0.1. Are you running any other software on your Pi that makes use of the Pi's timers or the GPIO port? This would probably be software that is not part of the regular Pi OS distribution. |
|
@uweseimet There is no other software installed like that, that I know of. the only software I installed other than what came with the distribution was scsi2pi. |
|
@uweseimet - After testing with this version I confirmed the problem is resolved. I do not see any scsi errors... |
|
@jcres69 Thank you for testing. This means, that for you SCSI2Pi (and very likely also PiSCSI) only appear to work with a non-standard timing. Unfortunately I cannot make this timing the default because it violates the SCSI standard (SCSI2Pi reads data from the bus too fast), and because it is less reliable. Even though I cannot change SCSi2Pi to always use this timing, if you are sure that this timing works for you, you can quite easily enforce this timing by modifying the SCSI2Pi sources before compiling them. In order to do that, in cpp/buses/rpi_bus.cpp just comment out or remove these lines at the end of the file: This change, which I also applied for the branch you were testing, removes the so-called SCSI bus settle delay. |
This is exactly what I did many times and the data is good after copying. When troubleshooting this with the piscsi software, I was told it is a hardware problem, so I spent a lot of time troubleshooting the Mac plus hardware, three logic boards, ram, scsi cables, nothing resolved it other than the s2p software. I had stopped using the piscsi because these scsi errors made it unusable as it would cause the Mac to hang. I also remember there were other people besides me who had been using the piscsi that had the same problems with the Mac Plus. I can do more testing as you suggested, editing the source file. But I'm thinking this is a specific issue with the Plus... |
|
Was it always the Mac Plus that was affected? Anyway, I don't see anything more I can do. With your help it was possible to collect more details on these timing issues, even though there does not seem to be a SCSI-compliant solution for it. But if you don't have any issues when omitting the bus settle delay there is at least some kind of solution for you, which is better than nothing ;-). Maybe other users with the same problem can confirm that this work-around also works for them. |
|
Yes, I think this is a good solution for me. Thanks! |
|
@uweseimet Just FYI, I did as you suggested and deleted those lines from cpp/buses/rpi_bus.cpp after git pull from main, compiled version 3.0 and it works good, but got these errors when compiling. not sure if this is a problem just wanted to know if I did something wrong: /usr/include/c++/12/bits/char_traits.h:431:56: warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict] /usr/include/c++/12/bits/char_traits.h:431:56: warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 9223372036854775810 or more bytes at offsets -4611686018427387902 and [-4611686018427387903, 4611686018427387904] may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict] make[1]: Leaving directory '/home/pi/scsi2pi/cpp' |
|
@jcres69 You can ignore these messages. They are related to some compiler-internal code, not the the actual SCSI2Pi code. You may have to install clang++ on your Pi (with apt install) first. |
|
@uweseimet I don't see the issue_82 branch - I did read #82 and agree about the silverlining drivers. However, even with silverlining, the piscsi software still gives me the scsi errors. only with the "fixed" version of s2p is it completely resolved for me. |
|
@jcres69 I forgot to mention that I deleted the branch because all changes are now contained in the develop branch. Can you please use the develop branch and add a trace log of the error message you get (please only the relevant part of the log, i.e. just a few lines) to this ticket. I am asking for this because I would like to ensure that we collect all available information, for potential future reference. |
|
@uweseimet I got this error after attempting to boot the first time using the develop branch, but have not been able to recreate this again... the Mac would not boot at first, but now there doesn't seem to be a problem. [2024-03-05 15:56:06.001] [debug] (ID 5) - Controller is executing READ(6)/GET MESSAGE(6), CDB $08:00:00:00:01:00 |
This confirms that the error is related to the REQ/ACK handshake, but that it happens in a different part of the handshake as in #82. Thank you for running this test. |
This is a follow-up ticket to PiSCSI/piscsi#656 and #20.
It has turned out that for @jcres69 piscsi/s2p only seem to work with a non-standard SCSI timing. SCSI2Pi 2.0 is working for him, SCSI2Pi 2.0.1 is not. There are messages like
(With piscsi v23.11.01 the problem is the same, just the message is different.) The messages indicate that the board and the computer "lose" the connection in the DATA OUT phase, i.e. not all required data for the respective SCSI command are received because the bus phase appears to change before the end of the data transfer.
Device 5 is a DaynaPort, device 6 a hard drive.
Completely removing the bus settle delay appears to resolve the problem but is not SCSI compliant and causes issues (wrong data received in the DATA OUT phase) with other platforms. These issues are not necessarily immediately visible.
The text was updated successfully, but these errors were encountered: