Re: [hatari-devel] Linux-68k and REQUEST SENSE

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

I think I misread the log output, didn't I? The "6" is not the number of
bytes requested, but the number of command block bytes, isn't it? Linux
requested 60 bytes.
But that's even less strange. It is not unusual that the maximum number of
bytes is requested, e.g. with REQUEST SENSE or MODE SENSE, to ensure that
the device returns all available data. If there are less data to return,
this is not an error condition. The device will just send as many bytes as
it has, and will set the length field in the response to the respective
size. Just like Hatari does it with

       else if (nRetLen > 22)
        {
                nRetLen = 22;
        }

> Hi,
> 
> I just had a look at the current doc/m68k-linux.txt file.
> 
> DEBUG: raw_scsi: got command byte 00 (6/6)
> WARN : HDC: *** Strange REQUEST SENSE ***!
> DEBUG: raw_scsi: data in 22 bytes waiting
> 
> Am I right that Linux requests a 6 byte response? This is not strange, but
> perfectly legal, because Linux may just have reserved a 6 byte buffer for
> the response because it does not need more bytes. I suggest to remove this
> message.
> 
> What I actually stumbled upon is this:
> 
> DEBUG: raw_scsi: data in finished, 22 bytes: status phase
> DEBUG: DMA initiator recv PC=001c40ee
> DEBUG: SCSI BUS reset
> 
> Where does the 22 come from? The message looks as if Hatari tries to send 22
> bytes, even though a maximum of 6 was requested. If this is the case it
> explains the subsequent bus reset and the SCSI boot failure.
> 
> Have these messages been recorded with a binary based on the current
> Hatari sources? I don't think that with the latest sources Hatari sends
> 22 bytes when only 6 are requested, but maybe I am missing something.
> 
> Best regards
> 
> Uwe
> 
>