From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomas Henzl Subject: Re: [PATCH 10/11] hpsa: fix issues with multilun devices Date: Wed, 22 Jul 2015 17:19:55 +0200 Message-ID: <55AFB49B.1060004@redhat.com> References: <20150718160245.31955.16794.stgit@brunhilda> <20150718161309.31955.77228.stgit@brunhilda> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45786 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934322AbbGVPT6 (ORCPT ); Wed, 22 Jul 2015 11:19:58 -0400 In-Reply-To: <20150718161309.31955.77228.stgit@brunhilda> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Don Brace , 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 On 18.7.2015 18:13, Don Brace wrote: > From: shane.seymour > > 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 > Reviewed-by: Kevin Barnett > Reviewed-by: Scott Teel > Signed-off-by: Don Brace Reviewed-by: Tomas Henzl Tomas