diff mbox

mpt2sas: Fall back to 64 bit coherent mask if 64 bit DMA / 32 bit coherent mask not supported

Message ID 55528BBB.3000809@linux.vnet.ibm.com (mailing list archive)
State New, archived
Headers show

Commit Message

Brian King May 12, 2015, 11:24 p.m. UTC 
On 05/12/2015 05:10 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2015-05-12 at 17:07 -0500, Brian King wrote:
>> The mpt2sas driver was changed late last year in that it now requests a 64 bit DMA
>> mask, then requests a 32 bit coherent DMA mask, then later requests a 64 bit coherent
>> DMA mask. This was 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c. This breaks 64 bit DMA
>> support for mpt2sas on Power and we always fall back to using 32 bit DMA. Looking
>> at the commit log, it looks like this was an intentional change.
>>
>> Ben - you had a patch set you had posted to the list back in Feb of this year, but it
>> doesn't look like it got merged. 
> 
> Right, it was broken, we can't do that unfortunately. It's a hard
> problem to fix.
> 
>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-February/125087.html
>>
>> This would fix the issue I'm seeing on mpt2sas. Do you plan to dust that patch set
>> off and upstream it? Were there issues with it that still need to be resolved?
> 
> No that patch doesn't actually work.
> 
> What we need is essentially a new set of DMA ops that can route an
> individual map request via the iommu or the bypass window depending on
> what mask applies.

Ok. For the interim, then, Sreekanth, would you consider a patch such as the one
below to allow mpt2sas to support 64 bit DMA on architectures that don't support
a 32 bit coherent mask and a 64 bit dma mask at the same time? Only compile tested
at this point. Will run it on a Power machine shortly to confirm it doesn't
break anything...

Comments

Arnd Bergmann May 13, 2015, 8:10 a.m. UTC | #1 
On Tuesday 12 May 2015 18:24:43 Brian King wrote:
> 
> Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for mpt2sas on Power.
> That commit changed the sequence for setting up the DMA and coherent DMA masks so
> that during initialization the driver requests a 64 bit DMA mask and a 32 bit consistent
> DMA mask, then later requests a 64 bit consistent DMA mask. The Power architecture does
> not currently support this, which results in always falling back to a 32 bit DMA window,
> which has a negative impact on performance. Tweak this algorithm slightly so that
> if requesting a 32 bit consistent mask fails after we've successfully set a 64 bit
> DMA mask, just try to get a 64 bit consistent mask. This should preserve existing
> behavior on platforms that support mixed mask setting and restore previous functionality
> to those that do not.
> 
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>

I believe the way the API is designed, it should guarantee that after dma_set_mask()
succeeds for a device, dma_set_coherent_mask() with the same mask will also succeed.

Could you just call dma_set_mask_and_coherent() here to avoid that complex logic?

	Arnd
--
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
Brian King May 13, 2015, 1:23 p.m. UTC | #2 
On 05/13/2015 03:10 AM, Arnd Bergmann wrote:
> On Tuesday 12 May 2015 18:24:43 Brian King wrote:
>>
>> Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for mpt2sas on Power.
>> That commit changed the sequence for setting up the DMA and coherent DMA masks so
>> that during initialization the driver requests a 64 bit DMA mask and a 32 bit consistent
>> DMA mask, then later requests a 64 bit consistent DMA mask. The Power architecture does
>> not currently support this, which results in always falling back to a 32 bit DMA window,
>> which has a negative impact on performance. Tweak this algorithm slightly so that
>> if requesting a 32 bit consistent mask fails after we've successfully set a 64 bit
>> DMA mask, just try to get a 64 bit consistent mask. This should preserve existing
>> behavior on platforms that support mixed mask setting and restore previous functionality
>> to those that do not.
>>
>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> 
> I believe the way the API is designed, it should guarantee that after dma_set_mask()
> succeeds for a device, dma_set_coherent_mask() with the same mask will also succeed.
> 
> Could you just call dma_set_mask_and_coherent() here to avoid that complex logic?

