Re: [hatari-devel] Wrong MODE SENSE data length for page code 0x3f

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi Eero,

> This one command Linux does only once.

This does not mean that Linux does not need this page. If a devices does not
support a particular mode page, requesting it several times won't help ;-).
I suggest simply adding this page (caching page), even if it just in order
to get rid of the warning. Adding this mode page won't do any harm,
https://www.hddriver.net/SDRVTEST.LOG shows valid sets of a pages of a real
drive and an emulated drive.

> >> DEBUG: SCSI BUS reset
> >> sd 0:0:0:0: Device offlined - not ready after error recovery
> >> ------------------------------------------
> 
> But this one it does many times.

A bus reset means that there is an issue with the SCSI protocol, e.g. an
issue with the bus phases, wrong handling of SCSI bus signals, or a hardware
issue. This is different from a non-implemented SCSI feature, which just
results in a proper SCSI error message. SCSI error messages are expected
behavior, a bus reset is issued as a last resort when there is unexpected
behavior.

> Does the attached patch look OK?

After having a quick look at it this is what I found:

        nRetLen = HDC_GetCount(ctr);
+       assert(nRetLen >= 0);

The allocation length (I suggest renaming variables to the field names of
the SCSI specs, so that their meaning becomes clearer) is unsigned, i.e.
the assertion probably does not make sense. It is normal that an 8 bit
allocation length is >= 128, often 255.

+       if (nRetLen >= 4 && nRetLen < 22)

This does not look correct to me. As already mentioned Hatari has to ensure
that it does not return more bytes than requested. Looks to me as if the
patch returns nothing if the length is >= 22 or < 4? As long as there are
enough data available the amount of bytes specified in the allocation length
field must be returned.
 
> When using Falcon emulation instead of TT, Linux provides more info 
> about the problem:
> -------------------------------------
> ....
> DEBUG: raw_scsi: data in finished, 4096 bytes: status phase
> DEBUG: SCSI BUS reset

See my note on the bus reset above. Every error logged after the reset is
rather meaningless, because things have already gone awfully wrong before.

> Same image is fine as IDE device, without partition table...

I don't think that media without a partition table exist (except for the
superfloppy format). Linux (also Linux-68k) uses partition tables,
Windows does, macOS does. Also see https://www.hddriver.net/en/gpt.html.

>Maybe it still makes sense to log INFO message?
>"INFO: REQUEST SENSE max size (%d) differs from what old SCSI-1 drives use
>(4-22)"

I don't think that something like this should be logged. Even with SCSI-1
drives the initiator can request less than 4 or more than 22 bytes. The
number of bytes requested may even depend on the context. Usually you do not
request more data than you need. Why logging an info for something that's
normal?

I recommend to update the Hatari code to be compliant with SCSI-2, at least
for the SCSI port. For ACSI you might keep work-arounds for HDX, but you
should check whether the current work-arounds are really needed.
For TT/Falcon SCSI standards older than SCSI-1-CCS have never been relevant.
Having work-arounds that simulate devices that cannot not even be connected
to the SCSI port physically (e.g. Atari Megafile) is not recommended and
may be causing some of the Linux issues.

Physical devices connected to the Atari have usually been SCSI-2, and most
(all?) current emulations (e.g. SCSI2Pi or BlueSCSI) use SCSI-2 or newer as
the default level, which works perfectly well with the Atari, also with ACSI.

Furthermore, simulating old drives on the one hand and implementing ICD
compatibility on the other hand IMO tends to be mutually exclusive ;-).

Best regards

Uwe