On Mon, 2015-04-06 at 23:17 -0700, Christoph Hellwig wrote:
On Thu, Apr 02, 2015 at 01:57:10PM -0700, Nicholas A. Bellinger wrote:
mempools are for I/O path that make guaranteed progress. While the
callers of core_enable_device_list_for_node are in the control path,
and not in a very
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/char/ppdev.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
also return the proper error code in module_init.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/net/plip/plip.c | 16 ++--
1 file
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/i2c/busses/i2c-parport.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/pps/clients/pps_parport.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
On Wed, Apr 08, 2015 at 02:38:32PM +0300, Dan Carpenter wrote:
1) We can't apply this patch on its own so this way of breaking up the
patches doesn't work.
yes, if the first patch is reverted for any reason all the others need
to be reverted also. so then everything in one single patch?
2) I
Currently we are not checking if attach has succeeded or not. Also
parport_register_driver() always return 0 even if attach fails.
But in many places where attach has been used, it can fail.
So, modified the parport code to check the return value of attach and
accordingly return either 0 or error
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/scsi/imm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/char/lp.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/pps/generators/pps_gen_parport.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
On Wed, Apr 08, 2015 at 02:38:32PM +0300, Dan Carpenter wrote:
1) We can't apply this patch on its own so this way of breaking up the
patches doesn't work.
The right thing is to do add an attach_ret().
static int do_attach(drv)
{
if (drv-attach_ret)
return
On Wed, Apr 08, 2015 at 02:44:37PM +0300, Dan Carpenter wrote:
On Wed, Apr 08, 2015 at 02:38:32PM +0300, Dan Carpenter wrote:
Then we convert one driver to use the new function pointer and see if
it simplifies the code. If so we can transition the others as well. If
not then we give up.
i
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
sound/drivers/portman2x4.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff
1) We can't apply this patch on its own so this way of breaking up the
patches doesn't work.
2) I was thinking that all the -attach() calls would have to succeed or
we would bail. Having some of them succeed and some fail doesn't seem
like it will simplify the driver code very much. But I can
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/staging/panel/panel.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/spi/spi-lm70llp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
as of now, we are not checking if attach or parport_register_driver
has succeeded or failed. But attach can fail in the places where they
have been used. Lets check the return of attach, and if attach fails
then parport_register_driver should also fail. We can have multiple
parallel port so we
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
sound/drivers/mts64.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git
now that we are monitoring the return value from attach, make the
required changes to return proper value from its attach function.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/scsi/ppa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Hannes,
Thank you for reviewing patches. Please find responses inline.
On 07/04/15 12:08 pm, Hannes Reinecke h...@suse.de wrote:
On 04/02/2015 10:13 AM, Narsimhulu Musini (nmusini) wrote:
Hi Hannes,
Thank you for reviewing the patch. Please find responses inline.
I will incorporate
On Tue, 2015-04-07 at 19:27 -0400, Martin K. Petersen wrote:
nab == Nicholas A Bellinger n...@daterainc.com writes:
nab This specifically is to allow LIO to perform WRITE_STRIP +
nab READ_INSERT operations when functioning with non T10-PI enabled
nab devices, seperate from any available hw
On 04/08/2015 11:05 AM, Narsimhulu Musini (nmusini) wrote:
Hi Hannes,
Thank you for reviewing patches. Please find responses inline.
On 07/04/15 12:08 pm, Hannes Reinecke h...@suse.de wrote:
On 04/02/2015 10:13 AM, Narsimhulu Musini (nmusini) wrote:
Hi Hannes,
Thank you for
Hi Christoph,
Thank you for reviewing the patch. Please find responses inline.
I will incorporate the comments and suggestions in next patch submittal.
On 02/04/15 2:51 pm, Christoph Hellwig h...@infradead.org wrote:
+/*
+ * Usage of the scsi_cmnd scratchpad.
+ * These fields are locked by
Hi Hannes,
Thank you for reviewing patches. Please find responses inline.
I will incorporate the comments and suggestions in next patch submittal.
On 07/04/15 11:57 am, Hannes Reinecke h...@suse.de wrote:
Hi Narsimhulu,
On 04/02/2015 09:48 AM, Narsimhulu Musini (nmusini) wrote:
Hi Hannes,
On Wed, Apr 08, 2015 at 05:20:10PM +0530, Sudip Mukherjee wrote:
On Wed, Apr 08, 2015 at 02:38:32PM +0300, Dan Carpenter wrote:
1) We can't apply this patch on its own so this way of breaking up the
patches doesn't work.
yes, if the first patch is reverted for any reason all the others need
On Wed, Apr 08, 2015 at 04:32:57PM +0300, Sergei Shtylyov wrote:
Hello.
On 4/8/2015 2:20 PM, Sudip Mukherjee wrote:
now that we are monitoring the return value from attach, make the
So you've first changed the method prototype and follow up with
the changes to the actual
Hello.
On 4/8/2015 2:20 PM, Sudip Mukherjee wrote:
now that we are monitoring the return value from attach, make the
So you've first changed the method prototype and follow up with the
changes to the actual implementations? That's backward. I'm afraid such
changes can't be done
2015-04-08 14:13 GMT+09:00 Nicholas A. Bellinger n...@linux-iscsi.org:
On Sun, 2015-04-05 at 23:59 +0900, Akinobu Mita wrote:
The scatterlist for protection information which is passed to
sbc_dif_verify_read() or sbc_dif_verify_write() requires that
neighboring scatterlist entries are
On Wed, Apr 8, 2015 at 11:17 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Wed, 2015-04-08 at 10:59 -0700, Andy Lutomirski wrote:
This is a regression somewhere between 3.15 and 3.19.3. Let me know
if more diagnostics would be helpful.
It's not a regression. Likely
On Wed, 2015-04-08 at 11:26 -0700, Andy Lutomirski wrote:
On Wed, Apr 8, 2015 at 11:17 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Wed, 2015-04-08 at 10:59 -0700, Andy Lutomirski wrote:
This is a regression somewhere between 3.15 and 3.19.3. Let me know
if more
On Wed, 2015-04-08 at 18:33 +0200, Christoph Hellwig wrote:
This fixes the crash that I saw, but the Compare and Write testcast
in the scsi testsuite still fails..
I'm not seeing this on my end:
root@scsi-mq:/usr/src/libiscsi.git# ./test-tool/iscsi-test-cu --test
LINUX.CompareAndWrite
On Wed, Apr 08, 2015 at 10:59:36AM -0700, Andy Lutomirski wrote:
This is a regression somewhere between 3.15 and 3.19.3. Let me know
if more diagnostics would be helpful.
Try this patch:
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Andy Lutomirski
Sent: Wednesday, April 8, 2015 1:27 PM
To: James Bottomley
Cc: Kashyap Desai; Sumit Saxena; Uday Lingala;
megaraidlinux@avagotech.com; Linux SCSI
On Wed, Apr 8, 2015 at 11:51 AM, Christoph Hellwig h...@infradead.org wrote:
On Wed, Apr 08, 2015 at 10:59:36AM -0700, Andy Lutomirski wrote:
This is a regression somewhere between 3.15 and 3.19.3. Let me know
if more diagnostics would be helpful.
Try this patch:
diff --git
This fixes the crash that I saw, but the Compare and Write testcast
in the scsi testsuite still fails..
--
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
On Fri, 2015-03-27 at 00:26 -0700, K. Y. Srinivasan wrote:
This patch-set addresses perf issues discovered on the Azure storage stack.
These patches also fix a couple of bugs.
As in the first version of this patch-set, some of the patches are simply a
resend.
I have bumped up the version
On Wed, Apr 08, 2015 at 03:27:37PM +0300, Dan Carpenter wrote:
On Wed, Apr 08, 2015 at 05:20:10PM +0530, Sudip Mukherjee wrote:
On Wed, Apr 08, 2015 at 02:38:32PM +0300, Dan Carpenter wrote:
1) We can't apply this patch on its own so this way of breaking up the
patches doesn't work.
This is a regression somewhere between 3.15 and 3.19.3. Let me know
if more diagnostics would be helpful.
[58635.050733] BUG: using smp_processor_id() in preemptible []
code: apt-check/13293
[58635.059861] caller is debug_smp_processor_id+0x17/0x20
[58635.059863] CPU: 0 PID: 13293 Comm:
[ Sending again with a trimmed CC list to just the lists. Jeff - cc
lists that large get blocked by mailing lists... ]
On Tue, Apr 07, 2015 at 02:55:13PM -0400, Jeff Moyer wrote:
The way the on-stack plugging currently works, each nesting level
flushes its own list of I/Os. This can be less
39 matches
Mail list logo
