| Re: [hatari-devel] Wrong MODE SENSE data length for page code 0x3f |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi Uwe,
On 26.10.2024 0.13, Uwe Seimet wrote:
They seem to change Linux SCSI boot messages from:
....
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.
Gah, I should not have compared to old trace info, it was too old.
When taking output with exactly same machine setup, using git commits
just before and after your patches, the only difference is actually this:
-sd 0:0:0:0: [sda] Mode Sense: 2c 00 00 00
+sd 0:0:0:0: [sda] Mode Sense: 2b 00 00 00
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.
This one command Linux does only once.
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
------------------------------------------
But this one it does many times.
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.
Does the attached patch look OK?
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
sd 0:0:0:0: Device offlined - not ready after error recovery
sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ERROR
driverbyte=DRIVER_OK cmd_age=40s
sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00
I/O error, dev sda, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Buffer I/O error on dev sda, logical block 0, async page read
sd 0:0:0:0: rejecting I/O to offline device
I/O error, dev sda, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Buffer I/O error on dev sda, logical block 0, async page read
sda: unable to read partition table
sd 0:0:0:0: [sda] Attached SCSI disk
VFS: Cannot open root device "/dev/sda" or unknown-block(8,0): error -6
-------------------------------------
The complaint about partition table is odd. Device is just an EXT2
partition, there's no partition table.
Same image is fine as IDE device, without partition table...
- Eero
From 44884387f80502435f2f0d3a05c0e3279136330d Mon Sep 17 00:00:00 2001
From: Eero Tamminen <oak@xxxxxxxxxxxxxx>
Date: Sat, 26 Oct 2024 01:31:01 +0300
Subject: [PATCH] Do not warn about odd, but valid SCSI mode sense buffer sizes
And keep update writes within requested size.
---
src/hdc.c | 21 ++++++---------------
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/src/hdc.c b/src/hdc.c
index 6462e477..69c54d93 100644
--- a/src/hdc.c
+++ b/src/hdc.c
@@ -125,6 +125,7 @@ static int HDC_GetCommandByteCount(SCSI_CTRLR *ctr)
/**
* Return the count specified in the current ACSI command block.
+ * Value is unsigned as ctr->command values are unsigned.
*/
static int HDC_GetCount(SCSI_CTRLR *ctr)
{
@@ -249,28 +250,19 @@ static void HDC_Cmd_RequestSense(SCSI_CTRLR *ctr)
uint8_t *retbuf;
nRetLen = HDC_GetCount(ctr);
+ assert(nRetLen >= 0);
LOG_TRACE(TRACE_SCSI_CMD, "HDC: REQUEST SENSE (%s).\n", HDC_CmdInfoStr(ctr));
- if ((nRetLen < 4 && nRetLen != 0) || nRetLen > 22)
- {
- Log_Printf(LOG_WARN, "HDC: *** Strange REQUEST SENSE ***!\n");
- }
+ retbuf = HDC_PrepRespBuf(ctr, nRetLen);
+ ctr->status = HD_STATUS_OK;
- /* Limit to sane length */
if (nRetLen <= 0)
- {
- nRetLen = 4;
- }
- else if (nRetLen > 22)
- {
- nRetLen = 22;
- }
+ return;
- retbuf = HDC_PrepRespBuf(ctr, nRetLen);
memset(retbuf, 0, nRetLen);
- if (nRetLen <= 4)
+ if (nRetLen >= 4 && nRetLen < 22)
{
retbuf[0] = dev->nLastError;
if (dev->bSetLastBlockAddr)
@@ -314,7 +306,6 @@ static void HDC_Cmd_RequestSense(SCSI_CTRLR *ctr)
fprintf(stderr,"\n");
*/
- ctr->status = HD_STATUS_OK;
}
--
2.39.5