build is giving :
warning: passing argument 1 of 'strlen' makes pointer from integer
without a cast [enabled by default]
the snprintf after the strlen is trying to put the "Unsupported" string
at the end of exising string. so len should give the string length here
Signed-off-by: Sudip Mukherjee
tifier_type);
> ret = -EINVAL;
> --
> 1.8.1.2
>
please discard this patch. This is based on next-20140908 , and the
issue has been corrected in next-20140909.
thanks
sudip
--
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
Hi All,
While working on making error handling in the uas driver more robust,
I noticed that all the commands being send to a sata ssd hooked up
over uas were untagged, where I would expect tcq to be used, as that
is the big advantage of uas over usb-storage / bot.
Taking the uas.c file from 3.17
Hi,
As recent discussion, especially suggested by Christoph, this patchset
implements per-distpatch_queue flush machinery, so that:
- current init_request and exit_request callbacks can
cover flush request too, then the ugly and buggy copying
way of initializing flush requ
This patch supports to run one single lush machinery for
each blk-mq dispatch queue, so that:
- current init_request and exit_request callbacks can
cover flush request too, then the ugly and buggy way of
initializing flush request's pdu can be fixed
- flushing performance gets improved in case of
This patch adds 'blk_mq_ctx' parameter to blk_get_flush_queue(),
so that this function can find the corresponding blk_flush_queue
bound with current mq context since the flush queue will become
per hw-queue.
For legacy queue, the parameter can be simply 'NULL'.
For multiqueue case, the parameter
This patch trys to use local variable to access flush request,
so that we can convert to per-queue flush machinery a bit easier.
Signed-off-by: Ming Lei
---
block/blk-flush.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/block/blk-flush.c b/block/blk-flu
It is reasonable to allocate flush req in blk_mq_init_flush().
Signed-off-by: Ming Lei
---
block/blk-flush.c | 11 ++-
block/blk-mq.c| 16 ++--
block/blk-mq.h|2 +-
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/block/blk-flush.c b/block/blk-
This patch introduces 'struct blk_flush_queue' and puts all
flush machinery related stuff into this strcuture, so that
- flush implementation details aren't exposed to driver
- it is easy to convert to per dispatch-queue flush machinery
This patch is basically a mechanical replace
Just figuring out flush queue at the entry of kicking off flush
machinery and request's completion handler, then pass it through.
Signed-off-by: Ming Lei
---
block/blk-flush.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/block/blk-flush.c
These stuff is always used with flush req together, so
we can do that safely.
Signed-off-by: Ming Lei
---
block/blk-core.c |3 ---
block/blk-flush.c |4
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 0a9d172..222fe84 100644
These two functions are introduced to initialize and de-initialize
flush stuff centrally.
Signed-off-by: Ming Lei
---
block/blk-core.c |5 ++---
block/blk-flush.c | 19 ++-
block/blk-mq.c|2 +-
block/blk-mq.h|1 -
block/blk-sysfs.c |4 ++--
block/blk.h
On 09/06/2014 03:25 PM, sumit.sax...@avagotech.com wrote:
> Use writeq() for 64bit PCI write instead of writel() to avoid additional lock
> overhead.
>
> Signed-off-by: Sumit Saxena
> Signed-off-by: Kashyap Desai
> ---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 8
> 1 file changed
On 09/06/2014 03:25 PM, sumit.sax...@avagotech.com wrote:
> Current driver updates reply post host index to let firmware know that
> replies are processed,
> while returning from ISR function, only if there is no oustanding replies in
> reply queue.
>
> Driver will free the request frame immediat
asm1051e usb <-> sata bridges hang when receiving a report opcodes scsi cmnd.
Take a page out of the usb-storage book, and simple disable no_report_opcodes
outright.
Cc: sta...@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 2 ++
1 file changed, 2 insertions(
Even with REPORT SUPPORTED OPERATION CODES blacklisted the ASM1051 chipset
still does not work when combined with some disks, e.g. a Crucial M500 ssd.
When used with a troublesome disk, the chipset throws all kinds of USB errors,
and eventually hangs, where as in BOT mode it works fine.
To make m
Hi Greg,
I've received a number of bug-reports from users related to uas on ASM1051
chipset using devices. After some searching around I've managed to get myself
an ASM1051 device.
As a result I've spend the last 4 days trying to get the ASM1051 chipset to
work. After some initial success which m
On Tue, 9 Sep 2014, Tejun Heo wrote:
> Hello,
>
> On Mon, Sep 08, 2014 at 01:42:44PM -0400, Alan Stern wrote:
> > > This looks like a nasty hack. In theory the QUEUE_FLAG_INIT_DONE should
> > > be unset on blk_unregister_queue() to match the teardown; it's only
> > > accident it isn't. del_gend
Hello, Alan.
On Tue, Sep 09, 2014 at 11:08:22AM -0400, Alan Stern wrote:
> Sorry, the meaning wasn't clear. I meant that the existing code
> doesn't work. The patch seems to work okay (except that I can't use
> queue_flag_test_and_set because the queue isn't locked at that point).
> I'll sub
Hi Ming,
thanks for doing this work!
I've only taken a very cursory look at the series and I like most of it.
But can you explain why you're not simply incrementing the number of
allocated requests in the blk-mq request allocation code instead of
allocating the flush request separately in the la
On Tue, 9 Sep 2014, Hans de Goede wrote:
> Even with REPORT SUPPORTED OPERATION CODES blacklisted the ASM1051 chipset
> still does not work when combined with some disks, e.g. a Crucial M500 ssd.
>
> When used with a troublesome disk, the chipset throws all kinds of USB errors,
> and eventually h
On Tue, Sep 09, 2014 at 11:15:24AM +0200, Hans de Goede wrote:
> Taking the uas.c file from 3.17, and building it for 3.16 restores
> the use of tcq (debugged by adding a printk blk_rq_tagged + request->tag).
>
> So either uas is doing something wrong which happened to work in
> 3.16, or something
On Mon, Sep 08, 2014 at 04:31:01PM -0400, Douglas Gilbert wrote:
> stop_all_queued() is doing hrtimer_cancel(), del_timer_sync()
> or tasklet_kill() on all the scsi_cmnd objects that are
> "in play". Unless another mechanism calls the .eh_abort_handler
> entry point reliably on each "in play" comma
On Tue, Sep 9, 2014 at 11:20 PM, Christoph Hellwig wrote:
> Hi Ming,
>
> thanks for doing this work!
>
> I've only taken a very cursory look at the series and I like most of it.
>
> But can you explain why you're not simply incrementing the number of
> allocated requests in the blk-mq request allo
When a queue is registered, the block layer turns off the bypass
setting (because bypass is enabled when the queue is created). This
doesn't work well for queues that are unregistered and then registered
again; we get a WARNING because of the unbalanced calls to
blk_queue_bypass_end().
This patch
On 09/06/2014 03:25 PM, sumit.sax...@avagotech.com wrote:
> This feature will provide similar interface as kernel crash dump feature.
> When megaraid firmware encounter any crash, driver will collect the firmware
> raw image and
> dump it into pre-configured location.
>
> Driver will allocate two
On Tue, Sep 09, 2014 at 04:59:59PM +0200, Hans de Goede wrote:
> asm1051e usb <-> sata bridges hang when receiving a report opcodes scsi cmnd.
> Take a page out of the usb-storage book, and simple disable no_report_opcodes
> outright.
Given that this device also seems broken in other ways can we w
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Tomas Henzl
> Sent: Tuesday, 09 September, 2014 10:54 AM
> Subject: Re: [PATCH 04/11] megaraid_sas : Firmware crash dump feature
> support
>
> On 09/06/2014 03:25 PM, s
Ching,
do you have a chance to address Thomas second concern below? As
far as I can tell (Thomas, please correct me) that's the last
outstanding concern, and I'd really like to merge the arcmsr updates
for the Linux 3.18 merge window.
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, Sep 09, 2014 at 11:50:58AM -0400, Alan Stern wrote:
> When a queue is registered, the block layer turns off the bypass
> setting (because bypass is enabled when the queue is created). This
> doesn't work well for queues that are unregistered and then registered
> again; we get a WARNING be
Tested-by: Shirish Pargaonkar
On Tue, Sep 9, 2014 at 10:50 AM, Alan Stern wrote:
> When a queue is registered, the block layer turns off the bypass
> setting (because bypass is enabled when the queue is created). This
> doesn't work well for queues that are unregistered and then registered
> ag
On Tue, Sep 09, 2014 at 09:05:42PM +0800, Ming Lei wrote:
> It is reasonable to allocate flush req in blk_mq_init_flush().
>
> Signed-off-by: Ming Lei
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to
On Tue, Sep 09, 2014 at 09:05:43PM +0800, Ming Lei wrote:
> These two functions are introduced to initialize and de-initialize
> flush stuff centrally.
>
> Signed-off-by: Ming Lei
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi
On Tue, Sep 09, 2014 at 09:05:44PM +0800, Ming Lei wrote:
> These stuff is always used with flush req together, so
> we can do that safely.
Little wording nitpick:
in the subject s/initialized stuff/initialization/
and in the body:
These fields are always used with the flush request, so initial
On Tue, Sep 09, 2014 at 09:05:45PM +0800, Ming Lei wrote:
> This patch trys to use local variable to access flush request,
> so that we can convert to per-queue flush machinery a bit easier.
>
> Signed-off-by: Ming Lei
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list
Looks good,
Reviewed-by: Christoph Hellwig
--
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 Tue, Sep 09, 2014 at 09:05:46PM +0800, Ming Lei wrote:
> This patch introduces 'struct blk_flush_queue' and puts all
> flush machinery related stuff into this strcuture, so that
s/stuff/fields/
s/strcuture/structure/
Looks good, but a few more nitpicks below.
Reviewed-by: Christoph Hellwig
> + if (hctx) {
> + int cmd_sz = q->tag_set->cmd_size;
> + int node = hctx->numa_node;
> +
> + fq = kzalloc_node(sizeof(*fq), GFP_KERNEL, node);
> + if (!fq)
> + goto failed;
> +
> + rq_sz = round_up(rq_sz + cmd_sz,
On 09/09/2014 12:43 PM, Christoph Hellwig wrote:
> On Tue, Sep 09, 2014 at 09:05:46PM +0800, Ming Lei wrote:
>> This patch introduces 'struct blk_flush_queue' and puts all
>> flush machinery related stuff into this strcuture, so that
>
> s/stuff/fields/
> s/strcuture/structure/
>
> Looks good, bu
Hi,
On 09/09/2014 05:23 PM, Alan Stern wrote:
On Tue, 9 Sep 2014, Hans de Goede wrote:
Even with REPORT SUPPORTED OPERATION CODES blacklisted the ASM1051 chipset
still does not work when combined with some disks, e.g. a Crucial M500 ssd.
When used with a troublesome disk, the chipset throws a
On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
wrote:
> On Tue, 2014-09-09 at 10:10 +0900, Tejun Heo wrote:
>> Hello, Luis.
>>
>> On Mon, Sep 08, 2014 at 06:04:23PM -0700, Luis R. Rodriguez wrote:
>> > > I have no idea how the selection should be. It could be per-insmod or
>> > > maybe just a s
Hi,
On 09/09/2014 06:01 PM, Christoph Hellwig wrote:
On Tue, Sep 09, 2014 at 04:59:59PM +0200, Hans de Goede wrote:
asm1051e usb <-> sata bridges hang when receiving a report opcodes scsi cmnd.
Take a page out of the usb-storage book, and simple disable no_report_opcodes
outright.
Given that
On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:
> On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
> wrote:
> > If we want to sort out some sync/async mechanism for probing devices, as
> > an agreement between the init systems and the kernel, that's fine, but
> > its a to-be negotiated
On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley
wrote:
> On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:
>> On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
>> wrote:
>> > If we want to sort out some sync/async mechanism for probing devices, as
>> > an agreement between the init syst
Hey, James.
On Tue, Sep 09, 2014 at 12:35:46PM -0700, James Bottomley wrote:
> I don't have very strong views on this one. However, I've got to say
> from a systems point of view that if the desire is to flag when the
> module is having problems, probing and initializing synchronously in a
> thre
On Tue, 9 Sep 2014, Luis R. Rodriguez wrote:
> By design it seems systemd should not allow worker processes to block
> indefinitely and in fact it currently uses the same timeout for all
> types of worker processes.
And I whole-heartedly believe this is something that fundamentally needs
to be
On Wed, 2014-09-10 at 06:42 +0900, Tejun Heo wrote:
> Hey, James.
>
> On Tue, Sep 09, 2014 at 12:35:46PM -0700, James Bottomley wrote:
> > I don't have very strong views on this one. However, I've got to say
> > from a systems point of view that if the desire is to flag when the
> > module is hav
Hello,
On Tue, Sep 09, 2014 at 03:26:02PM -0700, James Bottomley wrote:
> > We no longer report back error on probe failure on module load.
>
> Yes, we do; for every probe failure of a device on a driver we'll print
> a warning (see drivers/base/dd.c). Now if someone is proposing we
> should rep
On Wed, 2014-09-10 at 07:41 +0900, Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 09, 2014 at 03:26:02PM -0700, James Bottomley wrote:
> > > We no longer report back error on probe failure on module load.
> >
> > Yes, we do; for every probe failure of a device on a driver we'll print
> > a warning (se
Hello, James.
On Tue, Sep 09, 2014 at 03:46:23PM -0700, James Bottomley wrote:
> If you want the return of an individual device probe a log scraper gives
> it to you ... and nothing else does currently. The advantage of the
> prink in dd.c is that it's standard for everything and can be scanned
>
On Tuesday, September 09, 2014 03:46:23 PM James Bottomley wrote:
> On Wed, 2014-09-10 at 07:41 +0900, Tejun Heo wrote:
> >
> > The thing is that we have to have dynamic mechanism to listen for
> > device attachments no matter what and such mechanism has been in place
> > for a long time at this p
On Tue, Sep 09, 2014 at 12:25:29PM +0900, Tejun Heo wrote:
> Hello,
>
> On Mon, Sep 08, 2014 at 08:19:12PM -0700, Luis R. Rodriguez wrote:
> > On the systemd side of things it should enable this sysctl and for
> > older kernels what should it do?
>
> Supposing the change is backported via -stable
On Wed, Sep 10, 2014 at 2:43 AM, Christoph Hellwig wrote:
> On Tue, Sep 09, 2014 at 09:05:46PM +0800, Ming Lei wrote:
>> This patch introduces 'struct blk_flush_queue' and puts all
>> flush machinery related stuff into this strcuture, so that
>
> s/stuff/fields/
> s/strcuture/structure/
>
> Looks
On Wed, Sep 10, 2014 at 2:55 AM, Jens Axboe wrote:
> On 09/09/2014 12:43 PM, Christoph Hellwig wrote:
>> On Tue, Sep 09, 2014 at 09:05:46PM +0800, Ming Lei wrote:
>>> This patch introduces 'struct blk_flush_queue' and puts all
>>> flush machinery related stuff into this strcuture, so that
>>
>> s/
On Wed, Sep 10, 2014 at 2:48 AM, Christoph Hellwig wrote:
>> + if (hctx) {
>> + int cmd_sz = q->tag_set->cmd_size;
>> + int node = hctx->numa_node;
>> +
>> + fq = kzalloc_node(sizeof(*fq), GFP_KERNEL, node);
>> + if (!fq)
>> +
A few days ago I was trying to create a large file
(say 16 GB) of zeros on an ext4 file system:
dd if=/dev/zero bs=64k count=256k of=zero_16g.bin
After about 5 seconds there was a NULL de-reference that
crashed the machine (shown below). This was with a clean
version of lk 3.17-rc4 (from kerne
On Tue, Sep 9, 2014 at 3:26 AM, Luis R. Rodriguez
wrote:
> On Mon, Sep 8, 2014 at 6:22 PM, Tejun Heo wrote:
>> On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote:
>>> I'm not too convinced this is such a difficult problem to figure out.
>>> We already have most of logic in place and the on
On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez
wrote:
> On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley
> wrote:
>> On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:
>>> On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
>>> wrote:
>>> > If we want to sort out some sync/async mechan
On 08/28/2014 02:34 AM, James Smart wrote:
Mike,
Can you confirm - the "nulls" this patch correct are because the
probe_one and error_detect threads are running concurrently, thus
battling ?
If so - this fix looks insufficient and we should rework it.
Yes, it is. My patch is just a workaro
59 matches
Mail list logo
