From patchwork Tue Jul 7 08:43:51 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Seymour, Shane M" X-Patchwork-Id: 6731231 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 7B82D9F38C for ; Tue, 7 Jul 2015 08:44:58 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9B3AC204FF for ; Tue, 7 Jul 2015 08:44:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 73171204D6 for ; Tue, 7 Jul 2015 08:44:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756426AbbGGIoy (ORCPT ); Tue, 7 Jul 2015 04:44:54 -0400 Received: from g4t3425.houston.hp.com ([15.201.208.53]:26457 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756742AbbGGIor convert rfc822-to-8bit (ORCPT ); Tue, 7 Jul 2015 04:44:47 -0400 Received: from G4W6310.americas.hpqcorp.net (g4w6310.houston.hp.com [16.210.26.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t3425.houston.hp.com (Postfix) with ESMTPS id 43EB86E; Tue, 7 Jul 2015 08:44:44 +0000 (UTC) Received: from G9W3614.americas.hpqcorp.net (16.216.186.49) by G4W6310.americas.hpqcorp.net (16.210.26.217) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 7 Jul 2015 08:43:52 +0000 Received: from G9W0766.americas.hpqcorp.net ([169.254.4.103]) by G9W3614.americas.hpqcorp.net ([16.216.186.49]) with mapi id 14.03.0169.001; Tue, 7 Jul 2015 08:43:51 +0000 From: "Seymour, Shane M" To: "linux-scsi@vger.kernel.org" , "don.brace@pmcs.com" CC: "James Bottomley (JBottomley@Odin.com)" , "storagedev@pmcs.com" , ISS StorageDev Subject: [PATCH] hpsa: non-zero LUNs of multi-LUN devices missing on some Smart Arrays Thread-Topic: [PATCH] hpsa: non-zero LUNs of multi-LUN devices missing on some Smart Arrays Thread-Index: AdC4iclMs17BwUHtR6yaOL8Rn9T18g== Date: Tue, 7 Jul 2015 08:43:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.210.48.19] MIME-Version: 1.0 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. Signed-off-by: Shane Seymour --- Testing was done on RHEL 6.5 with hpsa driver version 3.4.10-120 and the below patch is the forward ported upstream patch since the issue exists there as well. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/drivers/scsi/hpsa.c 2015-07-06 19:48:22.224804233 -0500 +++ b/drivers/scsi/hpsa.c 2015-07-06 21:16:31.496444001 -0500 @@ -1083,17 +1083,19 @@ static int hpsa_scsi_add_entry(struct ct /* This is a non-zero lun of a multi-lun device. * Search through our list and find the device which - * has the same 8 byte LUN address, excepting byte 4. + * has the same 8 byte LUN address, excepting byte 4 and 5. * Assign the same bus and target for this new LUN. * Use the logical unit number from the firmware. */ memcpy(addr1, device->scsi3addr, 8); addr1[4] = 0; + addr1[5] = 0; for (i = 0; i < n; i++) { sd = h->dev[i]; memcpy(addr2, sd->scsi3addr, 8); addr2[4] = 0; - /* differ only in byte 4? */ + addr2[5] = 0; + /* differ only in byte 4 and 5? */ if (memcmp(addr1, addr2, 8) == 0) { device->bus = sd->bus; device->target = sd->target;