On Tue, Jan 24, 2017 at 02:25:39PM +0100, Hannes Reinecke wrote:
> On 01/23/2017 07:59 PM, Omar Sandoval wrote:
> > From: Omar Sandoval <osandov@xxxxxx>
> >
> > hctx->state could come in handy for bugs where the hardware queue gets
> > stuck in the stopped state, and hctx->flags is just useful to know.
> >
> > Signed-off-by: Omar Sandoval <osandov@xxxxxx>
> > ---
> > block/blk-mq-debugfs.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 42 insertions(+)
> >
> Hehe. I've found myself adding exactly the same attributes when
> debugging mq-deadline :-)
>
> > diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
> > index 01711bbf5ade..0c14511fa9e0 100644
> > --- a/block/blk-mq-debugfs.c
> > +++ b/block/blk-mq-debugfs.c
> > @@ -29,7 +29,49 @@ struct blk_mq_debugfs_attr {
> >
> > static struct dentry *block_debugfs_root;
> >
> > +static int hctx_state_show(struct seq_file *m, void *v)
> > +{
> > + struct blk_mq_hw_ctx *hctx = m->private;
> > +
> > + seq_printf(m, "0x%lx\n", hctx->state);
> > + return 0;
> > +}
> > +
> What about decoding it?
> Would make life so much easier, and one doesn't have to have a kernel
> source tree available when looking things up...
I thought of this, too, but doing that would require setting up a
mapping from flag values to strings and keeping those in sync with the
actual flags, which I don't think is worth the trouble, since I imagine
that most of the time you're going to be consulting the source to debug
this kind of issue, anyways.
Thanks for the review!
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
