Adrian,
> Kernel messages produced during runtime PM can cause a never-ending
> cycle because user space utilities (e.g. journald or rsyslog) write the
> messages back to storage, causing runtime resume, more messages, and so
> on.
>
> Messages that tell of things that are expected to happen, are arguably
> unnecessary, so suppress them.
I don't have a major objection to the sd_suspend changes although I
wonder if there is a log level configuration problem with these systems?
Would KERN_INFO instead of KERN_NOTICE help?
I do not like the report sense change. We see this message all the time
in the field and it is very useful for debugging problems. So that
message should be made conditional based on PM state.
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 60a6ae9d1219..e177dc5cc69a 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -484,8 +484,14 @@ static void scsi_report_sense(struct scsi_device *sdev,
>
> if (sshdr->asc == 0x29) {
> evt_type = SDEV_EVT_POWER_ON_RESET_OCCURRED;
> - sdev_printk(KERN_WARNING, sdev,
> - "Power-on or device reset occurred\n");
> + /*
> + * Do not print a message here because reset can be an
> + * expected side-effect of runtime PM. Do not print
> + * messages due to runtime PM to avoid never-ending
> + * cycles of messages written back to storage by user
> + * space causing runtime resume, causing more messages
> + * and so on.
> + */
> }
>
> if (sshdr->asc == 0x2a && sshdr->ascq == 0x01) {
--
Martin K. Petersen Oracle Linux Engineering