I don't think that would work. The mpt2sas driver wants to set the dma mask to 64bits
but set the coherent mask to 32 bits, then my change is to set the coherent mask to
64bits if setting it to 32bit fails. I'm not seeing how using dma_set_mask_and_coherent
would simplify anything here.

Thanks,

Brian
Arnd Bergmann May 13, 2015, 1:31 p.m. UTC | #3 
On Wednesday 13 May 2015 08:23:41 Brian King wrote:
> On 05/13/2015 03:10 AM, Arnd Bergmann wrote:
> > On Tuesday 12 May 2015 18:24:43 Brian King wrote:
> >>
> >> Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for mpt2sas on Power.
> >> That commit changed the sequence for setting up the DMA and coherent DMA masks so
> >> that during initialization the driver requests a 64 bit DMA mask and a 32 bit consistent
> >> DMA mask, then later requests a 64 bit consistent DMA mask. The Power architecture does
> >> not currently support this, which results in always falling back to a 32 bit DMA window,
> >> which has a negative impact on performance. Tweak this algorithm slightly so that
> >> if requesting a 32 bit consistent mask fails after we've successfully set a 64 bit
> >> DMA mask, just try to get a 64 bit consistent mask. This should preserve existing
> >> behavior on platforms that support mixed mask setting and restore previous functionality
> >> to those that do not.
> >>
> >> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> > 
> > I believe the way the API is designed, it should guarantee that after dma_set_mask()
> > succeeds for a device, dma_set_coherent_mask() with the same mask will also succeed.
> > 
> > Could you just call dma_set_mask_and_coherent() here to avoid that complex logic?
> 
> I don't think that would work. The mpt2sas driver wants to set the dma mask to 64bits
> but set the coherent mask to 32 bits, then my change is to set the coherent mask to
> 64bits if setting it to 32bit fails. I'm not seeing how using dma_set_mask_and_coherent
> would simplify anything here.

My question was more about why the driver would ask for a 32-bit coherent
mask to start with. Is this a limitation in the mpt2sas device that can
only have descriptors at low addresses, or is it trying to work around some
bug in a particular host system?

	Arnd
--
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
James Bottomley May 13, 2015, 1:59 p.m. UTC | #4 
On Wed, 2015-05-13 at 15:31 +0200, Arnd Bergmann wrote:
> On Wednesday 13 May 2015 08:23:41 Brian King wrote:
> > On 05/13/2015 03:10 AM, Arnd Bergmann wrote:
> > > On Tuesday 12 May 2015 18:24:43 Brian King wrote:
> > >>
> > >> Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for mpt2sas on Power.
> > >> That commit changed the sequence for setting up the DMA and coherent DMA masks so
> > >> that during initialization the driver requests a 64 bit DMA mask and a 32 bit consistent
> > >> DMA mask, then later requests a 64 bit consistent DMA mask. The Power architecture does
> > >> not currently support this, which results in always falling back to a 32 bit DMA window,
> > >> which has a negative impact on performance. Tweak this algorithm slightly so that
> > >> if requesting a 32 bit consistent mask fails after we've successfully set a 64 bit
> > >> DMA mask, just try to get a 64 bit consistent mask. This should preserve existing
> > >> behavior on platforms that support mixed mask setting and restore previous functionality
> > >> to those that do not.
> > >>
> > >> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> > > 
> > > I believe the way the API is designed, it should guarantee that after dma_set_mask()
> > > succeeds for a device, dma_set_coherent_mask() with the same mask will also succeed.
> > > 
> > > Could you just call dma_set_mask_and_coherent() here to avoid that complex logic?
> > 
> > I don't think that would work. The mpt2sas driver wants to set the dma mask to 64bits
> > but set the coherent mask to 32 bits, then my change is to set the coherent mask to
> > 64bits if setting it to 32bit fails. I'm not seeing how using dma_set_mask_and_coherent
> > would simplify anything here.
> 
> My question was more about why the driver would ask for a 32-bit coherent
> mask to start with. Is this a limitation in the mpt2sas device that can
> only have descriptors at low addresses, or is it trying to work around some
> bug in a particular host system?

