[PATCH] sd: assign appropriate log level

[PATCH] sd: assign appropriate log level

[David Singleton]

From: Shikhar Dogra <shidogra@cisco.com>

Reduce chatter on console for usb hotplug.
KERN_ERR is too high severity for these messages, moving them
to KERN_WARNING

USB devices never have a Caching Mode page, it doesn't make
sense to make it an error when you have tons of USB devices where
the print is useless, and not an error.

For second message, the condition is not an error. The existing
workaround of assuming a write through cache doesn't limit
functionality in any way.

Cc: xe-kernel@external.cisco.com
Signed-off-by: Shikhar Dogra <shidogra@cisco.com>
Signed-off-by: David Singleton <davsingl@cisco.com>
---
 drivers/scsi/sd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 51e5629..ab7bfe3 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2540,7 +2540,7 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char *buffer)
 			}
 		}
 
-		sd_first_printk(KERN_ERR, sdkp, "No Caching mode page found\n");
+		sd_first_printk(KERN_WARNING, sdkp, "No Caching mode page found\n");
 		goto defaults;
 
 	Page_found:
@@ -2594,7 +2594,7 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char *buffer)
 				"Assuming drive cache: write back\n");
 		sdkp->WCE = 1;
 	} else {
-		sd_first_printk(KERN_ERR, sdkp,
+		sd_first_printk(KERN_WARNING, sdkp,
 				"Assuming drive cache: write through\n");
 		sdkp->WCE = 0;
 	}
-- 
2.9.3

Re: [PATCH] sd: assign appropriate log level

[Joe Perches]

On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote:
> From: Shikhar Dogra <shidogra@cisco.com>
> 
> Reduce chatter on console for usb hotplug.
> KERN_ERR is too high severity for these messages, moving them
> to KERN_WARNING

Perhaps KERN_NOTICE is more appropriate.
That's the level for most of these sd_first_printk already.

> USB devices never have a Caching Mode page, it doesn't make
> sense to make it an error when you have tons of USB devices where
> the print is useless, and not an error.
> 
> For second message, the condition is not an error. The existing
> workaround of assuming a write through cache doesn't limit
> functionality in any way.
> 
> Cc: xe-kernel@external.cisco.com
> Signed-off-by: Shikhar Dogra <shidogra@cisco.com>
> Signed-off-by: David Singleton <davsingl@cisco.com>
> ---
>  drivers/scsi/sd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 51e5629..ab7bfe3 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -2540,7 +2540,7 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char *buffer)
>  			}
>  		}
>  
> -		sd_first_printk(KERN_ERR, sdkp, "No Caching mode page found\n");
> +		sd_first_printk(KERN_WARNING, sdkp, "No Caching mode page found\n");
>  		goto defaults;
>  
>  	Page_found:
> @@ -2594,7 +2594,7 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char *buffer)
>  				"Assuming drive cache: write back\n");
>  		sdkp->WCE = 1;
>  	} else {s
> -		sd_first_printk(KERN_ERR, sdkp,
> +		sd_first_printk(KERN_WARNING, sdkp,
>  				"Assuming drive cache: write through\n");
>  		sdkp->WCE = 0;
>  	}
> 

Re: [PATCH] sd: assign appropriate log level

[James Bottomley]

On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote:
> From: Shikhar Dogra <shidogra@cisco.com>
> 
> Reduce chatter on console for usb hotplug.
> KERN_ERR is too high severity for these messages, moving them
> to KERN_WARNING

It's an error because we have several USB to IDE bridges that have
write back cache drives but report nothing to the caching mode page. 
 For them this is a serious error because their data integrity is at
risk.  I'm open to other ways to fix your problem, but downgrading the
message severity because *you* don't have an issue would mask the
problem for others, so it's not really viable.

> USB devices never have a Caching Mode page, it doesn't make
> sense to make it an error when you have tons of USB devices where
> the print is useless, and not an error.
> 
> For second message, the condition is not an error. The existing
> workaround of assuming a write through cache doesn't limit
> functionality in any way.

Yes, it does if the cache is actually write back ...

James


> Cc: xe-kernel@external.cisco.com
> Signed-off-by: Shikhar Dogra <shidogra@cisco.com>
> Signed-off-by: David Singleton <davsingl@cisco.com>
> ---
>  drivers/scsi/sd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 51e5629..ab7bfe3 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -2540,7 +2540,7 @@ sd_read_cache_type(struct scsi_disk *sdkp,
> unsigned char *buffer)
>  			}
>  		}
>  
> -		sd_first_printk(KERN_ERR, sdkp, "No Caching mode
> page found\n");
> +		sd_first_printk(KERN_WARNING, sdkp, "No Caching mode
> page found\n");
>  		goto defaults;
>  
>  	Page_found:
> @@ -2594,7 +2594,7 @@ sd_read_cache_type(struct scsi_disk *sdkp,
> unsigned char *buffer)
>  				"Assuming drive cache: write
> back\n");
>  		sdkp->WCE = 1;
>  	} else {
> -		sd_first_printk(KERN_ERR, sdkp,
> +		sd_first_printk(KERN_WARNING, sdkp,
>  				"Assuming drive cache: write
> through\n");
>  		sdkp->WCE = 0;
>  	}

Re: [PATCH] sd: assign appropriate log level

[Daniel Walker]

On 10/17/2016 10:19 AM, James Bottomley wrote:
> On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote:
>> From: Shikhar Dogra <shidogra@cisco.com>
>>
>> Reduce chatter on console for usb hotplug.
>> KERN_ERR is too high severity for these messages, moving them
>> to KERN_WARNING
> It's an error because we have several USB to IDE bridges that have
> write back cache drives but report nothing to the caching mode page.
>   For them this is a serious error because their data integrity is at
> risk.  I'm open to other ways to fix your problem, but downgrading the
> message severity because *you* don't have an issue would mask the
> problem for others, so it's not really viable.

Is there a way to detect when you have a device of the type where this 
is a serious issue ? This typically happen for USB drives, but seems to 
have no effect on them.


Daniel