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

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi Eero,

> Thanks, I applied & pushed your patches.

Thank you.

> They seem to change Linux SCSI boot messages from:
> ------------------------------------------
> DEBUG: raw_scsi_put_data got message c0 (1/1)
> DEBUG: raw_scsi_put_data got message c0 (1 bytes)
> DEBUG: raw_scsi: got command byte 1a (1/6)
> DEBUG: raw_scsi: got command byte 00 (2/6)
> DEBUG: raw_scsi: got command byte 3f (3/6)
> DEBUG: raw_scsi: got command byte 00 (4/6)
> DEBUG: raw_scsi: got command byte 04 (5/6)
> DEBUG: raw_scsi: got command byte 00 (6/6)
> TODO : HDC: Unsupported MODE SENSE command
> DEBUG: raw_scsi: no data, status = 2
> DEBUG: raw_scsi: status byte read 02. Next=1
> DEBUG: raw_scsi: message byte read 00. Next=1
> DEBUG: raw_scsi: arbitration initiator id 7 (80)
> ------------------------------------------
> 
> To:
> ------------------------------------------
> DEBUG: raw_scsi_put_data got message c0 (1/1)
> DEBUG: raw_scsi_put_data got message c0 (1 bytes)
> DEBUG: raw_scsi: got command byte 1a (1/6)
> DEBUG: raw_scsi: got command byte 00 (2/6)
> DEBUG: raw_scsi: got command byte 3f (3/6)
> DEBUG: raw_scsi: got command byte 00 (4/6)
> DEBUG: raw_scsi: got command byte 04 (5/6)
> DEBUG: raw_scsi: got command byte 00 (6/6)
> DEBUG: raw_scsi: data in 44 bytes waiting
> DEBUG: raw_scsi: data in finished, 44 bytes: status phase
> DEBUG: raw_scsi: status byte read 00. Next=1
> DEBUG: raw_scsi: message byte read 00. Next=1
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 2b 00 00 00
> DEBUG: raw_scsi: arbitration initiator id 7 (80)
> ------------------------------------------

That's strange, isn't it? The command sent has not changed, and
ctrl->command[3] is always 0, i.e. the subpage change does not make a
difference. Only the number of bytes returned has changed. Why is
"Unsupported MODE SENSE command" before my changes and not anymore after my
changes? Nothing has changed with the actual pages supported by Hatari.

> But it just means there's then next unrecognized one:
> ------------------------------------------
> DEBUG: raw_scsi_put_data got message c0 (1/1)
> DEBUG: raw_scsi_put_data got message c0 (1 bytes)
> DEBUG: raw_scsi: got command byte 1a (1/6)
> DEBUG: raw_scsi: got command byte 00 (2/6)
> DEBUG: raw_scsi: got command byte 08 (3/6)
> DEBUG: raw_scsi: got command byte 00 (4/6)
> DEBUG: raw_scsi: got command byte 04 (5/6)
> DEBUG: raw_scsi: got command byte 00 (6/6)
> TODO : HDC: Unsupported MODE SENSE mode page
> ------------------------------------------

Well, Hatari does not support page 8, does it? It only supports pages 0 and
4. Adding more should not be a big issue, though. On the other hand,
unsupported mode pages are not necessarily a problem. Not all devices have
to support all mode pages. The SCSI specifications list the meaning of the
mode pages and their fields in detail.

> And it still fails to same one:
> ------------------------------------------
> DEBUG: raw_scsi_put_data got message 80 (1/1)
> DEBUG: raw_scsi_put_data got message 80 (1 bytes)
> DEBUG: raw_scsi: got command byte 03 (1/6)
> DEBUG: raw_scsi: got command byte 00 (2/6)
> DEBUG: raw_scsi: got command byte 00 (3/6)
> DEBUG: raw_scsi: got command byte 00 (4/6)
> DEBUG: raw_scsi: got command byte 60 (5/6)
> DEBUG: raw_scsi: got command byte 00 (6/6)
> WARN : HDC: *** Strange REQUEST SENSE ***!
> DEBUG: raw_scsi: data in 22 bytes waiting
> DEBUG: raw_scsi: data in finished, 22 bytes: status phase
> DEBUG: DMA initiator recv PC=001c40ee
> DEBUG: SCSI BUS reset
> sd 0:0:0:0: Device offlined - not ready after error recovery
> ------------------------------------------
> 
> 
> Are above anything that shows in the SCSI test suite?

No, the test suite does not report any issues. You can run it yourself.
Like a lot of my software it is open source, and the binaries can be
downloaded on https://www.hddriver.net/en/scsidriver.html.

As far as I can see Hatari complains because more than 22 bytes were
requested by Linux. But there is no reason to complain. The initiator can
request any number of bytes, 96 (0x60) in this case. This number is just the
maximum number of bytes the target may return, and usually is related to the
size of the buffer the initiator has reserved for the result data. If there
are less bytes available the target just returns less, that's it. This is no
error condition.
Therefore I don't think that Hatari should log anything like this. Hatari
should also not log something when the length is < 4. The initiator can
request any length, even 0. Hatari just has to ensure that not more bytes
are returned than the initiator is expecting.
I recommend changing the code accordingly. Currently it looks to me as if
Hatari is logging errors/warnings where nothing is wrong.
> 
> PS. Please provide patches in "git format-patch origin/master" format.
> I had to copy paste your name and comments from mails to the commits.

I see, I will try to remember this.

Best regards

Uwe