Can't speak for mp2sas, but it's a standard pattern for a lot of script
based (internal microcode) devices.  The microcode often gets extended
for external 64 bit addressing just by adding extra descriptor types, so
the device itself can do DMA to/from the full 64 bit range.  However,
the actual bit width of the microcode processor is usually left at 32
bits.  This means that if microcode scripts are executed out of system
memory, they have to be located in the lower 32 bits of physical memory
otherwise the internal microcode pointer references wrap (the aic79xx
has exactly this problem).  Hence they need a 64 bit mask but a 32 bit
coherent mask (coherent memory is where the scripts are located).

James


--
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
Brian King May 13, 2015, 2:12 p.m. UTC | #5 
On 05/13/2015 08:31 AM, Arnd Bergmann wrote:
> On Wednesday 13 May 2015 08:23:41 Brian King wrote:
>> On 05/13/2015 03:10 AM, Arnd Bergmann wrote:
>>> On Tuesday 12 May 2015 18:24:43 Brian King wrote:
>>>>
>>>> Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for mpt2sas on Power.
>>>> That commit changed the sequence for setting up the DMA and coherent DMA masks so
>>>> that during initialization the driver requests a 64 bit DMA mask and a 32 bit consistent
>>>> DMA mask, then later requests a 64 bit consistent DMA mask. The Power architecture does
>>>> not currently support this, which results in always falling back to a 32 bit DMA window,
>>>> which has a negative impact on performance. Tweak this algorithm slightly so that
>>>> if requesting a 32 bit consistent mask fails after we've successfully set a 64 bit
>>>> DMA mask, just try to get a 64 bit consistent mask. This should preserve existing
>>>> behavior on platforms that support mixed mask setting and restore previous functionality
>>>> to those that do not.
>>>>
>>>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
>>>
>>> I believe the way the API is designed, it should guarantee that after dma_set_mask()
>>> succeeds for a device, dma_set_coherent_mask() with the same mask will also succeed.
>>>
>>> Could you just call dma_set_mask_and_coherent() here to avoid that complex logic?
>>
>> I don't think that would work. The mpt2sas driver wants to set the dma mask to 64bits
>> but set the coherent mask to 32 bits, then my change is to set the coherent mask to
>> 64bits if setting it to 32bit fails. I'm not seeing how using dma_set_mask_and_coherent
>> would simplify anything here.
> 
> My question was more about why the driver would ask for a 32-bit coherent
> mask to start with. Is this a limitation in the mpt2sas device that can
> only have descriptors at low addresses, or is it trying to work around some
> bug in a particular host system?

I'll need help from Sreekanth in answering that. All that is in the git commit log is:

    2. Initially set the consistent DMA mask to 32 bit and then change it to 64 bit mask
    after allocating RDPQ pools by calling the function _base_change_consistent_dma_mask.
    This is to ensure that all the upper 32 bits of RDPQ entries's base address to be same.

So, I'm not sure my patch won't break something with mpt2sas... This commit also changed
how the RDPO pools are allocated, so its possible this won't work. However, I did load
it on Power box and I'm not seeing any major problems so far. I am seeing the following message
get logged on a regular basis, not sure if its related to this change or not:

mpt2sas3: log_info(0x31120303): originator(IOP), code(0x03), sub_code(0x3112)

-Brian
Sreekanth Reddy May 13, 2015, 4:44 p.m. UTC | #6 
Hi Brain,

We had a restriction from the firmware that the upper 32 bits of the
RDPQ pool entries must be same. So to limit this restriction we
initially set the consistent DMA mask to 32 and then after allocating
the RDPQ pools we changed the consistent DMA mask to 64 before
allocating remaining pools.

Regards,
Sreekanth

