All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
	James.Bottomley@SteelEye.com
Cc: linux-scsi@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net, jgarzik@pobox.com
Subject: Re: TYPE_RBC cache fixes (sbp2.c affected)
Date: Sun, 22 May 2005 16:31:26 +1000	[thread overview]
Message-ID: <4290273E.6050306@torque.net> (raw)
In-Reply-To: <20050516015955.GL1150@parcelfarce.linux.theplanet.co.uk>

Al + James,
Some comments about the original patch:

<snip>
> diff -urN RC12-rc4-base/drivers/scsi/sd.c RC12-rc4-rbc/drivers/scsi/sd.c
> --- RC12-rc4-base/drivers/scsi/sd.c	2005-05-07 04:05:00.000000000 -0400
> +++ RC12-rc4-rbc/drivers/scsi/sd.c	2005-05-15 12:30:38.769387199 -0400
> @@ -1368,17 +1368,26 @@
>   */
>  static void
>  sd_read_cache_type(struct scsi_disk *sdkp, char *diskname,
> -		   struct scsi_request *SRpnt, unsigned char *buffer) {
> +		   struct scsi_request *SRpnt, unsigned char *buffer)
> +{
>  	int len = 0, res;
>  
> -	const int dbd = 0;	   /* DBD */
> -	const int modepage = 0x08; /* current values, cache page */
> +	int dbd;
> +	int modepage;
>  	struct scsi_mode_data data;
>  	struct scsi_sense_hdr sshdr;
>  
>  	if (sdkp->device->skip_ms_page_8)
>  		goto defaults;
>  
> +	if (sdkp->device->type == TYPE_RBC) {
> +		modepage = 6;
> +		dbd = 8;

Al,
In my experience setting the DBD flag only increases the
chance of failure (from devices that don't understand the
DBD (i.e. disable block descriptors) bit. Also dbd should
be set (to 1) or cleared; not set to 8. Best to leave it clear
(the default) as the offset calculation below takes into
account any returned block descriptors.

James,
scsi_lib.c::__scsi_mode_sense() has a bug in it.
If dbd is set then both the DBD and LLBA bits in the
MODE SENSE cdb are set. However LLBA is not defined for
MODE SENSE 6 (in SPC or RBC). That may be why Al's
hardware doesn't like MODE SENSE 6 cdbs issued by the
SCSI mid level :-)

> +	} else {
> +		modepage = 8;
> +		dbd = 0;
> +	}
> +
>  	/* cautiously ask */
>  	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, 4, &data);
>  
> @@ -1409,11 +1418,20 @@
>  			"write back, no read (daft)"
>  		};
>  		int ct = 0;
> -		int offset = data.header_length +
> -			data.block_descriptor_length + 2;
> +		int offset = data.header_length + data.block_descriptor_length;
>  
> -		sdkp->WCE = ((buffer[offset] & 0x04) != 0);
> -		sdkp->RCD = ((buffer[offset] & 0x01) != 0);
> +		if ((buffer[offset] & 0x3f) != modepage) {
> +			printk(KERN_ERR "%s: got wrong page\n", diskname);
> +			goto defaults;
> +		}

So here is the sanity check that I have been talking
about. On my hardware since a MODE SENSE 10 was issued,
the response is corrupt (actually the response for the
corresponding MODE SENSE 6 is returned) so the exercise
becomes futile. Note that my hardware complies with
the RBC standard in properly supporting MODE SENSE 6.
[The RBC standard doesn't say anything about what should
happen when MODE SENSE 10 is issued :-)]

To work on my hardware the next move would be to
"sdev->use_10_for_ms = 0;" and try again (and if
that fails give up).

<snip>

Doug Gilbert

  parent reply	other threads:[~2005-05-22  6:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-16  1:59 TYPE_RBC cache fixes (sbp2.c affected) Al Viro
2005-05-16  3:26 ` Douglas Gilbert
2005-05-16  4:18   ` Al Viro
2005-05-21  5:03 ` Douglas Gilbert
2005-05-21 15:01 ` James Bottomley
2005-05-21 15:38   ` Jeff Garzik
2005-05-21 16:00     ` James Bottomley
2005-05-21 16:22       ` Al Viro
2005-05-21 18:12         ` James Bottomley
2005-05-21 22:06           ` Douglas Gilbert
2005-05-22  5:08             ` Douglas Gilbert
2005-05-21 15:24 ` James Bottomley
2005-05-22 10:15   ` Douglas Gilbert
2005-05-22  6:31 ` Douglas Gilbert [this message]
2005-05-22 14:06   ` James Bottomley
2005-05-23 15:14     ` Douglas Gilbert
2006-02-08 23:39 ` Stefan Richter
2006-02-08 23:54   ` Al Viro
2006-02-11  9:50     ` Stefan Richter
2006-02-11 13:05       ` Al Viro
2006-02-13 20:40       ` Stefan Richter
2006-02-20  6:08       ` Al Viro
2006-02-21 19:56         ` Stefan Richter
2006-02-21 21:51           ` Al Viro
2006-02-21 22:41             ` Stefan Richter
2006-02-22  7:08             ` Stefan Richter
2006-02-22  7:16               ` Al Viro
2006-02-22  7:35                 ` Stefan Richter

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=4290273E.6050306@torque.net \
    --to=dougg@torque.net \
    --cc=James.Bottomley@SteelEye.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.