[Bug 215447] New: sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[Bug 215447] New: sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

            Bug ID: 215447
           Summary: sr_mod scsi_mode_sense() failure -> "scsi-1 drive"
           Product: SCSI Drivers
           Version: 2.5
    Kernel Version: 5.15.6
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
          Assignee: scsi_drivers-other@kernel-bugs.osdl.org
          Reporter: cshorler@googlemail.com
        Regression: No

Created attachment 300216
  --> https://bugzilla.kernel.org/attachment.cgi?id=300216&action=edit
SUSE Tumbleweed default kernel with CONFIG_FUSION_LOGGING (debug_level 0x488)

scsi_lib.c: scsi_mode_sense() has defaults assuming MODE_SENSE_10, fallback to
MODE_SENSE if that fails.

sr.c: doesn't set sdev->use_10_for_ms.  In my case this causes
scsi_mode_sense() to fail and "scsi-1 drive" fallback to be selected.

I tried setting use_10_for_ms in the sr_probe() function, seems to work for
code page 0x2A, as requested by sr.c.

I'm unsure where the request for code page 0x19 originates / if failure is
acceptable or if it indicates another issue.

4 attachments

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

--- Comment #1 from Chris Horler (cshorler@googlemail.com) ---
Created attachment 300217
  --> https://bugzilla.kernel.org/attachment.cgi?id=300217&action=edit
SUSE Tumbleweed kernel with fix

notable by omission of messages (only error conditions are logged by mptscsih)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

--- Comment #2 from Chris Horler (cshorler@googlemail.com) ---
Created attachment 300218
  --> https://bugzilla.kernel.org/attachment.cgi?id=300218&action=edit
my understanding of a typical scsi messages / error codes from the logs

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

--- Comment #3 from Chris Horler (cshorler@googlemail.com) ---
Created attachment 300219
  --> https://bugzilla.kernel.org/attachment.cgi?id=300219&action=edit
add use_10_for_ms default to sr.c

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

--- Comment #4 from Chris Horler (cshorler@googlemail.com) ---
self-ping my list-email

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[Christopher Horler]

Is anyone able to comment on the sr_mod / cdrom / mptsas issue I'm
experiencing (see details in bug)?
I fixed my issue with a one line patch, but I'd like to know if it's
correct and what I should do to have it integrated upstream.

Thanks, Chris

On Sat, 15 Jan 2022 at 11:42, <bugzilla-daemon@bugzilla.kernel.org> wrote:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=215447
>
> --- Comment #4 from Chris Horler (cshorler@googlemail.com) ---
> self-ping my list-email
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are watching the assignee of the bug.

[Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

--- Comment #5 from Chris Horler (cshorler@googlemail.com) ---
Is anyone able to comment on the sr_mod / cdrom / mptsas issue I'm
experiencing (see details in bug)?
I fixed my issue with a one line patch, but I'd like to know if it's
correct and what I should do to have it integrated upstream.

Thanks, Chris

On Sat, 15 Jan 2022 at 11:42, <bugzilla-daemon@bugzilla.kernel.org> wrote:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=215447
>
> --- Comment #4 from Chris Horler (cshorler@googlemail.com) ---
> self-ping my list-email
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are watching the assignee of the bug.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[Martin K. Petersen]

Christopher,

> Is anyone able to comment on the sr_mod / cdrom / mptsas issue I'm
> experiencing (see details in bug)?  I fixed my issue with a one line
> patch, but I'd like to know if it's correct and what I should do to
> have it integrated upstream.

My concern is that switching to MODE SENSE(10) by default could break
things for other devices.

There are compelling arguments that we should use MODE SENSE(10). Most
ROM devices appear to favor it. The specs allow both but MMC3 (2001)
mentions MODE SENSE(10) as "shall implement" although it doesn't go as
far as marking it as mandatory in the SCSI command table.

In the current code we fall back to the MODE SENSE(6) command if a MODE
SENSE(10) fails. So if we change the default, unless a device hangs when
we send the 10-byte command, we should be OK.

Another option is to allow a fallback to the 10-byte command if the
6-byte command fails. We currently don't do that because MODE SENSE(6)
was required for so many years. This way we could accommodate devices
such as yours without the risk of changing the default.

The good news is that the "consumer" transports (ATA, FireWire, USB) all
use MODE SENSE(10) by default. So we are really only talking about
changing things for SPI-attached devices which typically are
well-behaved. So my hunch is that switching the default is probably OK,
although I would like the 6/10-byte fallback mechanism to work in both
directions as well.

-- 
Martin K. Petersen	Oracle Linux Engineering

[Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

--- Comment #6 from Martin K. Petersen (martin.petersen@oracle.com) ---
Christopher,

> Is anyone able to comment on the sr_mod / cdrom / mptsas issue I'm
> experiencing (see details in bug)?  I fixed my issue with a one line
> patch, but I'd like to know if it's correct and what I should do to
> have it integrated upstream.

My concern is that switching to MODE SENSE(10) by default could break
things for other devices.

There are compelling arguments that we should use MODE SENSE(10). Most
ROM devices appear to favor it. The specs allow both but MMC3 (2001)
mentions MODE SENSE(10) as "shall implement" although it doesn't go as
far as marking it as mandatory in the SCSI command table.

In the current code we fall back to the MODE SENSE(6) command if a MODE
SENSE(10) fails. So if we change the default, unless a device hangs when
we send the 10-byte command, we should be OK.

Another option is to allow a fallback to the 10-byte command if the
6-byte command fails. We currently don't do that because MODE SENSE(6)
was required for so many years. This way we could accommodate devices
such as yours without the risk of changing the default.

The good news is that the "consumer" transports (ATA, FireWire, USB) all
use MODE SENSE(10) by default. So we are really only talking about
changing things for SPI-attached devices which typically are
well-behaved. So my hunch is that switching the default is probably OK,
although I would like the 6/10-byte fallback mechanism to work in both
directions as well.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

--- Comment #7 from Chris Horler (cshorler@googlemail.com) ---
is it risky to implement the fallback mechanism in both directions? is there a
chance of forever retry? (fail 6, fail 10, fail 6, fail 10...)

scsi_lib.c:scsi_mode_sense(): ...

        if (!scsi_status_is_good(result) &&
            driver_byte(result) == DRIVER_SENSE) {
                if (scsi_sense_valid(sshdr)) {
                        if ((sshdr->sense_key == ILLEGAL_REQUEST) &&
                            (sshdr->asc == 0x20) && (sshdr->ascq == 0)) {
                                /* 
                                 * Invalid command operation code
                                 */
                                sdev->use_10_for_ms = !sdev->use_10_for_ms;
                                goto retry;
                        }
                }
        }

I guess I could increase the default retry_count at initialisation and also
decrementing it here.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[Martin K. Petersen]

> is it risky to implement the fallback mechanism in both directions? is
> there a chance of forever retry? (fail 6, fail 10, fail 6, fail 10...)

Just a heads-up that I am still working on a reasonable way to go about
this. It is not entirely trivial to perform the transition from MODE
SENSE(6) to (10) given how the SCSI disk driver works.

-- 
Martin K. Petersen	Oracle Linux Engineering

[Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

--- Comment #8 from Martin K. Petersen (martin.petersen@oracle.com) ---
> is it risky to implement the fallback mechanism in both directions? is
> there a chance of forever retry? (fail 6, fail 10, fail 6, fail 10...)

Just a heads-up that I am still working on a reasonable way to go about
this. It is not entirely trivial to perform the transition from MODE
SENSE(6) to (10) given how the SCSI disk driver works.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

--- Comment #9 from Chris Horler (cshorler@googlemail.com) ---
okay, thanks for the update!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215447

--- Comment #10 from Chris Horler (cshorler@googlemail.com) ---
any update on this?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.