Hey guys,
Apologies for missing this earlier. Comments below.
On Tue, 2017-06-13 at 20:47 -0700, Himanshu Madhani wrote:
> Hi Martin, Nic,
>
> This patch series adds support for multiqueue for qla2xxx target mode driver.
>
> This series depends on the seris applied to Martin's scsi/for-next br
From: Nicholas Bellinger
This patch re-introduces part of a long standing login workaround that
was recently dropped by:
commit 1c99de981f30b3e7868b8d20ce5479fa1c0fea46
Author: Nicholas Bellinger
Date: Sun Apr 2 13:36:44 2017 -0700
iscsi-target: Drop work-around for legacy Global
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Friday, July 07, 2017 11:05 AM
> To: Jens Axboe ; Christoph Hellwig
> ; Meelis Roos
> Cc: Linux Kernel list ; linux-
> bl...@vger.kernel.org; Don Brace ; Scott
> Benesh ; Scott Teel
> ; Kevin Barnett
> ; linux-scsi@
On 07/07/2017 02:08 PM, Christoph Hellwig wrote:
On Fri, Jul 07, 2017 at 11:42:38AM -0400, Laurence Oberman wrote:
What happens when hpsa_allow_any=1 with the Smart Array 64xx
It should probe.
But only if it has a HP vendor ID as far as I can tell. We'd
still need to add the compaq ids so
On Fri, Jul 07, 2017 at 11:42:38AM -0400, Laurence Oberman wrote:
> What happens when hpsa_allow_any=1 with the Smart Array 64xx
> It should probe.
But only if it has a HP vendor ID as far as I can tell. We'd
still need to add the compaq ids so that these controllers get
probed. But maybe it's
On 07/07/17 09:56, Johannes Thumshirn wrote:
> SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set
> it to NULL for the old sg_io read/write interface, but must have a length
> bigger than 0. This fixes a regression introduced by commit 28676d869bbb
> ("scsi: sg: check for vali
On 07/06/2017 11:50 PM, Nicholas A. Bellinger wrote:
> Hey MNC & Co,
>
> On Wed, 2017-06-28 at 12:44 -0500, Mike Christie wrote:
>> On 06/28/2017 12:58 AM, Damien Le Moal wrote:
>>> If the user request handler completed the request with a CHECK CONDITION
>>> status, tcmu_handle_completion() copies
On 07/07/2017 05:03 PM, Jens Axboe wrote:
> On 07/07/2017 09:00 AM, Christoph Hellwig wrote:
>> On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote:
Also we're trying to move people away from the cciss driver, can you
check if the hpsa SCSI driver works for you as well?
>>>
>>> I
On 07/07/2017 11:03 AM, Jens Axboe wrote:
On 07/07/2017 09:00 AM, Christoph Hellwig wrote:
On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote:
Also we're trying to move people away from the cciss driver, can you
check if the hpsa SCSI driver works for you as well?
I have older adap
On 07/07/2017 09:00 AM, Christoph Hellwig wrote:
> On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote:
>>> Also we're trying to move people away from the cciss driver, can you
>>> check if the hpsa SCSI driver works for you as well?
>>
>> I have older adapter:
>>
>> Compaq Computer Corpora
On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote:
> > Also we're trying to move people away from the cciss driver, can you
> > check if the hpsa SCSI driver works for you as well?
>
> I have older adapter:
>
> Compaq Computer Corporation Smart Array 64xx [0e11:0046] (rev 01)
>
> That
On 2017-07-07 09:20:02 [-0400], Chad Dupuis wrote:
> What was the question? My observation is that the patch I proposed fixed
> the issue we saw on testing the patch set. With that small change
> (essentially modulo by the number of active CPUs vs. the total number)
> your patch set worked ok.
On Fri, 7 Jul 2017, 9:14am, Sebastian Andrzej Siewior wrote:
> On 2017-06-29 15:57:56 [+0200], Johannes Thumshirn wrote:
> > So here we are again,
> > Tested-by: Johannes Thumshirn
> >
> > FCoE will follow as soon as my setup can speak FCoE again.
>
> So it all looks good, doesn't it? Chad ne
On 2017-06-29 15:57:56 [+0200], Johannes Thumshirn wrote:
> So here we are again,
> Tested-by: Johannes Thumshirn
>
> FCoE will follow as soon as my setup can speak FCoE again.
So it all looks good, doesn't it? Chad never responded to my question
on his patch. I still doubt that it fixes the pro
On Tue, Feb 07, 2017 at 02:27:09PM +0100, walter harms wrote:
>
>
> Am 07.02.2017 14:01, schrieb Dan Carpenter:
> > The problem here is this:
> >
> > sprintf(host_buf, "qedi_ofld%d", qedi->shost->host_no);
> >
> > host_buf is 16 character so we only have 6 characters left for
> > ->host_no.
SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set
it to NULL for the old sg_io read/write interface, but must have a length
bigger than 0. This fixes a regression introduced by commit 28676d869bbb
("scsi: sg: check for valid direction before starting the request")
Signed-off-b
On Thu, Jul 06, 2017 at 02:47:22PM -0400, Douglas Gilbert wrote:
> Can you check your patch with one of the utilities from sg3_utils
> such as sg_inq which will use SG_DXFER_FROM_DEV with the newer
> interface?
Correct, this patch broke sg_inq. I'll send a corrected v2.
> BTW I'm not sure why dxf
17 matches
Mail list logo
