When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id()
may return a node without memory, and later cause system failure/panic
when calling kmalloc_node() and friends with returned node id.
So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with
memory for the/curr
When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id()
may return a node without memory, and later cause system failure/panic
when calling kmalloc_node() and friends with returned node id.
So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with
memory for the/curr
When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id()
may return a node without memory, and later cause system failure/panic
when calling kmalloc_node() and friends with returned node id.
So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with
memory for the/curr
On 06/28/2014 08:09 PM, Christoph Hellwig wrote:
On Fri, Jun 27, 2014 at 04:34:35PM +0200, jgr...@suse.com wrote:
From: Juergen Gross
Introduces the XEN pvSCSI backend. With pvSCSI it is possible for a XEN domU
to issue SCSI commands to a SCSI LUN assigned to that domU. The SCSI commands
are p
On Fri, Jul 11, 2014 at 10:57:50AM +0200, Juergen Gross wrote:
> >This should be written against the generic target core infrastructure
> >in drivers/target, instead of introducing another simplistic pass
> >through only SCSI target.
> >.
> >
>
> Just to be sure: you mean something like a combined
On Sun, Jun 29, 2014 at 03:34:31PM +0200, Christoph Hellwig wrote:
> There has been some confusion because scsi_setup_blk_pc_cmnd is used to set
> up various special TYPE_FS commands. I've looked into the area and come
> up with various cleanup, as well as few small bug fixes that were turned
> up
On Mon, Jun 30, 2014 at 04:31:33AM +0930, Arthur Marsh wrote:
> Hi, I haven't had time to do a git bisect yet, but just saw this after
> rebuilding the kernel in the last day or so:
It seems like some of the routines called during the driver
initialization may sleep while the driver_lock is held a
Hi,
On 07/10/2014 01:31 AM, Jonathan wrote:
> Hans,
>
> Thanks for getting back to me. It looks like the USB 3.0 controller is an
> Etron.
Etron, that is the first time I've heard of them. So that is the 5th
manufacturer
which is making xhci controllers now (the others are nec, intel, via and
On 07/11/2014 12:26 AM, KY Srinivasan wrote:
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Thursday, July 10, 2014 3:13 AM
To: KY Srinivasan
Cc: Christoph Hellwig; linux-ker...@vger.kernel.org;
de...@linuxdriverproject.org; oher...@suse.com;
jbottom...@pa
On Fri, Jul 11, 2014 at 11:52:55AM +0200, Hannes Reinecke wrote:
> Something like this should be sufficient:
Right. That plus a detailed comment explaining why it's there..
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.o
On Wed, Jul 09, 2014 at 03:17:56PM -0700, Adam Radford wrote:
> The following patch for megaraid_sas fixes the LD/VF affiliation policy
> parsing
> code to account for LD targetId's and Hidden LD's (not yet affiliated with any
> Virtual Functions). This also breaks megasas_get_ld_vf_affiliation()
On Wed, Jul 09, 2014 at 03:17:57PM -0700, Adam Radford wrote:
> The following patch for megaraid_sas adds a missing initial call to
> megasas_get_ld_vf_affiliation() at the end of megasas_probe_one().
>
> Signed-off-by: Adam Radford
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe
Hi Christoph,
On Fri, Jul 11, 2014 at 3:23 AM, Christoph Hellwig wrote:
> Thanks Fabio,
>
> this looks good to me. Are there any other warnings you got from that
> autobuilder?
Yes, the build results for various ARM defconfigs are available at:
http://lists.linaro.org/pipermail/kernel-build-rep
On 06/29/2014 03:34 PM, Christoph Hellwig wrote:
scsi_init_io should only be called for requests that transfer data,
so move the assert that a request has segments from the callers into
scsi_init_io.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi_lib.c | 16 +---
1 file
On 06/29/2014 03:34 PM, Christoph Hellwig wrote:
We should call the device handler prep_fn for all TYPE_FS requests,
not just simple read/write calls that are handled by the disk driver.
Restructure the common I/O code to call the prep_fn handler and zero
out the CDB, and just leave the call to
On 06/29/2014 03:34 PM, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi_lib.c | 14 +++---
drivers/scsi/sd.c |2 --
drivers/scsi/sr.c |2 --
3 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c
On 06/29/2014 03:34 PM, Christoph Hellwig wrote:
Simplify handling of flush requests by setting up the command directly
instead of initializing request fields and then calling
scsi_setup_blk_pc_cmnd to propagate the information into the command.
Also rename scsi_setup_flush_cmnd to sd_setup_flus
On 06/29/2014 03:34 PM, Christoph Hellwig wrote:
Simplify handling of write same requests by setting up the command directly
instead of initializing request fields and then calling
scsi_setup_blk_pc_cmnd to propagate the information into the command.
Signed-off-by: Christoph Hellwig
---
drive
On 06/29/2014 03:34 PM, Christoph Hellwig wrote:
Simplify handling of discard requests by setting up the command directly
instead of initializing request fields and then calling
scsi_setup_blk_pc_cmnd to propagate the information into the command.
Signed-off-by: Christoph Hellwig
---
drivers/
On 06/29/2014 03:34 PM, Christoph Hellwig wrote:
Currently cmd->allowed is initialized from rq->retries for write same
commands, but retries is always 0 for non-BLOCK_PC requests. Set it
to the standard number of retries instead.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sd.c |2
On 06/29/2014 03:34 PM, Christoph Hellwig wrote:
Currently cmd->allowed is initialized from rq->retries for discard
commands, but retries is always 0 for non-BLOCK_PC requests. Set it
to the standard number of retries instead.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sd.c |2 +-
On 06/29/2014 03:34 PM, Christoph Hellwig wrote:
Factor out a function to initialize regular read/write commands and leave
sd_init_command as a simple dispatcher to the different prepare routines.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sd.c | 58 ++
On 06/29/2014 03:34 PM, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi_lib.c|3 +--
include/scsi/scsi_driver.h |2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index ea23860..f0
> "hch" == hch@infradead org writes:
(Back from vacation: Bear with me while I'm catching up on two weeks of
linux-scsi stuff...)
hch> I think the problem is a differnet one. If we have the logical
hch> provisioning EVPD it configures what method to use, but if we don't
hch> have one we sim
> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Friday, 11 July, 2014 1:15 AM
> To: Elliott, Robert (Server Storage)
> Cc: Jeff Moyer; Christoph Hellwig; Jens Axboe; dgilb...@interlog.com; James
> Bottomley; Bart Van Assche; Benjamin LaHaise; linux-scsi@
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Friday, July 11, 2014 2:53 AM
> To: KY Srinivasan; Christoph Hellwig
> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> oher...@suse.com; jbottom...@parallels.com; jasow...@redhat.com;
> a...@canon
On Fri, Jul 11, 2014 at 02:33:12PM +, Elliott, Robert (Server Storage)
wrote:
> That ran 9 total hours with no problem.
>
> Rather than revert in the bisect trees, I added just this single additional
> patch to the no-rebase tree, and the problem appeared:
Can you try the below totally untes
>> -rq->__data_len = sdp->sector_size;
>> +rq->__data_len = sdp->sector_size;
>> +ret = scsi_init_io(cmd, GFP_ATOMIC);
>> +rq->__data_len = nr_bytes;
>> return ret;
>> }
>>
> Hmm? __data_len is the amount of data written _on the target_.
> Do we actually care about it?
> And
On Fri, Jul 11, 2014 at 02:26:24PM +0200, Hannes Reinecke wrote:
>> blk_add_request_payload(rq, page, len);
>> -ret = scsi_setup_blk_pc_cmnd(sdp, rq);
>> +
>> +cmd->transfersize = len;
>> +cmd->allowed = rq->retries;
>> +
>> +ret = scsi_init_io(cmd, GFP_ATOMIC);
>> rq->__d
From: Andi Kleen
These data structures are accessed by different CPUs and have some
fields which are mostly read only and others which are frequently
written. Separate some common ones into separate cache line
to minimize false sharing while submitting a command.
This allows scsi_dispatch_cmd to
> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Thursday, July 10, 2014 3:19 AM
> To: KY Srinivasan
> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> oher...@suse.com; jbottom...@parallels.com; jasow...@redhat.com;
> a...@canonical.com;
Hans,
Sure enough, the enclosure worked flawlessly with uas on a machine with an
Intel xhci controller (2012 MacBook Air running Linux with kernel 3.15.3). I
look forward to learning your results with the Etron controller.
Best,
Jonathan
On Fri, 11 Jul 2014 11:36:28 +0200
Hans de Goede wrot
> -Original Message-
> From: h...@infradead.org [mailto:h...@infradead.org]
> Sent: Thursday, July 10, 2014 11:32 PM
> To: James Bottomley
> Cc: KY Srinivasan; linux-ker...@vger.kernel.org; m...@mkp.net;
> h...@infradead.org; de...@linuxdriverproject.org; a...@canonical.com;
> sta...@vger
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Friday, July 11, 2014 5:54 AM
> To: h...@infradead.org
> Cc: James Bottomley; KY Srinivasan; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; a...@canonical.com; sta...@vger.kernel.org
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Joe Lawrence
...
> In your crash stack trace, the scsi error handler has issued a host
> reset, but then crashed in mpt2sas_base_get_iocstate. Reading through
> _scsih_
Christoph Hellwig wrote, on 11/07/14 18:50:
On Mon, Jun 30, 2014 at 04:31:33AM +0930, Arthur Marsh wrote:
Hi, I haven't had time to do a git bisect yet, but just saw this after
rebuilding the kernel in the last day or so:
It seems like some of the routines called during the driver
initializa
36 matches
Mail list logo
