linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: "Elliott, Robert (Server Storage)" <Elliott@hp.com>,
	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"yrl.pp-manager.tt@hitachi.com" <yrl.pp-manager.tt@hitachi.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"James E.J. Bottomley" <JBottomley@parallels.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Doug Gilbert <dgilbert@interlog.com>,
	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace
Date: Tue, 26 Aug 2014 10:53:32 +0200	[thread overview]
Message-ID: <53FC4B0C.8040604@suse.de> (raw)
In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B402958C1A9E5@G9W0745.americas.hpqcorp.net>

On 08/22/2014 02:39 AM, Elliott, Robert (Server Storage) wrote:
>> -----Original Message-----
>> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
>> owner@vger.kernel.org] On Behalf Of Yoshihiro YUNOMAE
>> Sent: Friday, 08 August, 2014 6:50 AM
>> Subject: [RFC PATCH -logging 00/10] scsi/constants: Output continuous
>> error messages on trace
> ...
>> 1) printk
>> Keeps current implemntation of upstream kernel.
>> The messages are divided and can be mixed, but all users can
>> check the error messages without any settings.
>
> scsi_io_completion ignore the scsi_logging_level and always calls
> printk if it detects ACTION_FAIL, resulting in messages like:
>
>      [10240.338600] sd 2:0:0:0: [sdr]
>      [10240.339722] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
>      [10240.341662] sd 2:0:0:0: [sdr]
>      [10240.342792] Sense Key : Hardware Error [current]
>      [10240.344575] sd 2:0:0:0: [sdr]
>      [10240.345653] Add. Sense: Logical unit failure
>      [10240.347138] sd 2:0:0:0: [sdr] CDB:
>      [10240.348309] Read(10): 28 00 00 00 00 80 00 00 08 00
>
> If you trigger hundreds of errors (e.g., hot remove a device
> during heavy IO), then all the prints to the linux serial console
> bog down the system, causing timeouts in commands to other
> devices and soft lockups for applications.
>
> Some changes that would help are:
> 1. Put them under SCSI logging level control
> 2. Use printk_ratelimited so an excessive number are trimmed
>
> Would you like to include something like this in your
> patch set?
>
> This is an example patch that only prints them if the MLCOMPLETE
> logging level is nonzero.
> Off: scsi_logging_level --set --mlcomplete=0
> On: scsi_logging_level --set --mlcomplete=1
>
> Some other loglevel (e.g., ERROR_RECOVERY) could be used.
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index d6b4ea8..dbb601f 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1037,7 +1037,9 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
>   	switch (action) {
>   	case ACTION_FAIL:
>   		/* Give up and fail the remainder of the request */
> -		if (!(req->cmd_flags & REQ_QUIET)) {
> +		if (!(req->cmd_flags & REQ_QUIET) &&
> +		    SCSI_LOG_LEVEL(SCSI_LOG_MLCOMPLETE_SHIFT,
> +		    SCSI_LOG_MLCOMPLETE_BITS)) {
>   			scsi_print_result(cmd);
>   			if (driver_byte(result) & DRIVER_SENSE)
>   				scsi_print_sense("", cmd);
>
> Converting to printk_ratelimited is harder since the prints
> are spread out over three functions (and as your patch
> series notes, many individual printk calls).  The rates
> for the printk calls might not match, which would lead to
> even more confusing output.
>
Good point. Will be including it.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

      parent reply	other threads:[~2014-08-26  8:53 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08 11:50 [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace Yoshihiro YUNOMAE
2014-08-08 11:50 ` [RFC PATCH 01/10] scsi/constants: Cleanup printk message in __scsi_print_sense() Yoshihiro YUNOMAE
2014-08-12 14:51   ` Elliott, Robert (Server Storage)
2014-08-13  3:14     ` Yoshihiro YUNOMAE
2014-08-27 13:56   ` Hannes Reinecke
2014-08-08 11:50 ` [RFC PATCH 02/10] scsi/constants: Cleanup printk message in scsi_decode_sense_extras() Yoshihiro YUNOMAE
2014-08-27 13:58   ` Hannes Reinecke
2014-08-08 11:50 ` [RFC PATCH 03/10] scsi/constants: Cleanup printk message in __scsi_print_command() Yoshihiro YUNOMAE
2014-08-15 15:05   ` Ewan Milne
2014-08-18  5:05     ` Yoshihiro YUNOMAE
2014-08-27 13:58   ` Hannes Reinecke
2014-08-08 11:50 ` [RFC PATCH 04/10] scsi/constants: Cleanup printk message in scsi_dump_sense_buffer() Yoshihiro YUNOMAE
2014-08-15 15:08   ` Ewan Milne
2014-08-18  5:06     ` Yoshihiro YUNOMAE
2014-08-27 13:59   ` Hannes Reinecke
2014-08-08 11:50 ` [RFC PATCH 05/10] scsi/trace: Use macros for getting driver byte, host byte, msg byte, and status byte Yoshihiro YUNOMAE
2014-08-15 15:10   ` Ewan Milne
2014-08-27 14:01   ` Hannes Reinecke
2014-08-08 11:50 ` [RFC PATCH 06/10] scsi/sd: Delete extra scsi_show_extd_sense() in sd_print_sense_hdr() Yoshihiro YUNOMAE
2014-08-15 15:14   ` Ewan Milne
2014-08-27 14:07   ` Hannes Reinecke
2014-08-08 11:50 ` [RFC PATCH 07/10] scsi/trace: Use scsi_show_result trace point instead of printk Yoshihiro YUNOMAE
2014-08-27 14:12   ` Hannes Reinecke
2014-08-28  1:37     ` Yoshihiro YUNOMAE
2014-08-29  0:50     ` Christoph Hellwig
2014-09-03  1:17       ` Yoshihiro YUNOMAE
2014-08-08 11:50 ` [RFC PATCH 08/10] scsi/trace: Use scsi_print_sense " Yoshihiro YUNOMAE
2014-08-27 14:15   ` Hannes Reinecke
2014-08-28  1:39     ` Yoshihiro YUNOMAE
2014-08-08 11:50 ` [RFC PATCH 09/10] scsi/trace: Add additional sense code and additional sense code qualifier to scsi_print_sense trace point Yoshihiro YUNOMAE
2014-08-27 14:16   ` Hannes Reinecke
2014-08-28  1:39     ` Yoshihiro YUNOMAE
2014-08-08 11:50 ` [RFC PATCH 10/10] scsi/trace: Use scsi_print_command trace point instead of printk Yoshihiro YUNOMAE
2014-08-27 14:16   ` Hannes Reinecke
2014-08-28  1:40     ` Yoshihiro YUNOMAE
2014-08-28  6:19       ` Yoshihiro YUNOMAE
2014-08-28 12:15         ` Hannes Reinecke
2014-09-01  6:38           ` Yoshihiro YUNOMAE
2014-08-08 13:07 ` [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace Douglas Gilbert
2014-08-13  3:13   ` Yoshihiro YUNOMAE
2014-08-22 19:54     ` Douglas Gilbert
2014-08-26 14:23       ` Hannes Reinecke
2014-08-27 14:23   ` Hannes Reinecke
2014-08-27 14:48     ` Douglas Gilbert
2014-08-22  0:39 ` Elliott, Robert (Server Storage)
2014-08-24 20:44   ` scsi logging future directions, was " Christoph Hellwig
2014-08-25 11:30     ` Hannes Reinecke
2014-08-26  8:53   ` Hannes Reinecke [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53FC4B0C.8040604@suse.de \
    --to=hare@suse.de \
    --cc=Elliott@hp.com \
    --cc=JBottomley@parallels.com \
    --cc=dgilbert@interlog.com \
    --cc=hch@lst.de \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=yoshihiro.yunomae.ez@hitachi.com \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).