On Wed, May 13, 2015 at 7:42 PM, Brian King <brking@linux.vnet.ibm.com> wrote:
> On 05/13/2015 08:31 AM, Arnd Bergmann wrote:
>> On Wednesday 13 May 2015 08:23:41 Brian King wrote:
>>> On 05/13/2015 03:10 AM, Arnd Bergmann wrote:
>>>> On Tuesday 12 May 2015 18:24:43 Brian King wrote:
>>>>>
>>>>> Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for mpt2sas on Power.
>>>>> That commit changed the sequence for setting up the DMA and coherent DMA masks so
>>>>> that during initialization the driver requests a 64 bit DMA mask and a 32 bit consistent
>>>>> DMA mask, then later requests a 64 bit consistent DMA mask. The Power architecture does
>>>>> not currently support this, which results in always falling back to a 32 bit DMA window,
>>>>> which has a negative impact on performance. Tweak this algorithm slightly so that
>>>>> if requesting a 32 bit consistent mask fails after we've successfully set a 64 bit
>>>>> DMA mask, just try to get a 64 bit consistent mask. This should preserve existing
>>>>> behavior on platforms that support mixed mask setting and restore previous functionality
>>>>> to those that do not.
>>>>>
>>>>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
>>>>
>>>> I believe the way the API is designed, it should guarantee that after dma_set_mask()
>>>> succeeds for a device, dma_set_coherent_mask() with the same mask will also succeed.
>>>>
>>>> Could you just call dma_set_mask_and_coherent() here to avoid that complex logic?
>>>
>>> I don't think that would work. The mpt2sas driver wants to set the dma mask to 64bits
>>> but set the coherent mask to 32 bits, then my change is to set the coherent mask to
>>> 64bits if setting it to 32bit fails. I'm not seeing how using dma_set_mask_and_coherent
>>> would simplify anything here.
>>
>> My question was more about why the driver would ask for a 32-bit coherent
>> mask to start with. Is this a limitation in the mpt2sas device that can
>> only have descriptors at low addresses, or is it trying to work around some
>> bug in a particular host system?
>
> I'll need help from Sreekanth in answering that. All that is in the git commit log is:
>
>     2. Initially set the consistent DMA mask to 32 bit and then change it to 64 bit mask
>     after allocating RDPQ pools by calling the function _base_change_consistent_dma_mask.
>     This is to ensure that all the upper 32 bits of RDPQ entries's base address to be same.
>
> So, I'm not sure my patch won't break something with mpt2sas... This commit also changed
> how the RDPO pools are allocated, so its possible this won't work. However, I did load
> it on Power box and I'm not seeing any major problems so far. I am seeing the following message
> get logged on a regular basis, not sure if its related to this change or not:
>
> mpt2sas3: log_info(0x31120303): originator(IOP), code(0x03), sub_code(0x3112)
>
> -Brian
>
>
> --
> Brian King
> Power Linux I/O
> IBM Linux Technology Center
>
>
--
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
Benjamin Herrenschmidt May 13, 2015, 8:56 p.m. UTC | #7 
On Wed, 2015-05-13 at 22:14 +0530, Sreekanth Reddy wrote:
> Hi Brain,
> 
> We had a restriction from the firmware that the upper 32 bits of the
> RDPQ pool entries must be same. So to limit this restriction we
> initially set the consistent DMA mask to 32 and then after allocating
> the RDPQ pools we changed the consistent DMA mask to 64 before
> allocating remaining pools.

Brian, maybe we should just bite that bullet and implement that hybrid
DMA ops I mentioned. I'll see if I can spare some time today to look
at it. It would work as long as we never remove the legacy window using
the DDW APIs (removing the legacy window is broken anyway for other
reasons I think we discussed already).

As long as we have both the legacy window and the DDW available (or the
legacy and bypass on "nv"), we can then route individual DMAs according
to the corresponding applicable mask.

I'll try to come up with a patch but I'll need you to test it.

Cheers,
Ben.

