[PATCH 0/10] megaraid_sas: Updates for scsi-misc

[PATCH 0/10] megaraid_sas: Updates for scsi-misc

[adam radford]

James/Linux-scsi,

The following patch series for megaraid_sas brings the driver up to v6.12-rc1:

1. Continue booting immediately if FW in FAULT at driver load time.
2. Increase default cmds per lun to 256.
3. Fix mismatch in megasas_reset_fusion() mutex lock-unlock.
4. Remove some un-necessary code.
5. Clear state change interrupts for Fusion/Invader.
6. Clear FUSION_IN_RESET before enabling interrupts.
7. Add support for MegaRAID 9360/9380 12GB/s controllers.
8. Add multiple MSI-X vector/multiple reply queue support.
9. Add driver workaround for PERC5/1068 kdump kernel panic.
10. Version and Changelog update.

-Adam

Re: [PATCH 0/10] megaraid_sas: Updates for scsi-misc

[Douglas Gilbert]

On 11-10-08 09:14 PM, adam radford wrote:
> James/Linux-scsi,
>
> The following patch series for megaraid_sas brings the driver up to v6.12-rc1:
>
> 1. Continue booting immediately if FW in FAULT at driver load time.
> 2. Increase default cmds per lun to 256.
> 3. Fix mismatch in megasas_reset_fusion() mutex lock-unlock.
> 4. Remove some un-necessary code.
> 5. Clear state change interrupts for Fusion/Invader.
> 6. Clear FUSION_IN_RESET before enabling interrupts.
> 7. Add support for MegaRAID 9360/9380 12GB/s controllers.
> 8. Add multiple MSI-X vector/multiple reply queue support.
> 9. Add driver workaround for PERC5/1068 kdump kernel panic.
> 10. Version and Changelog update.

I haven't checked all SAS HBAs in Linux but of those that I
have checked only one doesn't support the SMP pass-through
in the bsg driver. And that HBA driver is megaraid_sas **.

The SMP pass-through allows user space programs to monitor
and change advanced features in SAS expanders such as
zoning. SMP (Serial Management Protocol) is one of the three
SAS transport protocols defined by t10.org (the other two are
SSP and STP). All SAS HBAs, including MegaRaid SAS HBAs,
support SMP "under the covers" otherwise they would not be
able to discover disks connected via SAS expanders.

Doug Gilbert


** I'm not aware of any proprietary SMP pass-through interface
    accessible in Linux for megaraid_sas either

Re: [PATCH 0/10] megaraid_sas: Updates for scsi-misc

[James Bottomley]

On Sun, 2011-10-09 at 09:56 -0400, Douglas Gilbert wrote:
> On 11-10-08 09:14 PM, adam radford wrote:
> > James/Linux-scsi,
> >
> > The following patch series for megaraid_sas brings the driver up to v6.12-rc1:
> >
> > 1. Continue booting immediately if FW in FAULT at driver load time.
> > 2. Increase default cmds per lun to 256.
> > 3. Fix mismatch in megasas_reset_fusion() mutex lock-unlock.
> > 4. Remove some un-necessary code.
> > 5. Clear state change interrupts for Fusion/Invader.
> > 6. Clear FUSION_IN_RESET before enabling interrupts.
> > 7. Add support for MegaRAID 9360/9380 12GB/s controllers.
> > 8. Add multiple MSI-X vector/multiple reply queue support.
> > 9. Add driver workaround for PERC5/1068 kdump kernel panic.
> > 10. Version and Changelog update.
> 
> I haven't checked all SAS HBAs in Linux but of those that I
> have checked only one doesn't support the SMP pass-through
> in the bsg driver. And that HBA driver is megaraid_sas **.

Technically the megaraid_sas isn't really a SAS HBA, it's a RAID one
that just happens to have SAS/SATA disk attachments.  None of the RAID
HBA's (including the IBM power raid) expose a BSG interface or even
attach properly to the in-kernel SAS interfaces.

James

