On 15/02/2022 05:29, Martin K. Petersen wrote:
>
> 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 tried KERN_DEBUG but it did not help, but we also do not want to produce
large numbers of unnecessary messages.
>
> 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.
It can happen after runtime PM when a LUN is accessed, so a flag set by
the driver seems better. Please see V3.
>
>> 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) {
>
