Issue in SCSIDRV interface

[michal]

Hi,

I hope this is the right place to post.

Me and Roger Burrows (ExtenDOS author) have found an interesting bug, possibly in HD Driver's SCSIDRV implementation but I can't say 100% for sure. Maybe you can help me to shed some light on it. My test machine is Falcon030, TOS 4.04, NVDI and ExtenDOS 4.10.

Basically, while doing some experiments with real CD media I have found out that my executable freezes at one point when accessing the CD. However it was weird from the beginning: it would freeze only in 030 mode while 060 mode in both TOS and MiNT worked just fine. First I thought it is something obvious (like ST RAM vs TT RAM, size of free/allocated memory etc) but the more I dug into it, the weirder it got.

After a few days I was able to nail it down to the last byte: the difference is how memory is aligned and when certain I/O operations are done, namely:

- Fopen (file on cd)
- Fseek(454529)
- Fread(2183, buffer);

When this code is executed and the buffer is at even address, the TOS I/O error dialog is shown. However:

- it doesn't happen on TT
- it doesn't happen in EmuTOS
- it doesn't happen in MiNT
- it doesn't happen in CT60 TOS, even if forced to run and allocated from ST RAM
- it doesn't happen for files on (IDE) HDD
- it doesn't happen for USB CD
- it doesn't happen if I lower the Fread value to 2182 (or lower)
- it doesn't happen if ExtenDOS uses its own SCSI routines (there's a setting for it)
- it doesn't happen if ExtenDOS uses a different BOS (e.g. spin_sd.bos)
- it doesn't happen when I replace HD Driver with CBHD 5.02 (which also provides SCSIDRV)

but :

- it does happen for every file on the CD
- it does happen on Roger's Falcon as well
- it goes away if buffer is on odd (!) address
- buffer size doesn't matter
- free memory doesn't matter

I was lucky enough that Roger is both able to reproduce it and being the author of ExtenDOS so he could look it up what is failing: "There isn't much point you having a look at my code, I know what's happening, the only issue is why I'm getting a status error from SCSIDRV. If you can explain under what circumstances that happens, and what is the correct response, I can fix it."

As I can't really explain more than what I'm seeing, I'm posting my findings here. The attached archive contains both an executable which by default looks for P:\README.EXE but optionally takes one command line argument with a generic path to a file on CD ROM media. If the file is found, the bug manifests itself with showing the TOS I/O error message box.

I asked Roger for more details, if provided, I can post them here. In the meantime, if you have a SCSI CD drive still attached to your Atari (Falcon), could you run this test application to see whether you can reproduce it?

Thanks,
Michal

[uweseimet]

This is very strange, indeed. Please confirm that you are using the latest HDDRIVER, i.e. version 12.79, for your tests. Please also tell me whether you are using the demo version or the full version.

[uweseimet]

Thinking more about this, it will probably be tricky to investigate, but I have some ideas. It's easier to handle this by email than with postings. Please send me an email with the information I have asked for, and then we will continue by email.

We can post a summary in the forum when there are some results.

[uweseimet]

While waiting for your response to the emails I sent you, with my test results, let me summarize the current status.

Based on the SCSI_MON logs you sent me, all transfers fail with odd buffer addresses, but not with even addresses:

Code: Select all

In    tpSCSICmd $131972
  Handle $1395a
  CmdLen 6  Cmd $08:00:02:49:01:00
  TransferLen 2048  Buffer $13859c
  SenseBuffer $131922  Timeout 4004
  Flags $00
-> GOOD
In    tpSCSICmd $131972
  Handle $1395a
  CmdLen 6  Cmd $08:00:02:4A:01:00
  TransferLen 2048  Buffer $1a518f
  SenseBuffer $131922  Timeout 4004
  Flags $00
-> STATUSERROR

This is because the Falcon's DMA chip does not support transfers to odd addresses. I have verified this with a real Falcon, and also with Hatari. On Hatari I have also tried EmuTOS, and the transfer also fails. EmuTOS does not appear to detect that there is a problem, but returns broken data (all bytes return are 0).
I have used a modified SCSI Driver test suite for my tests. The test suite is open source, in case you want to verify that these transfers do not work.

A SCSI Driver cannot compensate for this DMA chip limitation. You would have to use PIO for transfers from/to odd addresses, which would be very slow. You would also have to do it that way for ACSI. And with IDE you would also need special solutions, because you cannot directly transfer words from/to odd memory addresses with the 68000, but only with the 68020 and up.

Therefore, you should never use odd transfer addresses. If this works at all, it may be slow. In your case, if I understand you correctly, it's ExtenDOS that causes the problem by providing an odd address to the SCSI Driver.

[michal]

As Uwe reported in the previous post, in the end SCSI_MON was the definite proof where the problem lies. Fortunately, Roger was kind enough to spend time on a bugfix release (which should be announced soon) and therefore HD Driver is doing its job properly.

Thank you to everyone involved, it took more than month to investigate, report, confirm and fix this issue but it was worth it. Even if CD media are niche these days.