2016-10-17 17:05:46

by David Singleton

[permalink] [raw]
Subject: [PATCH] sd: assign appropriate log level

From: Shikhar Dogra <[email protected]>

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: [email protected]
Signed-off-by: Shikhar Dogra <[email protected]>
Signed-off-by: David Singleton <[email protected]>
---
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


2016-10-17 17:15:34

by Joe Perches

[permalink] [raw]
Subject: Re: [PATCH] sd: assign appropriate log level

On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote:
> From: Shikhar Dogra <[email protected]>
>
> 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: [email protected]
> Signed-off-by: Shikhar Dogra <[email protected]>
> Signed-off-by: David Singleton <[email protected]>
> ---
> 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;
> }
>

2016-10-17 17:19:29

by James Bottomley

[permalink] [raw]
Subject: Re: [PATCH] sd: assign appropriate log level

On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote:
> From: Shikhar Dogra <[email protected]>
>
> 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: [email protected]
> Signed-off-by: Shikhar Dogra <[email protected]>
> Signed-off-by: David Singleton <[email protected]>
> ---
> 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;
> }

2016-10-17 17:32:43

by Daniel Walker (danielwa)

[permalink] [raw]
Subject: Re: [PATCH] sd: assign appropriate log level

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 <[email protected]>
>>
>> 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