All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomas Henzl <thenzl@redhat.com>
To: Don Brace <don.brace@pmcs.com>,
	scott.teel@pmcs.com, Kevin.Barnett@pmcs.com,
	james.bottomley@parallels.com, hch@infradead.org,
	Justin.Lindley@pmcs.com, elliott@hp.com
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 10/11] hpsa: fix issues with multilun devices
Date: Wed, 22 Jul 2015 17:19:55 +0200	[thread overview]
Message-ID: <55AFB49B.1060004@redhat.com> (raw)
In-Reply-To: <20150718161309.31955.77228.stgit@brunhilda>

On 18.7.2015 18:13, Don Brace wrote:
> From: shane.seymour <shane.seymour@hp.com>
> 
> A regression was introduced into the hpsa driver a while back so
> non-zero LUNs of multi-LUN devices may no longer be presented via
> a SAS based Smart Array. I have not done a bisection to discover
> the change that caused it.
> 
> The CISS firmware specification (available on sourceforge)
> defines an 8 byte lunid that describes devices that the Smart
> Array can see/present to the system. The current code in the hpsa
> driver attempts to find matches for non-zero LUNs with LUN 0 for
> a bus/target by zeroing out byte 4 of the lunid and find a match.
> 
> This method is sufficient for SCSI based Smart Arrays because
> byte 5 is always 0. For SAS based Smart arrays byte 5 of the
> lunid contains the path number for a multipath device and
> either one or two bits (the documentation does not define how
> many bits are used but it appears it may be one only) that
> indicate if the given path number in byte 5 must always be
> used to access that device. Byte 5 may not always be zero.
> 
> The following are lunids (spaces added for clarity) for a
> MSL2024 single drive library connected via a H241 Smart Array:
> 
> 00 00 00 00 01 00 00 01 (changer)
> 00 00 00 00 00 80 00 01 (tape)
> 
> In the 4th byte (counting from 0) you can see that the tape
> is LUN 0 and the changer is LUN 1. The 0x80 set in the 5th byte
> for the tape drive means the driver should force access to
> path 0 (the library in this case was connected to one path only
> anyway).
> 
> After the changes we can see the following in the dmesg output:
> 
> scsi 0:3:0:0: RAID              HP       H241             1.18 \
> PQ: 0 ANSI: 5
> scsi 0:2:0:0: Sequential-Access HP       Ultrium 6-SCSI   354W \
> PQ: 0 ANSI: 6
> scsi 0:2:0:1: Medium Changer    HP       MSL G3 Series    8.70 \
> PQ: 0 ANSI: 5
> 
> Showing that the changer is correctly identified as LUN 1 of
> bus 2 target 0. Before the change the changer device is not seen.
> 
> Suggested-by: shane.seymour <shane.seymour@hp.com>
> Reviewed-by: Kevin Barnett <kevin.barnett@pmcs.com>
> Reviewed-by: Scott Teel <scott.teel@pmcs.com>
> Signed-off-by: Don Brace <don.brace@pmcs.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>

Tomas


  reply	other threads:[~2015-07-22 15:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-18 16:12 [PATCH 00/11] hpsa updates Don Brace
2015-07-18 16:12 ` [PATCH 01/11] hpsa: Correct double unlock of mutex Don Brace
2015-07-22 15:16   ` Tomas Henzl
2015-07-18 16:12 ` [PATCH 02/11] hpsa: correct decode sense data Don Brace
2015-07-22 15:16   ` Tomas Henzl
2015-07-18 16:12 ` [PATCH 03/11] hpsa: correct static checker warnings on driver init cleanup Don Brace
2015-07-22 15:16   ` Tomas Henzl
2015-07-18 16:12 ` [PATCH 04/11] hpsa: add PMC to copyright Don Brace
2015-07-18 16:12 ` [PATCH 05/11] hpsa: add sysfs entry path_info to show box and bay information Don Brace
2015-07-22 15:18   ` Tomas Henzl
2015-07-18 16:12 ` [PATCH 06/11] hpsa: cleanup update scsi devices Don Brace
2015-07-22 15:19   ` Tomas Henzl
2015-07-18 16:12 ` [PATCH 07/11] hpsa: add in new controllers Don Brace
2015-07-22 15:19   ` Tomas Henzl
2015-07-18 16:12 ` [PATCH 08/11] Change how controllers in mixed mode are handled Don Brace
2015-07-18 16:13 ` [PATCH 09/11] hpsa: add in new offline mode Don Brace
2015-07-22 15:19   ` Tomas Henzl
2015-07-18 16:13 ` [PATCH 10/11] hpsa: fix issues with multilun devices Don Brace
2015-07-22 15:19   ` Tomas Henzl [this message]
2015-07-18 16:13 ` [PATCH 11/11] hpsa: fix rmmod issues Don Brace
2015-07-22 15:20   ` Tomas Henzl

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=55AFB49B.1060004@redhat.com \
    --to=thenzl@redhat.com \
    --cc=Justin.Lindley@pmcs.com \
    --cc=Kevin.Barnett@pmcs.com \
    --cc=don.brace@pmcs.com \
    --cc=elliott@hp.com \
    --cc=hch@infradead.org \
    --cc=james.bottomley@parallels.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=scott.teel@pmcs.com \
    /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.