Re: [hatari-devel] ACSI: READ/WRITE (10) incorrectly evaluate block number

[Thomas Huth <th.huth@xxxxxx>]

Am Sun, 27 Oct 2013 12:00:18 +0100
schrieb Uwe Seimet <Uwe.Seimet@xxxxxxxxx>:

> Hi,
> 
> > > Yes, this works fine now, thank you. Reading beyond the last
> > > sector is not yet rejected, though.
> > 
> > Oh, well, I (or whoever wrote that code) was assuming that doing
> > an fseek() beyond the end of the file would return an error ... but
> > it apparently does not. So I've added now additional checks for
> > correct sector numbers, so that this problem should now be gone,
> > too.
> 
> Yes, perfect. So two things remain that as far as I can tell are not
> yet as they are supposed to be:
> 
> 1. Commands like READ CAPACITY (16), READ (16) or REPORT LUNS are not
> yet rejected with a Sense Key of $05 and an ASC of $20.
> 2. Trying to read a block with READ (6) from a non-existing LUN should
> return SenseKey $05 and ASC $25 but returns $00 both times. There is a
> special rule that applies when REQUEST SENSE is called with a (the
> same) non-existing LUN in order to retrieve the error information for
> the command that failed for this LUN. For this case SPC-4 says:
> 
> In response to a REQUEST SENSE command issued to a logical unit that
> reports a peripheral qualifier of 011b in its standard INQUIRY data
> (see 6.4.2) the device server shall:
> 1) Return parameter data containing sense data with the sense key set
> to ILLEGAL REQUEST and the additional sense code shall be set to
> LOGICAL UNIT NOT SUPPORTED; and
> 2) Complete the REQUEST SENSE command with GOOD status.
> 
> So in this case REQUEST SENSE does not return CHECK CONDITION even
> though error information is available.

Ok, thanks a lot for the descriptions - I think I've fixed now these
remaining issues, but it would be good if you could also do a quick
test again.

 Cheers,
  Thomas