> Regards,
> Sreekanth
> 
> On Wed, May 13, 2015 at 7:42 PM, Brian King <brking@linux.vnet.ibm.com> wrote:
> > On 05/13/2015 08:31 AM, Arnd Bergmann wrote:
> >> On Wednesday 13 May 2015 08:23:41 Brian King wrote:
> >>> On 05/13/2015 03:10 AM, Arnd Bergmann wrote:
> >>>> On Tuesday 12 May 2015 18:24:43 Brian King wrote:
> >>>>>
> >>>>> Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for mpt2sas on Power.
> >>>>> That commit changed the sequence for setting up the DMA and coherent DMA masks so
> >>>>> that during initialization the driver requests a 64 bit DMA mask and a 32 bit consistent
> >>>>> DMA mask, then later requests a 64 bit consistent DMA mask. The Power architecture does
> >>>>> not currently support this, which results in always falling back to a 32 bit DMA window,
> >>>>> which has a negative impact on performance. Tweak this algorithm slightly so that
> >>>>> if requesting a 32 bit consistent mask fails after we've successfully set a 64 bit
> >>>>> DMA mask, just try to get a 64 bit consistent mask. This should preserve existing
> >>>>> behavior on platforms that support mixed mask setting and restore previous functionality
> >>>>> to those that do not.
> >>>>>
> >>>>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> >>>>
> >>>> I believe the way the API is designed, it should guarantee that after dma_set_mask()
> >>>> succeeds for a device, dma_set_coherent_mask() with the same mask will also succeed.
> >>>>
> >>>> Could you just call dma_set_mask_and_coherent() here to avoid that complex logic?
> >>>
> >>> I don't think that would work. The mpt2sas driver wants to set the dma mask to 64bits
> >>> but set the coherent mask to 32 bits, then my change is to set the coherent mask to
> >>> 64bits if setting it to 32bit fails. I'm not seeing how using dma_set_mask_and_coherent
> >>> would simplify anything here.
> >>
> >> My question was more about why the driver would ask for a 32-bit coherent
> >> mask to start with. Is this a limitation in the mpt2sas device that can
> >> only have descriptors at low addresses, or is it trying to work around some
> >> bug in a particular host system?
> >
> > I'll need help from Sreekanth in answering that. All that is in the git commit log is:
> >
> >     2. Initially set the consistent DMA mask to 32 bit and then change it to 64 bit mask
> >     after allocating RDPQ pools by calling the function _base_change_consistent_dma_mask.
> >     This is to ensure that all the upper 32 bits of RDPQ entries's base address to be same.
> >
> > So, I'm not sure my patch won't break something with mpt2sas... This commit also changed
> > how the RDPO pools are allocated, so its possible this won't work. However, I did load
> > it on Power box and I'm not seeing any major problems so far. I am seeing the following message
> > get logged on a regular basis, not sure if its related to this change or not:
> >
> > mpt2sas3: log_info(0x31120303): originator(IOP), code(0x03), sub_code(0x3112)
> >
> > -Brian
> >
> >
> > --
> > Brian King
> > Power Linux I/O
> > IBM Linux Technology Center
> >
> >


--
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
Brian King May 13, 2015, 9:37 p.m. UTC | #8 
On 05/13/2015 03:56 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2015-05-13 at 22:14 +0530, Sreekanth Reddy wrote:
>> Hi Brain,
>>
>> We had a restriction from the firmware that the upper 32 bits of the
>> RDPQ pool entries must be same. So to limit this restriction we
>> initially set the consistent DMA mask to 32 and then after allocating
>> the RDPQ pools we changed the consistent DMA mask to 64 before
>> allocating remaining pools.
> 
> Brian, maybe we should just bite that bullet and implement that hybrid
> DMA ops I mentioned. I'll see if I can spare some time today to look
> at it. It would work as long as we never remove the legacy window using
> the DDW APIs (removing the legacy window is broken anyway for other
> reasons I think we discussed already).
> 
> As long as we have both the legacy window and the DDW available (or the
> legacy and bypass on "nv"), we can then route individual DMAs according
> to the corresponding applicable mask.
> 
> I'll try to come up with a patch but I'll need you to test it.

Sure. I can help with that.

Thanks,

Brian