Re: [PATCH 0/10] megaraid_sas: Updates for scsi-misc

[Douglas Gilbert]

On 11-10-09 10:10 AM, James Bottomley wrote:
> On Sun, 2011-10-09 at 09:56 -0400, Douglas Gilbert wrote:
>> On 11-10-08 09:14 PM, adam radford wrote:
>>> James/Linux-scsi,
>>>
>>> The following patch series for megaraid_sas brings the driver up to v6.12-rc1:
>>>
>>> 1. Continue booting immediately if FW in FAULT at driver load time.
>>> 2. Increase default cmds per lun to 256.
>>> 3. Fix mismatch in megasas_reset_fusion() mutex lock-unlock.
>>> 4. Remove some un-necessary code.
>>> 5. Clear state change interrupts for Fusion/Invader.
>>> 6. Clear FUSION_IN_RESET before enabling interrupts.
>>> 7. Add support for MegaRAID 9360/9380 12GB/s controllers.
>>> 8. Add multiple MSI-X vector/multiple reply queue support.
>>> 9. Add driver workaround for PERC5/1068 kdump kernel panic.
>>> 10. Version and Changelog update.
>>
>> I haven't checked all SAS HBAs in Linux but of those that I
>> have checked only one doesn't support the SMP pass-through
>> in the bsg driver. And that HBA driver is megaraid_sas **.
>
> Technically the megaraid_sas isn't really a SAS HBA, it's a RAID one
> that just happens to have SAS/SATA disk attachments.  None of the RAID
> HBA's (including the IBM power raid) expose a BSG interface or even
> attach properly to the in-kernel SAS interfaces.

In JBOD mode MegaRaid SAS controllers are SAS HBAs
(marketing BS aside). Their firmware has the same
SMP pass-through as LSI's MPT SAS Fusion controllers.

There is no reason why a MegaRaid controller user
couldn't place a SAS-2 expander in front of an array
of disks and make some disks available to a MegaRaid
volume. Other array disks could be used by other
machines and the different sets could be isolated
from each other with SAS-2 zoning. The problem then
would be that via a MegaRaid SAS controller a user
could not monitor or control that zoning. Seems a
bit wasteful to add a "real" SAS HBA just to get
that capability.

Many SAS HBAs (including MPT SAS Fusion controllers)
do RAID 0 and 1 (and 10?) so they could be viewed as
"RAID" controllers that expose a BSG interface.

Doug Gilbert

Re: [PATCH 0/10] megaraid_sas: Updates for scsi-misc

[Hannes Reinecke]

On 10/10/2011 02:56 AM, Douglas Gilbert wrote:
> On 11-10-09 10:10 AM, James Bottomley wrote:
>> On Sun, 2011-10-09 at 09:56 -0400, Douglas Gilbert wrote:
>>> On 11-10-08 09:14 PM, adam radford wrote:
>>>> James/Linux-scsi,
>>>>
>>>> The following patch series for megaraid_sas brings the driver up
>>>> to v6.12-rc1:
>>>>
>>>> 1. Continue booting immediately if FW in FAULT at driver load time.
>>>> 2. Increase default cmds per lun to 256.
>>>> 3. Fix mismatch in megasas_reset_fusion() mutex lock-unlock.
>>>> 4. Remove some un-necessary code.
>>>> 5. Clear state change interrupts for Fusion/Invader.
>>>> 6. Clear FUSION_IN_RESET before enabling interrupts.
>>>> 7. Add support for MegaRAID 9360/9380 12GB/s controllers.
>>>> 8. Add multiple MSI-X vector/multiple reply queue support.
>>>> 9. Add driver workaround for PERC5/1068 kdump kernel panic.
>>>> 10. Version and Changelog update.
>>>
>>> I haven't checked all SAS HBAs in Linux but of those that I
>>> have checked only one doesn't support the SMP pass-through
>>> in the bsg driver. And that HBA driver is megaraid_sas **.
>>
>> Technically the megaraid_sas isn't really a SAS HBA, it's a RAID one
>> that just happens to have SAS/SATA disk attachments. None of the RAID
>> HBA's (including the IBM power raid) expose a BSG interface or even
>> attach properly to the in-kernel SAS interfaces.
>
> In JBOD mode MegaRaid SAS controllers are SAS HBAs
> (marketing BS aside). Their firmware has the same
> SMP pass-through as LSI's MPT SAS Fusion controllers.
>
> There is no reason why a MegaRaid controller user
> couldn't place a SAS-2 expander in front of an array
> of disks and make some disks available to a MegaRaid
> volume. Other array disks could be used by other
> machines and the different sets could be isolated
> from each other with SAS-2 zoning. The problem then
> would be that via a MegaRaid SAS controller a user
> could not monitor or control that zoning. Seems a
> bit wasteful to add a "real" SAS HBA just to get
> that capability.
>
Yes, true. But that's the megaraid SAS design.
It's actually the same with every other RAID controller.
Everyone (well, every reasonably recent one) supports SAS, but
virtually no-one exposes them as such.

