mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: brace77070@gmail.com, Jack Suter <jack@suter.io>
Cc: iss_storagedev@hp.com, esc.storagedev@microsemi.com,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	martin.petersen@oracle.com, scott.teel@microsemi.com,
	kevin.barnett@microsemi.com, thenzl@redhat.com
Subject: Re: "hpsa: Change SAS transport devices to bus 0." commit breaks hpacucli on old controller firmware
Date: Thu, 17 Nov 2016 12:17:29 +0100	[thread overview]
Message-ID: <f6b163ab-29ca-a9f2-6eef-2d6aec03fd02@suse.de> (raw)
In-Reply-To: <0dda89dd-ba20-6fbb-d4dd-1bb6601a4108@gmail.com>

On 11/16/2016 05:09 PM, brace77070@gmail.com wrote:
> On 10/31/2016 02:06 PM, Don Brace wrote:
>> On 10/27/2016 01:15 PM, Jack Suter wrote:
>>> Hi there,
>>>
>>> Commit "hpsa: Change SAS transport devices to bus 0."
>>> (09371d623c9c3dc6ed7f53ec8ab01d25f0c6c697) breaks the hpacucli utility
>>> for some HP Smart Array controllers with old firmware.
>>>
>>> Specifically, I have a P410 connected to an HP DL180 G6 running firmware
>>> version 1.66. Yes, the firmware is old, but it works. On the 4.4 series
>>> kernels and earlier, hpacucli works with no trouble. On 4.5 and later,
>>> the hpsa driver reports errors  in the kernel log, and hpacucli reports
>>> "Error: No controllers detected."
>>>
>>> Oct 27 15:50:30 hostname kernel: [   32.189495] hpsa 0000:06:00.0: scsi
>>> 0:0:0:0: added RAID              HP       P410 controller
>>> SSDSmartPathCap- En- Exp=1
>>> Oct 27 15:50:30 hostname kernel: [   32.190054] hpsa 0000:06:00.0:
>>> addition failed -19, device not added.
>>>
>>> Reverting the above commit resolves both the hpsa errors and the
>>> hpacucli error when tested with kernel 4.7.9.
>>>
>>> In addition to this troublesome server, I have a handful of servers with
>>> P410 controllers and firmware versions ranging from 3.52 to 6.60. All of
>>> them work with the 09371d62 commit in place, which leads me to believe
>>> it is just this old 1.66 firmware that is incompatible.
>>>
>>> While a firmware upgrade seems like the simple solution, I think this
>>> should be considered a bug/regression due to it breaking functionality
>>> that previously worked. It appears others may have run into this issue
>>> too:
>>> http://superuser.com/questions/1093124/coreos-hp410-raid1-device-not-added-19
>>>
>>>
>>> Some dmesg output (grep -e hpsa -e sg) is below from both a 4.4.2 kernel
>>> (working) and 4.5.7 kernel (broken). Note the change in SCSI address
>>> from 0:3:0:0 to 0:0:0:0.
>>>
>>> Please let me know if you need me to do any testing to help resolve
>>> this.
>>>
>>> Jack Suter
>> I discussed this with the ssacli developers and they do not look
>> at the bus, but I see "device not added" messages that
>> should not be there. I'll attack your issue from that
>> perspective.
>>
>> Thanks,
>> Don Brace
> 
> The root cause is that this older firmware is not scsi revision 5 and
> thus we add the
> controller at the end of the list, not at the beginning.
> 
>         if (is_scsi_rev_5(h))
>                 raid_ctlr_position = 0;
>         else
>                 raid_ctlr_position = nphysicals + nlogicals;
> 
> So the first logical volume gets BTL 0:0:0 and then we attempt to add in
> the controller
> using the same BTL values at the end of the list. Thus you get the
> "device not added" messages.
> 
> The change to bus 0 was because the SAS transport is using bus 0 and
> there was a
> discrepancy in what the driver was putting the controller on and what
> the SAS
> transport was actually using.
> 
> I'll work on a patch to resolve this for you.
> 
One can resolve this issue with checking the SCSI revision of the
controller, and move every controller with revision '0' to bus 3.
That solved the issue for me.

Patch posted in a different mail.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

  reply	other threads:[~2016-11-17 11:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-27 18:15 Jack Suter
2016-10-31 19:06 ` Don Brace
2016-11-16 16:09   ` brace77070
2016-11-17 11:17     ` Hannes Reinecke [this message]
2016-11-17 20:22       ` Jack Suter
     [not found]         ` <4993A297653ECB4581FA5C3C31323D193B0BC887@avsrvexchmbx1.microsemi.net>
2016-11-17 21:37           ` Jack Suter

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=f6b163ab-29ca-a9f2-6eef-2d6aec03fd02@suse.de \
    --to=hare@suse.de \
    --cc=brace77070@gmail.com \
    --cc=esc.storagedev@microsemi.com \
    --cc=iss_storagedev@hp.com \
    --cc=jack@suter.io \
    --cc=kevin.barnett@microsemi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=scott.teel@microsemi.com \
    --cc=thenzl@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®