On 5/31/19 11:34 AM, John Pittman wrote:
> Hi Jens. Does this patch seem reasonable?
Looks good to me, applied.
--
Jens Axboe
Hi Jens. Does this patch seem reasonable?
On Fri, May 24, 2019 at 12:51 PM Chaitanya Kulkarni
wrote:
>
> Let's leave it to Jens.
>
> On 5/24/19 5:19 AM, John Pittman wrote:
> > Thanks Chaitanya for the review. I was not sure what Jens would think
> > about the checkpatch warning, so I left it a
Let's leave it to Jens.
On 5/24/19 5:19 AM, John Pittman wrote:
> Thanks Chaitanya for the review. I was not sure what Jens would think
> about the checkpatch warning, so I left it as it was so he could
> decide. I tried to model the value output after that old 'bio too
> big' error. Thanks aga
Thanks Chaitanya for the review. I was not sure what Jens would think
about the checkpatch warning, so I left it as it was so he could
decide. I tried to model the value output after that old 'bio too
big' error. Thanks again.
On Thu, May 23, 2019 at 9:17 PM Chaitanya Kulkarni
wrote:
>
> I thi
Hi Ming; thanks for reviewing. I've not seen anything in 5.x.
Currently, we have a RHEL case for kernel 3.x where we've hit this
error, but we've yet to identify root cause. As part of debugging,
the techs involved are having to grab the values via systemtap (which
the end-user is resisting). Pl
On Fri, May 24, 2019 at 5:50 AM John Pittman wrote:
>
> While troubleshooting issues where cloned request limits have been
> exceeded, it is often beneficial to know the actual values that
> have been breached. Print these values, assisting in ease of
> identification of root cause of the breach.
I think it will be useful to print the information along with the error.
Do we want to address the checkpatch warnings ?
WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then
dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
#20: FILE: block/blk-core.c:1202:
+
While troubleshooting issues where cloned request limits have been
exceeded, it is often beneficial to know the actual values that
have been breached. Print these values, assisting in ease of
identification of root cause of the breach.
Signed-off-by: John Pittman
---
block/blk-core.c | 7 +-
