These drivers didn't bother to enable clustering, which allows merges
across pages. But the original block driver had not such limitation,
so there should be no need to set these limits either.
The old DAC960 drivers was fine with merging over segment bondaries,
so this new driver should be to.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/myrb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/myrb.c b/drivers/scsi/myrb.c
index 1d6dbd77bd0e..aeb282f617c5 100644
---
The old DAC960 drivers was fine with merging over segment bondaries,
so this new driver should be to.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/myrs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/myrs.c b/drivers/scsi/myrs.c
index 76a04cedfc83..0264a2e2bc19 100644
---
On Tue, Dec 18, 2018 at 11:23:32PM -0500, Martin K. Petersen wrote:
>
> Christoph,
>
> > can we get this reviewed and merge before the end of the merge window?
> > That gets the clustering put of the way for the multipage-biovec work
> > from Ming which we want to land in the block tree early in
Please consider this patch as
Acked-by: Sreekanth Reddy
On Wed, Dec 19, 2018 at 9:22 AM Martin K. Petersen
wrote:
>
>
> > With revision 09c2f95ad404, 64bit writes in _base_writeq() were rewritten
> > to use __raw_writeq() instad of writeq().
> >
> > This introduced a bug apparent on powerpc64 s
On 12/18/18 9:45 PM, Martin K. Petersen wrote:
If you haven't received feedback on a patch you should poke the relevant
driver maintainer.
Got it. Will do so.
Thanks
--
Gustavo
Jens,
> You can add my reviewed-by to 10 and add that one too, that makes more
> sense than me adding it for a post-merge pull. But either way works
> for me.
OK, done.
--
Martin K. Petersen Oracle Linux Engineering
John,
> From: Xiang Chen
>
> For v3 hw, we support DIF operation for SAS, but not SATA.
>
> In addition, DIF CRC16 is supported.
>
> This patchset adds the SW support for the described features. The main
> components are as follows:
> - Get protection mask from module param
> - Fill PI fields
>
On 12/18/18 9:23 PM, Martin K. Petersen wrote:
>
> Christoph,
>
>> can we get this reviewed and merge before the end of the merge window?
>> That gets the clustering put of the way for the multipage-biovec work
>> from Ming which we want to land in the block tree early in the next
>> merge window
Ewan,
> Certain older adapters such as the OneConnect OCe10100 may not have a
> valid wqpcnt value. In this case, do not set queue->page_count to 0
> in lpfc_sli4_queue_alloc() as this will prevent the driver from
> initializing.
Applied to 4.21/scsi-queue, thanks!
--
Martin K. Petersen
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
> b/drivers/scsi/megaraid/megaraid_sas_fp.c
> index 59ecbb3b53b5..a33628550425 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fp.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
> @@ -1266,7 +1266,7 @@ void mr_update_load_balance_params(
Christoph,
> can we get this reviewed and merge before the end of the merge window?
> That gets the clustering put of the way for the multipage-biovec work
> from Ming which we want to land in the block tree early in the next
> merge window.
I have been somewhat hesitant to apply this just befo
Wei,
> memory allocated by kmem_cache_alloc() should be freed using
> kmem_cache_free(), not kfree().
Applied to 4.21/scsi-queue, thanks!
--
Martin K. Petersen Oracle Linux Engineering
> With revision 09c2f95ad404, 64bit writes in _base_writeq() were rewritten
> to use __raw_writeq() instad of writeq().
>
> This introduced a bug apparent on powerpc64 systems such as the Raptor
> Talos II that causes the HBA to drop from the PCIe bus under heavy load and
> being reinitialized af
Bart,
> Commit b5b6e8c8d3b4 ("scsi: virtio_scsi: fix IO hang caused by
> automatic irq vector affinity") removed all virtio_scsi hostdata
> users. Since the SCSI host data is no longer used, also remove the
> host data itself.
Applied to 4.21/scsi-queue, thanks!
--
Martin K. Petersen Ora
These patches are based on Linus's tree
There are two more patches that need to be added
that were not fully tested until now.
The changes are:
- smartpqi-increase-fw-status-register-read-timeout
. wait longer for fw to fully initialize
- smartpqi-add-ofa-support
. allow on-line firmware upd
- need to bump up the driver version because
of the OFA patch and the fw status register
read timeout patch.
Reviewed-by: Gerry Morong
Signed-off-by: Don Brace
---
drivers/scsi/smartpqi/smartpqi_init.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/s
After an underwhelming response to my intermediate level patchsets to
modernize the sg driver in October this year (see "[PATCH 0/8] sg: major
cleanup, remove max_queue limit" followed by v2 and v3 between 20181019
and 20181028), I decided to move ahead and add the functionality proposed
for the v
From: Mahesh Rajashekhara
Problem:
- during the driver initialization, driver will poll fw
for KERNEL_UP in a 30 seconds timeout.
- if the firmware is not ready after 30 seconds,
driver will not be loaded.
Fix:
- change timeout from 30 seconds to 3 minutes.
Reported-by: Feng Li
Review
From: Mahesh Rajashekhara
- when OFA event occurs, driver will stop traffic to
RAID/HBA path. Driver waits for all the outstanding
requests to complete.
- Driver sends OFA event acknowledgment to firmware.
- Driver will wait until the new firmware is up and running.
- Driver will free up the
Hi,
Was this issue ever resolved? We are seeing this on 4.14.35.
Thanks,
Alan Adamson
On 5/9/18 3:27 PM, Ilkka Sovanto wrote:
Hi again, Chris and others!
We're hitting this again on 4.14.32.
Looks like the path iscsi_queuecommand -> prepd_reject/prepd_fault
results in iscsi_complete_task g
>
> I actually took a look at scsi_host_find_tag() - what I think needs fixing
> here is
> that it should not return a tag that isn't allocated.
> You're just looking up random stuff, that is a recipe for disaster.
> But even with that, there's no guarantee that the tag isn't going away.
Got your
https://bugzilla.kernel.org/show_bug.cgi?id=201935
--- Comment #3 from Bart Van Assche (bvanass...@acm.org) ---
A fix has been queued for the 4.19 stable series and should be included in a
4.19.x stable kernel soon. See also
https://lore.kernel.org/lkml/20181218163929.193192...@linuxfoundation.org
On 12/18/18 11:22 AM, Kashyap Desai wrote:
>>>
>>> At the time of device removal, it requires reverse traversing. Find
>>> out if each requests associated with sdev is part of hctx->tags->rqs()
>>> and clear that entry.
>>> Not sure about atomic traverse if more than one device removal is
>>> hap
> >
> > At the time of device removal, it requires reverse traversing. Find
> > out if each requests associated with sdev is part of hctx->tags->rqs()
> > and clear that entry.
> > Not sure about atomic traverse if more than one device removal is
> > happening in parallel. May be more error pron
On 12/18/18 11:08 AM, Kashyap Desai wrote:
>> On 12/18/18 10:48 AM, Kashyap Desai wrote:
On 12/18/18 10:08 AM, Kashyap Desai wrote:
>>>
>>> Other block drivers (e.g. ib_srp, skd) do not need this to work
>>> reliably.
>>> It has been explained to you that the bug that you
> On 12/18/18 10:48 AM, Kashyap Desai wrote:
> >>
> >> On 12/18/18 10:08 AM, Kashyap Desai wrote:
> >
> > Other block drivers (e.g. ib_srp, skd) do not need this to work
> > reliably.
> > It has been explained to you that the bug that you reported can be
> > fixed by modifying t
I'd like to announce the availability of the Broadcom (Emulex) FC target
driver - efct.
This is the 2nd round of announcement. In the first round, after
discussion with community members, it was decided that the driver would
consist of the following:
- A SLI4-library that can be used by bo
-Original Message-
From: Hannes Reinecke [mailto:h...@suse.de]
Sent: Tuesday, December 18, 2018 1:57 AM
To: Don Brace ; Kevin Barnett - C33748
; Scott Teel - C33730 ;
Justin Lindley - C33718 ; Scott Benesh - C33703
; bader.alisa...@microchip.com; Gerry Morong -
C33720 ; Mahesh Rajashek
The pull request you sent on Tue, 18 Dec 2018 07:57:14 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ddfbab46539f2d37a9e9d357b054486b51f7dc27
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On 12/18/18 10:48 AM, Kashyap Desai wrote:
>>
>> On 12/18/18 10:08 AM, Kashyap Desai wrote:
>
> Other block drivers (e.g. ib_srp, skd) do not need this to work
> reliably.
> It has been explained to you that the bug that you reported can be
> fixed by modifying the mpt3sas drive
>
> On 12/18/18 10:08 AM, Kashyap Desai wrote:
> >>>
> >>> Other block drivers (e.g. ib_srp, skd) do not need this to work
> >>> reliably.
> >>> It has been explained to you that the bug that you reported can be
> >>> fixed by modifying the mpt3sas driver. So why to fix this by
> >>> modifying the
On 12/18/18 11:13 AM, Boaz Harrosh wrote:
On 28/11/18 06:32, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva
ACK-by: Boaz Harrosh
Thank you, Boaz.
--
Gustavo
On 28/11/18 06:32, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva
ACK-by: Boaz Harrosh
> ---
> drivers/scsi/osd/osd_initiator.c | 3 ++-
> 1 file changed, 2 inse
On 12/18/18 10:08 AM, Kashyap Desai wrote:
>>>
>>> Other block drivers (e.g. ib_srp, skd) do not need this to work
>>> reliably.
>>> It has been explained to you that the bug that you reported can be
>>> fixed by modifying the mpt3sas driver. So why to fix this by modifying
>>> the block layer? Add
> >
> > Other block drivers (e.g. ib_srp, skd) do not need this to work
> > reliably.
> > It has been explained to you that the bug that you reported can be
> > fixed by modifying the mpt3sas driver. So why to fix this by modifying
> > the block layer? Additionally, what prevents that a race condit
On 17/12/2018 10:28, Marc Gonzalez wrote:
> On 17/12/2018 08:14, Kyuho Choi wrote:
>
>> On Thursday, December 13, 2018, Marc Gonzalez wrote:
>>
>> I'm having trouble getting UFS working on an APQ8098 MEDIABOX dev board.
>> (I'm running v4.20-rc4 with a few UFS patches taken off the MSM li
On Tue, Dec 18, 2018 at 08:47:48AM +0100, Hannes Reinecke wrote:
> On 12/18/18 8:08 AM, Christoph Hellwig wrote:
>> Martin and others:
>>
>> can we get this reviewed and merge before the end of the merge window?
>> That gets the clustering put of the way for the multipage-biovec work
>> from Ming w
On Tue, Dec 18, 2018 at 04:12:30PM +0100, Greg Kroah-Hartman wrote:
On Mon, Dec 17, 2018 at 07:20:28PM -0500, Sasha Levin wrote:
On Fri, Dec 14, 2018 at 11:10:05PM +0100, Arnd Bergmann wrote:
> Hi Greg,
>
> I did some randconfig testing on linux-4.19 arm/arm64/x86. So far I needed
> 27 patches,
On 12/18/18 9:15 AM, Bart Van Assche wrote:
> On Tue, 2018-12-18 at 12:38 +0530, Kashyap Desai wrote:
>> V1 -> V2
>> Added fix in __blk_mq_finish_request around blk_mq_put_tag() for
>> non-internal tags
>>
>> Problem statement :
>> Whenever try to get outstanding request via scsi_host_find_tag,
>>
On Tue, 2018-12-18 at 12:38 +0530, Kashyap Desai wrote:
> V1 -> V2
> Added fix in __blk_mq_finish_request around blk_mq_put_tag() for
> non-internal tags
>
> Problem statement :
> Whenever try to get outstanding request via scsi_host_find_tag,
> block layer will return stale entries instead of act
Three fixes: The t10-pi one is a regression from the 4.19 release, the
qla2xxx one is a 4.20 merge window regression and the bnx2fc is a very
old bug.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Dan Carpenter (1):
Hi Martin,
Friendly ping:
Only 8 out the 41 patches in this series have been applied so far.
I wonder if you could apply the rest of this series, except:
[PATCH 02/41] scsi: NCR5380: Mark expected switch fall-through
(I'll send a v2 of this patch)
Thanks
--
Gustavo
On 11/27/18 10:18 PM, Gu
On Mon, Dec 17, 2018 at 07:20:28PM -0500, Sasha Levin wrote:
> On Fri, Dec 14, 2018 at 11:10:05PM +0100, Arnd Bergmann wrote:
> > Hi Greg,
> >
> > I did some randconfig testing on linux-4.19 arm/arm64/x86. So far I needed
> > 27 patches, most of which are also still needed in mainline Linux. I
> >
This patchset fixes an issue with enabling 64-bit DMA for
megaraid controllers.
The second patch updates the driver version for tracking.
Shivasharan S (2):
megaraid_sas: Use 63-bit DMA addressing
megaraid_sas: driver version update
drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
driver
Although MegaRAID controllers support 64-bit DMA addressing,
as per hardware design, DMA address with all 64-bits set
(0x-) results in a firmware fault.
Fix -
Driver will set 63-bit DMA mask to ensure the above address
will not be used.
Cc: sta...@vger.kernel.org
Signed-off-by: Sh
Signed-off-by: Shivasharan S
---
drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index 8bfe4c54e4ae..2099c8e9d629 100644
--- a/drivers/scsi/megaraid/megaraid_s
On 12/18/18 8:08 AM, Kashyap Desai wrote:
V1 -> V2
Added fix in __blk_mq_finish_request around blk_mq_put_tag() for
non-internal tags
Problem statement :
Whenever try to get outstanding request via scsi_host_find_tag,
block layer will return stale entries instead of actual outstanding
request. K
On 13/12/2018 16:17, Christoph Hellwig wrote:
> There is no such limitation in the protocol or implementation, so
> remove it.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Juergen Gross
Juergen
49 matches
Mail list logo