Testing whether a pointer is not NULL after it has been dereferenced is
not useful. Hence remove the if (fcport) test. This was detected by
Coverity.
Cc: Himanshu Madhani
Cc: Giridhar Malavali
Signed-off-by: Bart Van Assche
---
drivers/scsi/qla2xxx/qla_nvme.c | 7 +++
1 file changed, 3
From: Xiang Chen
Add host reset interface to make it easier for testing the host
reset feature.
Signed-off-by: Xiang Chen
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 13 +
drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 1 +
drivers/scsi/hisi_sas/hisi_sas_v2_h
gt;>
>> Since then blktests has grown and became go-to framework where we have
>> integrated
>> different stand-alone test suites like SRP-tests, NVMFTESTS, NVMe Multipath
>> tests,
>> zone block device tests, into one central framework, which has made an
>
n
>> about:-
>>
>> 1. Current status of the blktests framework.
>> 2. Any new/missing features that we want to add in the blktests.
>> 3. Any new kernel features that could be used to make testing easier?
>> E.g. Implementing new features in the null_blk.c in o
Anyway, enabling Travis CI is easy:
> > * Navigate to https://travis-ci.org/ and click on "Sign in with github".
> > * In the left column, click on "+" (Add New Repository).
> > * For the blktests repository, enable continuous integration. This will
> >
ithub".
> * In the left column, click on "+" (Add New Repository).
> * For the blktests repository, enable continuous integration. This will cause
> a
> continuous integration test to be started after every git push and also
> every
> time a pull request is submitted. The
Sign in with github".
* In the left column, click on "+" (Add New Repository).
* For the blktests repository, enable continuous integration. This will cause a
continuous integration test to be started after every git push and also every
time a pull request is submitted. The rdma-core
ng new features in the null_blk.c in order to have device
> > independent complete test coverage. (e.g. adding discard command for
> > null_blk or any
> > other specific REQ_OP). Discussion about having any new tracepoint events
> > in the block layer.
> > 4. Any new te
ework.
> 2. Any new/missing features that we want to add in the blktests.
> 3. Any new kernel features that could be used to make testing easier?
> E.g. Implementing new features in the null_blk.c in order to have device
> independent complete test coverage. (e.g. adding discard com
e support).
>>
>> Since then blktests has grown and became go-to framework where we have
>> integrated
>> different stand-alone test suites like SRP-tests, NVMFTESTS, NVMe Multipath
>> tests,
>> zone block device tests, into one central framework, which has made an
>
with the latest block layer changed which are being added
> based
> on the different device features from different device types
> (e.g. NVMe devices with Zoned Namespace support).
>
> Since then blktests has grown and became go-to framework where we have
> integrated
>
ent device types
(e.g. NVMe devices with Zoned Namespace support).
Since then blktests has grown and became go-to framework where we have
integrated
different stand-alone test suites like SRP-tests, NVMFTESTS, NVMe Multipath
tests,
zone block device tests, into one central framework, which h
Did you get my email from last week?
Let me know if you have photos for cutting out or retouching?
We are an image team who can do editing for your the web store photos,
industry photos or portrait photos.
Send photos, we will do testing for you to check quality.
Waiting for your reply soon.
Th
On 07/18/2018 05:46 PM, Bart Van Assche wrote:
> On Sun, 2018-07-15 at 18:16 -0500, Mike Christie wrote:
>> + int (*test_session)(struct se_session *, u8 timeout);
>
> Does any of the patches in this series define a test_session callback
> function?
Patch 14 does.
>
> What is the unit of
On Sun, 2018-07-15 at 18:16 -0500, Mike Christie wrote:
> + int (*test_session)(struct se_session *, u8 timeout);
Does any of the patches in this series define a test_session callback
function?
What is the unit of the timeout parameter? 1/HZ, ms or s?
Thanks,
Bart.
This adds a callout and configfs file so userspace apps can
test a session. It is useful for apps that do not want
to enable target nops that may disrupt normal traffic
and only want to test it during specific events like
failover/failbacks when there might be multiple sessions
to the same target
ts of potential for messing up the selection algorithm.
> > > This adds a test for catching regressions here.
> >
> > I'm waiting to see how the patches end up before applying this, but I'm
> > glad to see this test :) A few comments below. I've addres
reliably
So could you test v4.16 and see if this issue is fixed?
Thanks,
--
You are receiving this mail because:
You are watching the assignee of the bug.
0, Omar Sandoval wrote:
> >>>> On Thu, Apr 19, 2018 at 11:53:30AM -0700, Omar Sandoval wrote:
> >>>>> Thanks for the test! Applied.
> >>>>
> >>>> Side note, it's unfortunate that this test takes 180 seconds to run only
> >>&g
ndoval wrote:
>>>>> Thanks for the test! Applied.
>>>>
>>>> Side note, it's unfortunate that this test takes 180 seconds to run only
>>>> because we have to wait for the command timeout. We should be able to
>>>> export request_qu
On Thu, Apr 19, 2018 at 01:44:41PM -0600, Jens Axboe wrote:
> On 4/19/18 1:41 PM, Bart Van Assche wrote:
> > On Thu, 2018-04-19 at 12:13 -0700, Omar Sandoval wrote:
> >> On Thu, Apr 19, 2018 at 11:53:30AM -0700, Omar Sandoval wrote:
> >>> Thanks for the test! Appl
On 4/19/18 1:13 PM, Omar Sandoval wrote:
> On Thu, Apr 19, 2018 at 11:53:30AM -0700, Omar Sandoval wrote:
>> Thanks for the test! Applied.
>
> Side note, it's unfortunate that this test takes 180 seconds to run only
> because we have to wait for the command timeout. We sho
On 4/19/18 1:41 PM, Bart Van Assche wrote:
> On Thu, 2018-04-19 at 12:13 -0700, Omar Sandoval wrote:
>> On Thu, Apr 19, 2018 at 11:53:30AM -0700, Omar Sandoval wrote:
>>> Thanks for the test! Applied.
>>
>> Side note, it's unfortunate that this test takes 180 sec
On Thu, 2018-04-19 at 12:13 -0700, Omar Sandoval wrote:
> On Thu, Apr 19, 2018 at 11:53:30AM -0700, Omar Sandoval wrote:
> > Thanks for the test! Applied.
>
> Side note, it's unfortunate that this test takes 180 seconds to run only
> because we have to wait for the comman
On Thu, Apr 19, 2018 at 11:53:30AM -0700, Omar Sandoval wrote:
> Thanks for the test! Applied.
Side note, it's unfortunate that this test takes 180 seconds to run only
because we have to wait for the command timeout. We should be able to
export request_queue->rq_timeout writeable in s
ed SAM_STAT_TASK_SET_FULL results in EIO on timing out
> command.
> +#
> +# Regression test for commit cbe095e2b584 ("Revert "scsi: core: return
> +# BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"")
> +#
> +# Found independently of corresponding
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
b/tests/scsi/004
new file mode 100755
index 000..4852efc
--- /dev/null
+++ b/tests/scsi/004
@@ -0,0 +1,59 @@
+#!/bin/bash
+#
+# Ensure repeated SAM_STAT_TASK_SET_FULL results in EIO on timing out command.
+#
+# Regression test for commit cbe095e2b584 ("Revert "scsi: core: return
+#
The test-case results with PATCH v2.
scsih_abort()
=
Without patch:
[ 362.669743] setting logging_level(0x1000)
[ 362.705074] mpt3sas_cm0: skip free_smid/scsi_done scmd(c01fd4f2bd40)
[ 363.956579] sd 16:0:1:0: [sdf] Synchronizing SCSI cache
[ 363.956844
On 01/31/2018 08:50 PM, Bart Van Assche wrote:
I think it would be useful to have some variant of the above code in the kernel
tree. Are you familiar with the fault injection framework (see also
and Documentation/fault-injection/fault-injection.txt)?
No, not yet. That's very interesting.
Do
On Wed, 2018-01-31 at 17:24 -0200, Mauricio Faria de Oliveira wrote:
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 3c4e47c..611cee33 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -2997,6
This patch can be verified with this simple test-case,
which inserts a wait loop at the bottom of 'scsih_shutdown()'
and forces SCSI commands to timeout (skip 'scmd->scsi_done()').
It abuses the 'ioc->logging_level' parameter do to that, with:
- 0x1000: wa
Himanshu,
> This patch fixes memory corrpution while performing
> HBA Reset test.
Applied to 4.16/scsi-fixes. Thank you!
--
Martin K. Petersen Oracle Linux Engineering
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
From: Quinn Tran
This patch fixes memory corrpution while performing
HBA Reset test.
Following stack trace is seen
[ 466.397219] BUG: unable to handle kernel NULL pointer dereference at
0020
[ 466.433669] IP: [] qlt_free_session_done+0x260/0x5f0
[qla2xxx]
[ 466.467731] PGD 0
On Tue, Aug 15, 2017 at 11:00:49PM -0700, Omar Sandoval wrote:
> On Wed, Aug 09, 2017 at 12:50:06PM +0200, Hannes Reinecke wrote:
> > SCSI device blacklisting seems to be a tricky subject, with
> > lots of potential for messing up the selection algorithm.
> > This add
On Wed, Aug 09, 2017 at 12:50:06PM +0200, Hannes Reinecke wrote:
> SCSI device blacklisting seems to be a tricky subject, with
> lots of potential for messing up the selection algorithm.
> This adds a test for catching regressions here.
I'm waiting to see how the patches end up b
On Wed, Aug 09, 2017 at 12:50:05PM +0200, Hannes Reinecke wrote:
> Add a test group for tests of the SCSI midlayer.
>
> Signed-off-by: Hannes Reinecke
> ---
> tests/scsi/group | 26 ++
> 1 file changed, 26 insertions(+)
> create mode 100644 tests
On Wed, 2017-08-09 at 12:50 +0200, Hannes Reinecke wrote:
> +requires() {
> +if modinfo scsi_debug | grep -q inq_vendor ; then
> + return 0
> +fi
> +return 1
> +}
How about changing the above four statements into the following, which is
shorter and more robust?
modinfo scsi_debug
Add a test group for tests of the SCSI midlayer.
Signed-off-by: Hannes Reinecke
---
tests/scsi/group | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 tests/scsi/group
diff --git a/tests/scsi/group b/tests/scsi/group
new file mode 100644
index 000
SCSI device blacklisting seems to be a tricky subject, with
lots of potential for messing up the selection algorithm.
This adds a test for catching regressions here.
Signed-off-by: Hannes Reinecke
---
tests/scsi/001 | 69 ++
tests/scsi/001
Le 07/08/2017 à 10:25, walter harms a écrit :
Am 07.08.2017 00:51, schrieb Christophe JAILLET:
In the lines above this test, 8 'kzalloc' are performed, but only 7 results
are tested.
Add the missing one (i.e. '!ioc->port_enable_cmds.reply').
Signed-off-by: Christophe
Am 07.08.2017 00:51, schrieb Christophe JAILLET:
> In the lines above this test, 8 'kzalloc' are performed, but only 7 results
> are tested.
>
> Add the missing one (i.e. '!ioc->port_enable_cmds.reply').
>
> Signed-off-by: Christophe JAILLET
> --
In the lines above this test, 8 'kzalloc' are performed, but only 7 results
are tested.
Add the missing one (i.e. '!ioc->port_enable_cmds.reply').
Signed-off-by: Christophe JAILLET
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 8
1 file changed, 4 insertions(+), 4 d
From: Steffen Maier
Signed-off-by: Steffen Maier
Reviewed-by: Benjamin Block
Signed-off-by: Benjamin Block
---
drivers/s390/scsi/zfcp_fsf.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c
index c10b4b9f1574..9f
On Thu, Jul 06, 2017 at 02:09:21PM +0200, Johannes Thumshirn wrote:
> Add a regression test for the patch titled "scsi: sg: fix
> SG_DXFER_FROM_DEV transfers" which reassembles the syscalls done by Nero
> Burning ROM to discover CD and DVD burners.
Fixed up a few things below
Omar, ping?
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9
Add a regression test for the patch titled "scsi: sg: fix
SG_DXFER_FROM_DEV transfers" which reassembles the syscalls done by Nero
Burning ROM to discover CD and DVD burners.
Signed-off-by: Johannes Thumshirn
---
common/sg | 2 +-
src/.gitignore | 1 +
sr
On 06/07/2017 08:44 AM, Omar Sandoval wrote:
> Sorry for the delay, I was chasing down a few Btrfs bugs for the last
> couple of weeks. I applied these with some small changes. I stuck with
> running syzkaller on the scsi-debug device like you had here, we can
> revisit that for future tests if it
On Fri, May 19, 2017 at 03:55:28PM +0200, Johannes Thumshirn wrote:
> Add a test group for the SCSI generic driver and one syzcaller
> reproducer for this group.
>
> The reprodcuer is distributed as a C program, so the makefile is
> amended to build C files to be used in the test.
Hi Christian
Am 06.06.2017 um 07:17 schrieb Christian T. Steigies:
> On Mon, Jun 05, 2017 at 07:37:59PM +1200, Michael Schmitz wrote:
>> m68k_num_memory is unsuitable to test for the presence of FastRAM
>> on CT60 if the kernel is located in FastRAM: in arch/m68k/mm/motorola.c
>
Michael,
> m68k_num_memory is unsuitable to test for the presence of FastRAM on
> CT60 if the kernel is located in FastRAM: in arch/m68k/mm/motorola.c
> the ST-RAM chunk is skipped and m68k_num_memory is decremented in this
> case. m68k_realnum_memory still contains the actual n
On Mon, Jun 05, 2017 at 07:37:59PM +1200, Michael Schmitz wrote:
> m68k_num_memory is unsuitable to test for the presence of FastRAM
> on CT60 if the kernel is located in FastRAM: in arch/m68k/mm/motorola.c
> the ST-RAM chunk is skipped and m68k_num_memory is decremented in th
m68k_num_memory is unsuitable to test for the presence of FastRAM
on CT60 if the kernel is located in FastRAM: in arch/m68k/mm/motorola.c
the ST-RAM chunk is skipped and m68k_num_memory is decremented in this
case. m68k_realnum_memory still contains the actual number of RAM chunks
so use that
From: Joe Carnuccio
Signed-off-by: Joe Carnuccio
Signed-off-by: Himanshu Madhani
Reviewed-by: Bart Van Assche
---
drivers/scsi/qla2xxx/qla_init.c | 8
drivers/scsi/qla2xxx/qla_tmpl.c | 16 +---
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi
On Tue, 2017-05-30 at 10:54 -0700, Himanshu Madhani wrote:
> From: Joe Carnuccio
Reviewed-by: Bart Van Assche
From: Joe Carnuccio
Signed-off-by: Joe Carnuccio
Signed-off-by: Himanshu Madhani
---
drivers/scsi/qla2xxx/qla_init.c | 8
drivers/scsi/qla2xxx/qla_tmpl.c | 16 +---
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/
;s queued up in Martin's tree [1].
>
> I'm assuming this is a bug in the sg.c driver, in which case the 2/3
> prep and real test case looks fine. For generic device testing, we
> should just use SG_IO and not bother with sg.c at all. The world would
> be a better place if w
On 05/23/2017 08:25 AM, Johannes Thumshirn wrote:
> On 05/23/2017 04:15 PM, Jens Axboe wrote:
>> Add some code to the framework that allows you to get the corresponding
>> SG device for a SCSI block device? Make that part of the prepare, skip
>> the test if the block de
On 05/23/2017 04:15 PM, Jens Axboe wrote:
> Add some code to the framework that allows you to get the corresponding
> SG device for a SCSI block device? Make that part of the prepare, skip
> the test if the block device isn't a SCSI dev.
Well the code is already there (in patch 2/
On 05/23/2017 12:58 AM, Johannes Thumshirn wrote:
> On 05/22/2017 07:59 PM, Omar Sandoval wrote:
>> This looks much better, thanks! One question for you: is there any value
>> in running this on specific test devices (i.e., changing test() to
>> test_device() and using &qu
On 05/22/2017 07:59 PM, Omar Sandoval wrote:
> This looks much better, thanks! One question for you: is there any value
> in running this on specific test devices (i.e., changing test() to
> test_device() and using "$TEST_DEV" instead of a scsi-debug device), or
> would it be
On Fri, May 19, 2017 at 03:55:31PM +0200, Johannes Thumshirn wrote:
> Add a regression test for commit 48ae8484e9fc ("scsi: sg: don't return
> bogus Sg_requests"). This is a general protection fault triggered by
> syzcaller via issuing bogus read(2)s on the /dev/sg dev
On Thu, May 18, 2017 at 03:29:45PM +0200, Johannes Thumshirn wrote:
> On 05/18/2017 03:19 PM, Christoph Hellwig wrote:
> > All SG_IO test should also apply to block device nodes that support
> > the ioctl..
> >
>
> But these are not necessarily SG_IO tests, are they
Add the ability to build test cases from C files. This is handy for
things like syzcaller reproducers and all other kinds of test
binaries.
Signed-off-by: Johannes Thumshirn
---
Makefile | 26 +++-
src/.gitignore | 1 +
src/Makefile | 16 +++
src/sg-001.c | 438
Add a regression test for commit 48ae8484e9fc ("scsi: sg: don't return
bogus Sg_requests"). This is a general protection fault triggered by
syzcaller via issuing bogus read(2)s on the /dev/sg devices.
Signed-off-by: Johannes Thumshirn
---
tests/
Add a test group for tests of the SCSI generic driver and and
functions common to the SCSI generic driver and it's test cases.
Signed-off-by: Johannes Thumshirn
---
common/sg | 41 +
tests/sg/group | 28
2 files ch
Add a test group for the SCSI generic driver and one syzcaller
reproducer for this group.
The reprodcuer is distributed as a C program, so the makefile is
amended to build C files to be used in the test.
Changes to v1:
* Stripped left over TODO comment
* Modified reproducer to accept a device
On 05/19/2017 12:46 AM, Omar Sandoval wrote:
> Looking at this some more, it seems like the syzkaller reproducer always
> bangs on /dev/sg0. How hard would it be to adapt it to run on the sg
> device for every test device instead?
Can't be too hard I guess ;-).
Maybe I can even cle
On Thu, May 18, 2017 at 03:29:45PM +0200, Johannes Thumshirn wrote:
> On 05/18/2017 03:19 PM, Christoph Hellwig wrote:
> > All SG_IO test should also apply to block device nodes that support
> > the ioctl..
> >
>
> But these are not necessarily SG_IO tests, are they
On Thu, May 18, 2017 at 02:06:20PM -0700, Omar Sandoval wrote:
> On Thu, May 18, 2017 at 02:13:07PM +0200, Johannes Thumshirn wrote:
> > Add a test group for tests of the SCSI generic driver and and
> > functions common to the SCSI generic driver and it's test cases.
&g
On Thu, May 18, 2017 at 02:13:08PM +0200, Johannes Thumshirn wrote:
> Add a regression test for commit 48ae8484e9fc ("scsi: sg: don't return
> bogus Sg_requests"). This is a general protection fault triggered by
> syzcaller.
>
> Signed-off-by: Johannes Thumshirn
On Thu, May 18, 2017 at 02:13:07PM +0200, Johannes Thumshirn wrote:
> Add a test group for tests of the SCSI generic driver and and
> functions common to the SCSI generic driver and it's test cases.
>
> Signed-off-by: Johannes Thumshirn
> ---
&g
On 05/18/2017 03:19 PM, Christoph Hellwig wrote:
> All SG_IO test should also apply to block device nodes that support
> the ioctl..
>
But these are not necessarily SG_IO tests, are they?
The test included is doesn't hit the SG_IO path in the sg driver, but
the sg_read path.
O
All SG_IO test should also apply to block device nodes that support
the ioctl..
Add the ability to build test cases from C files. This is handy for
things like syzcaller reproducers and all other kinds of test
binaries.
Signed-off-by: Johannes Thumshirn
---
Makefile | 26 +++-
src/.gitignore | 1 +
src/Makefile | 14 ++
src/sg-001.c | 430
Add a test group for the SCSI generic driver and one syzcaller
reproducer for this group.
The reprodcuer is distributed as a C program, so the makefile is
amended to build C files to be used in the test.
I didn't get the TIMEOUT to work (not even with block/001) so I
decided to just requir
Add a test group for tests of the SCSI generic driver and and
functions common to the SCSI generic driver and it's test cases.
Signed-off-by: Johannes Thumshirn
---
common/sg | 22 ++
tests/sg/group | 40
2 files change
Add a regression test for commit 48ae8484e9fc ("scsi: sg: don't return
bogus Sg_requests"). This is a general protection fault triggered by
syzcaller.
Signed-off-by: Johannes Thumshirn
---
tests/sg/001 | 48
tests/sg/001.out |
--git a/tests/generic/420 b/tests/generic/420
new file mode 100755
index 000..592703d
--- /dev/null
+++ b/tests/generic/420
@@ -0,0 +1,77 @@
+#! /bin/bash
+# FS QA Test 420
+#
+# Regression test for information leak for lio-fileio target
+# BUG: If image file is less than virtual blockdev then
Test create virtual block device via lio-targed infastructure and
perform basic IO operations with data corruption detection.
Temprorally mark is as dangerous, because currently it trigger BUG_ON
inside blkdev_issue_flush
BTW: I use 'dd' to test read from corrupted image instead
On 2017-03-28 06:49, kusumi.tomoh...@gmail.com wrote:
From: Tomohiro Kusumi
(Note this commit directly goes on top of the previous one)
Signed-off-by: Tomohiro Kusumi
---
drivers/scsi/ufs/ufshcd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.c
From: Tomohiro Kusumi
(Note this commit directly goes on top of the previous one)
Signed-off-by: Tomohiro Kusumi
---
drivers/scsi/ufs/ufshcd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b006f1e..dd46259 1006
On Mon, Jan 23, 2017 at 03:26:09PM +0530, Chaitra P B wrote:
> Due existence of loop in the IO path our HBA will receive heavy IOs and
> also as driver is not updating the Reply Post Host Index frequently, So
> there will be a high chance that our Firmware unable to find any free entry
> in the Rep
Due existence of loop in the IO path our HBA will receive heavy IOs and
also as driver is not updating the Reply Post Host Index frequently, So
there will be a high chance that our Firmware unable to find any free entry
in the Reply Post Descriptor Queue (i.e. Queue overflow occurs) and can
observe
On Fri, Jan 20, 2017 at 8:40 PM, Johannes Thumshirn wrote:
> On Fri, Jan 20, 2017 at 08:12:12PM +0530, Chaitra P B wrote:
>> Due existence of loop in the IO path our HBA will receive heavy IOs and
>> also as driver is not updating the Reply Post Host Index frequently, So
>> there will be a high ch
On Fri, Jan 20, 2017 at 08:12:12PM +0530, Chaitra P B wrote:
> Due existence of loop in the IO path our HBA will receive heavy IOs and
> also as driver is not updating the Reply Post Host Index frequently, So
> there will be a high chance that our Firmware unable to find any free entry
> in the Rep
Due existence of loop in the IO path our HBA will receive heavy IOs and
also as driver is not updating the Reply Post Host Index frequently, So
there will be a high chance that our Firmware unable to find any free entry
in the Reply Post Descriptor Queue (i.e. Queue overflow occurs) and can
observe
Due existence of loop in the IO path our HBA will receive heavy IOs and
also as driver is not updating the Reply Post Host Index frequently, So
there will be a high chance that our Firmware unable to find any free entry
in the Reply Post Descriptor Queue (i.e. Queue overflow occurs) and can
observe
> "Tomas" == Tomas Henzl writes:
Tomas> Martin, another (better) patch "fnic: Correcting rport check
Tomas> location in fnic_queuecommand_lck" has been added to
Tomas> 4.10/scsi-queue.
Tomas> Please drop this one.
Done!
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe
On 1.11.2016 17:40, Tomas Henzl wrote:
> rport can't be null here, it would have failed already in
> fc_remote_port_chkready
>
> Signed-off-by: Tomas Henzl
Martin,
another (better) patch "fnic: Correcting rport check location in
fnic_queuecommand_lck"
has been added to 4.10/scsi-queue.
Please
Satish, Sesidhar,
Please review Tomas' patch:
https://patchwork.kernel.org/patch/9407637/
Thank you!
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More
> "Tomas" == Tomas Henzl writes:
Tomas> rport can't be null here, it would have failed already in
Tomas> fc_remote_port_chkready
Cisco folks: Please review!
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the b
9
>> year old bug and is marked for stable as well.
*sigh* It's always the most innocuous patches that cause the worst
regressions :(
Kashyap> I will run some more test (using patch set only marked for
Kashyap> stable from last series) and submit fix ASAP.
I just tried a system
> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Wednesday, November 09, 2016 6:50 AM
> To: Kashyap Desai; Martin K. Petersen
> Cc: linux-scsi
> Subject: Re: [REGRESSION] 4.9-rc4+ doesn't boot on my test box
>
> On 11/08/2016
on my test box
"Jens" == Jens Axboe writes:
Jens> I wasted half a day on this, thinking it was something in my
Jens> 4.10 branches. But it turns out it is not, the regression is in
Jens> mainline.
Jens -
Sorry for trouble. I did not validated this single patch. I vali
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Wednesday, November 09, 2016 4:45 AM
> To: Jens Axboe
> Cc: linux-scsi; Kashyap Desai; Martin K. Petersen
> Subject: Re: [REGRESSION] 4.9-rc4+ doesn't boot on my test box
&
> "Jens" == Jens Axboe writes:
Jens> I wasted half a day on this, thinking it was something in my
Jens> 4.10 branches. But it turns out it is not, the regression is in
Jens> mainline.
Kashyap, have you tested the stable fix without the remainder of the
driver update in place?
--
Martin K.
Hi,
I wasted half a day on this, thinking it was something in my 4.10
branches. But it turns out it is not, the regression is in mainline.
Looking at the recent fixes, turns out to be this one:
commit 1e793f6fc0db920400574211c48f9157a37e3945
Author: Kashyap Desai
Date: Fri Oct 21 06:33:32 20
Testing. Please ignore.
Thanks,
Don.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
1 - 100 of 371 matches
Mail list logo