> 
> Cheers,
> Ben.
> 
>> Regards,
>> Sreekanth
>>
>> On Wed, May 13, 2015 at 7:42 PM, Brian King <brking@linux.vnet.ibm.com> wrote:
>>> On 05/13/2015 08:31 AM, Arnd Bergmann wrote:
>>>> On Wednesday 13 May 2015 08:23:41 Brian King wrote:
>>>>> On 05/13/2015 03:10 AM, Arnd Bergmann wrote:
>>>>>> On Tuesday 12 May 2015 18:24:43 Brian King wrote:
>>>>>>>
>>>>>>> Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for mpt2sas on Power.
>>>>>>> That commit changed the sequence for setting up the DMA and coherent DMA masks so
>>>>>>> that during initialization the driver requests a 64 bit DMA mask and a 32 bit consistent
>>>>>>> DMA mask, then later requests a 64 bit consistent DMA mask. The Power architecture does
>>>>>>> not currently support this, which results in always falling back to a 32 bit DMA window,
>>>>>>> which has a negative impact on performance. Tweak this algorithm slightly so that
>>>>>>> if requesting a 32 bit consistent mask fails after we've successfully set a 64 bit
>>>>>>> DMA mask, just try to get a 64 bit consistent mask. This should preserve existing
>>>>>>> behavior on platforms that support mixed mask setting and restore previous functionality
>>>>>>> to those that do not.
>>>>>>>
>>>>>>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
>>>>>>
>>>>>> I believe the way the API is designed, it should guarantee that after dma_set_mask()
>>>>>> succeeds for a device, dma_set_coherent_mask() with the same mask will also succeed.
>>>>>>
>>>>>> Could you just call dma_set_mask_and_coherent() here to avoid that complex logic?
>>>>>
>>>>> I don't think that would work. The mpt2sas driver wants to set the dma mask to 64bits
>>>>> but set the coherent mask to 32 bits, then my change is to set the coherent mask to
>>>>> 64bits if setting it to 32bit fails. I'm not seeing how using dma_set_mask_and_coherent
>>>>> would simplify anything here.
>>>>
>>>> My question was more about why the driver would ask for a 32-bit coherent
>>>> mask to start with. Is this a limitation in the mpt2sas device that can
>>>> only have descriptors at low addresses, or is it trying to work around some
>>>> bug in a particular host system?
>>>
>>> I'll need help from Sreekanth in answering that. All that is in the git commit log is:
>>>
>>>     2. Initially set the consistent DMA mask to 32 bit and then change it to 64 bit mask
>>>     after allocating RDPQ pools by calling the function _base_change_consistent_dma_mask.
>>>     This is to ensure that all the upper 32 bits of RDPQ entries's base address to be same.
>>>
>>> So, I'm not sure my patch won't break something with mpt2sas... This commit also changed
>>> how the RDPO pools are allocated, so its possible this won't work. However, I did load
>>> it on Power box and I'm not seeing any major problems so far. I am seeing the following message
>>> get logged on a regular basis, not sure if its related to this change or not:
>>>
>>> mpt2sas3: log_info(0x31120303): originator(IOP), code(0x03), sub_code(0x3112)
>>>
>>> -Brian
>>>
>>>
>>> --
>>> Brian King
>>> Power Linux I/O
>>> IBM Linux Technology Center
>>>
>>>
> 
>
diff mbox

Patch

diff -puN drivers/scsi/mpt2sas/mpt2sas_base.c~mpt2sas_dma_mask drivers/scsi/mpt2sas/mpt2sas_base.c
--- linux/drivers/scsi/mpt2sas/mpt2sas_base.c~mpt2sas_dma_mask	2015-05-12 16:09:58.228687852 -0500
+++ linux-bjking1/drivers/scsi/mpt2sas/mpt2sas_base.c	2015-05-12 17:38:31.588060903 -0500
@@ -1200,12 +1200,14 @@  _base_config_dma_addressing(struct MPT2S
 		const uint64_t required_mask =
 		    dma_get_required_mask(&pdev->dev);
 		if ((required_mask > DMA_BIT_MASK(32)) &&
-		    !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
-		    !pci_set_consistent_dma_mask(pdev, consistent_dma_mask)) {
-			ioc->base_add_sg_single = &_base_add_sg_single_64;
-			ioc->sge_size = sizeof(Mpi2SGESimple64_t);
-			ioc->dma_mask = 64;
-			goto out;
+		    !pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
+			if (!pci_set_consistent_dma_mask(pdev, consistent_dma_mask) ||
+			    !pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
+				ioc->base_add_sg_single = &_base_add_sg_single_64;
+				ioc->sge_size = sizeof(Mpi2SGESimple64_t);
+				ioc->dma_mask = 64;
+				goto out;
+			}
 		}
 	}