linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 215447] sr_mod scsi_mode_sense() failure -> "scsi-1 drive"
Date: Sat, 15 Jan 2022 13:08:54 +0000	[thread overview]
Message-ID: <bug-215447-11613-7nhV0R36aP@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-215447-11613@https.bugzilla.kernel.org/>

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.

  parent reply	other threads:[~2022-01-15 13:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-03 18:00 [Bug 215447] New: sr_mod scsi_mode_sense() failure -> "scsi-1 drive" bugzilla-daemon
2022-01-03 18:03 ` [Bug 215447] " bugzilla-daemon
2022-01-03 18:04 ` bugzilla-daemon
2022-01-03 18:05 ` bugzilla-daemon
2022-01-15 11:42 ` bugzilla-daemon
2022-01-15 12:16   ` Christopher Horler
2022-01-15 13:08     ` Martin K. Petersen
2022-01-15 12:17 ` bugzilla-daemon
2022-01-15 13:08 ` bugzilla-daemon [this message]
2022-01-15 14:04 ` bugzilla-daemon
2022-01-19  4:02   ` Martin K. Petersen
2022-01-19  4:02 ` bugzilla-daemon
2022-01-19 21:20 ` bugzilla-daemon
2022-06-30 17:19 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-215447-11613-7nhV0R36aP@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).