On Tue, Jan 28, 2014 at 12:58:36PM +0100, Hannes Reinecke wrote:
> I actually know of a customer using this (with a semi-proprietary
> target mode driver). I'll be asking him what his plans are.
They are using the IBM pseries vscsi driver for that? It they actually
adding out of tree kernel code
On 01/30/2014 09:44 AM, Christoph Hellwig wrote:
> On Tue, Jan 28, 2014 at 12:58:36PM +0100, Hannes Reinecke wrote:
>> I actually know of a customer using this (with a semi-proprietary
>> target mode driver). I'll be asking him what his plans are.
>
> They are using the IBM pseries vscsi driver fo
On Wed, Jan 29, 2014 at 09:52:46PM -0700, Matthew Wilcox wrote:
> On Fri, Jan 24, 2014 at 10:57:48AM +, Mel Gorman wrote:
> > So far on the table is
> >
> > 1. major filesystem overhawl
> > 2. major vm overhawl
> > 3. use compound pages as they are today and hope it does not go
> >complete
On Wed, Jan 29, 2014 at 02:26:52PM +0100, Alexander Gordeev wrote:
> > Do you want me to rediff your patches on top of this one,
> > or do you want to keep the entire MSI series together
> > and do the rediff? Otherwise the patches seem fine.
>
> I would prefer the former.
Hi Brian,
I am sending
There is no need to call pci_disable_msi() or pci_disable_msix()
in case the call to pci_enable_msi() or pci_enable_msix() failed.
Signed-off-by: Alexander Gordeev
---
drivers/scsi/ipr.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/i
As result deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev
---
drivers/scsi/ipr.c |
Coverity reports that the test of req_data_len vs. rsp_data_len is dead code.
This appears to be because the test occurs before any real assignment to
either variable.
Assuming that the sole in-tree execution path (QL_VND_DIAG_IO_CMD submitted
via FC pass-through on a host /dev/bsg/X) does not req
srp_iu_pool_alloc implements what seems like a standard "common exit path with
gotos"
but there's only one way to reach it. Additionally the kfree(q->items) is
unreachable.
fold the error path back into the if.
Signed-off-by: Dave Jones
diff --git a/drivers/scsi/libsrp.c b/drivers/scsi/libsrp
Hi Linus!
Here are the target-pending updates for the v3.14-rc1 merge window.
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next
The highlights this round include:
- Add support for SCSI Referrals (Hannes)
- Add support for T10 DIF into target
On 06/25/13 18:13, Michael Christie wrote:
> On Jun 25, 2013, at 10:31 AM, Bart Van Assche wrote:
>> On 06/25/13 15:45, James Bottomley wrote:
>>> On Tue, 2013-06-25 at 11:01 +0200, Bart Van Assche wrote:
There is a difference though between moving the EH kthread_stop() call
and the patc
Hi Tejun,
As it had being awhile, any issue with this version of the SATA
drivers before I post the follow on errata patches?
-Loc
On Thu, Jan 16, 2014 at 8:11 AM, Loc Ho wrote:
> This patch adds support for the APM X-Gene SoC SATA host controller. In
> order for the host controller to work, th
When running the LVM2 testsuite on 32-bit kernel, there are unkillable
processes stuck in the kernel consuming 100% CPU:
blkid R running 0 2005 1409 0x0004
ce009d00 0082 ffcf c11280ba 0060 560b5dfd 3111 00fe41cb
ce009d00 d51cfeb0
On Thu, 2014-01-30 at 15:40 -0500, Mikulas Patocka wrote:
> When running the LVM2 testsuite on 32-bit kernel, there are unkillable
> processes stuck in the kernel consuming 100% CPU:
> blkid R running 0 2005 1409 0x0004
> ce009d00 0082 ffcf c11280ba 0060 560b5dfd 0
On Thu, 30 Jan 2014, James Bottomley wrote:
> Why is this? the whole reason for CONFIG_LBDAF is supposed to be to
> allow 64 bit offsets for block devices on 32 bit. It sounds like
> there's somewhere not using sector_t ... or using it wrongly which needs
> fixing.
The page cache uses unsigne
On Thu, 2014-01-30 at 18:10 -0500, Mikulas Patocka wrote:
>
> On Thu, 30 Jan 2014, James Bottomley wrote:
>
> > Why is this? the whole reason for CONFIG_LBDAF is supposed to be to
> > allow 64 bit offsets for block devices on 32 bit. It sounds like
> > there's somewhere not using sector_t ... o
On Thu, 30 Jan 2014, James Bottomley wrote:
> On Thu, 2014-01-30 at 18:10 -0500, Mikulas Patocka wrote:
> >
> > On Thu, 30 Jan 2014, James Bottomley wrote:
> >
> > > Why is this? the whole reason for CONFIG_LBDAF is supposed to be to
> > > allow 64 bit offsets for block devices on 32 bit. It
On Thu, 2014-01-30 at 19:20 -0500, Mikulas Patocka wrote:
>
> On Thu, 30 Jan 2014, James Bottomley wrote:
>
> > On Thu, 2014-01-30 at 18:10 -0500, Mikulas Patocka wrote:
> > >
> > > On Thu, 30 Jan 2014, James Bottomley wrote:
> > >
> > > > Why is this? the whole reason for CONFIG_LBDAF is supp
On Thu, 30 Jan 2014, James Bottomley wrote:
> > A device may be accessed direcly (by opening /dev/sdX) and it creates a
> > mapping too - thus, the size of a mapping limits the size of a block
> > device.
>
> Right, that's what I suspected below. We can't damage large block
> support on file
On Thu, 2014-01-30 at 21:43 -0500, Mikulas Patocka wrote:
>
> On Thu, 30 Jan 2014, James Bottomley wrote:
>
> > > A device may be accessed direcly (by opening /dev/sdX) and it creates a
> > > mapping too - thus, the size of a mapping limits the size of a block
> > > device.
> >
> > Right, that
On Thu, 2014-01-30 at 20:46 +0100, Bart Van Assche wrote:
> On 06/25/13 18:13, Michael Christie wrote:
> > On Jun 25, 2013, at 10:31 AM, Bart Van Assche wrote:
> >> On 06/25/13 15:45, James Bottomley wrote:
> >>> On Tue, 2013-06-25 at 11:01 +0200, Bart Van Assche wrote:
> There is a differenc
On 01/31/14 06:58, James Bottomley wrote:
> On Thu, 2014-01-30 at 20:46 +0100, Bart Van Assche wrote:
>> On 06/25/13 18:13, Michael Christie wrote:
>> Sorry but I'm afraid that making the SCSI core invoke a callback
>> function from a device, target or host release function would create a
>> new ch
21 matches
Mail list logo