Problem here is that the RAID controller have invented
their own command set to talk to the RAID firmware.
Most RAID firmware have support for SCSI passthrough
commands (that's how we managed to get rid of cciss :-)
but virtually none of those have support for transport-specific
passthrough commands.

So yes, they are using the same SAS cores as 'normal'
SAS HBAs do. But no, there is no way how you could get
through to them. Or, at least, no documented one.

Would be cool to have them, but you could _severely_ screw up 
operations by using them.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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

Re: [PATCH 0/10] megaraid_sas: Updates for scsi-misc

[Hannes Reinecke]

On 10/10/2011 09:02 AM, Hannes Reinecke wrote:
> On 10/10/2011 02:56 AM, Douglas Gilbert wrote:
>> On 11-10-09 10:10 AM, James Bottomley wrote:
>>> On Sun, 2011-10-09 at 09:56 -0400, Douglas Gilbert wrote:
>>>> On 11-10-08 09:14 PM, adam radford wrote:
>>>>> James/Linux-scsi,
>>>>>
>>>>> The following patch series for megaraid_sas brings the driver up
>>>>> to v6.12-rc1:
>>>>>
>>>>> 1. Continue booting immediately if FW in FAULT at driver load
>>>>> time.
>>>>> 2. Increase default cmds per lun to 256.
>>>>> 3. Fix mismatch in megasas_reset_fusion() mutex lock-unlock.
>>>>> 4. Remove some un-necessary code.
>>>>> 5. Clear state change interrupts for Fusion/Invader.
>>>>> 6. Clear FUSION_IN_RESET before enabling interrupts.
>>>>> 7. Add support for MegaRAID 9360/9380 12GB/s controllers.
>>>>> 8. Add multiple MSI-X vector/multiple reply queue support.
>>>>> 9. Add driver workaround for PERC5/1068 kdump kernel panic.
>>>>> 10. Version and Changelog update.
>>>>
>>>> I haven't checked all SAS HBAs in Linux but of those that I
>>>> have checked only one doesn't support the SMP pass-through
>>>> in the bsg driver. And that HBA driver is megaraid_sas **.
>>>
>>> Technically the megaraid_sas isn't really a SAS HBA, it's a RAID one
>>> that just happens to have SAS/SATA disk attachments. None of the
>>> RAID
>>> HBA's (including the IBM power raid) expose a BSG interface or even
>>> attach properly to the in-kernel SAS interfaces.
>>
>> In JBOD mode MegaRaid SAS controllers are SAS HBAs
>> (marketing BS aside). Their firmware has the same
>> SMP pass-through as LSI's MPT SAS Fusion controllers.
>>
>> There is no reason why a MegaRaid controller user
>> couldn't place a SAS-2 expander in front of an array
>> of disks and make some disks available to a MegaRaid
>> volume. Other array disks could be used by other
>> machines and the different sets could be isolated
>> from each other with SAS-2 zoning. The problem then
>> would be that via a MegaRaid SAS controller a user
>> could not monitor or control that zoning. Seems a
>> bit wasteful to add a "real" SAS HBA just to get
>> that capability.
>>
> Yes, true. But that's the megaraid SAS design.
> It's actually the same with every other RAID controller.
> Everyone (well, every reasonably recent one) supports SAS, but
> virtually no-one exposes them as such.
>
> Problem here is that the RAID controller have invented
> their own command set to talk to the RAID firmware.
> Most RAID firmware have support for SCSI passthrough
> commands (that's how we managed to get rid of cciss :-)
> but virtually none of those have support for transport-specific
> passthrough commands.
>
Correction: megaraid_sas has.

It's got two command definitions:

#define MFI_CMD_SMP 0x7
#define MFI_CMD_STP 0x8

Which indeed look like they could've been used to implement the 
respective bsg interface.

Hmm.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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

Re: [PATCH 0/10] megaraid_sas: Updates for scsi-misc

[James Bottomley]

On Sun, 2011-10-09 at 20:56 -0400, Douglas Gilbert wrote:
> On 11-10-09 10:10 AM, James Bottomley wrote:
> > On Sun, 2011-10-09 at 09:56 -0400, Douglas Gilbert wrote:
> >> On 11-10-08 09:14 PM, adam radford wrote:
> >>> James/Linux-scsi,
> >>>
> >>> The following patch series for megaraid_sas brings the driver up to v6.12-rc1:
> >>>
> >>> 1. Continue booting immediately if FW in FAULT at driver load time.
> >>> 2. Increase default cmds per lun to 256.
> >>> 3. Fix mismatch in megasas_reset_fusion() mutex lock-unlock.
> >>> 4. Remove some un-necessary code.
> >>> 5. Clear state change interrupts for Fusion/Invader.
> >>> 6. Clear FUSION_IN_RESET before enabling interrupts.
> >>> 7. Add support for MegaRAID 9360/9380 12GB/s controllers.
> >>> 8. Add multiple MSI-X vector/multiple reply queue support.
> >>> 9. Add driver workaround for PERC5/1068 kdump kernel panic.
> >>> 10. Version and Changelog update.
> >>
> >> I haven't checked all SAS HBAs in Linux but of those that I
> >> have checked only one doesn't support the SMP pass-through
> >> in the bsg driver. And that HBA driver is megaraid_sas **.
> >
> > Technically the megaraid_sas isn't really a SAS HBA, it's a RAID one
> > that just happens to have SAS/SATA disk attachments.  None of the RAID
> > HBA's (including the IBM power raid) expose a BSG interface or even
> > attach properly to the in-kernel SAS interfaces.
> 
> In JBOD mode MegaRaid SAS controllers are SAS HBAs
> (marketing BS aside). Their firmware has the same
> SMP pass-through as LSI's MPT SAS Fusion controllers.
> 
> There is no reason why a MegaRaid controller user
> couldn't place a SAS-2 expander in front of an array
> of disks and make some disks available to a MegaRaid
> volume. Other array disks could be used by other
> machines and the different sets could be isolated
> from each other with SAS-2 zoning. The problem then
> would be that via a MegaRaid SAS controller a user
> could not monitor or control that zoning. Seems a
> bit wasteful to add a "real" SAS HBA just to get
> that capability.

I agree: ipr is used in precisely this way.  It even uses libata for
SATA devices but doesn't attach to the libsas transport class which
means it's dragging us for moving to the new_eh in libata.

The problem in the IPR case (and I assume the megaraid case) is that it
takes extra work to get the attachment which no-one seems willing to do.

> Many SAS HBAs (including MPT SAS Fusion controllers)
> do RAID 0 and 1 (and 10?) so they could be viewed as
> "RAID" controllers that expose a BSG interface.

fusion is more a SCSI controller with RAID wedged into a spare piece in
the firmware ... it wasn't really designed as a RAID controller.

James