BugLink: http://bugs.launchpad.net/bugs/1319457
Hello,
Please consider including upstream commit b7a77235 in the next v3.13.y release. It was included upstream as of v3.15-rc5. It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1319457 .
commit b7a7723513dc89f83d6df13206df55d4dc26e825
Author: Sander Eikelenboom <[email protected]>
Date: Fri May 2 15:09:27 2014 +0200
ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined
This commit does not apply cleanly to v3.13, so I performed a backport, which is in email 1/1.
Sander Eikelenboom (1):
ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log
while DEBUG not defined
sound/usb/pcm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
1.9.1
From: Sander Eikelenboom <[email protected]>
BugLink: http://bugs.launchpad.net/bugs/1319457
This (widely used) construction:
if(printk_ratelimit())
dev_dbg()
Causes the ratelimiting to spam the kernel log with the "callbacks suppressed"
message below, even while the dev_dbg it is supposed to rate limit wouldn't
print anything because DEBUG is not defined for this device.
[ 533.803964] retire_playback_urb: 852 callbacks suppressed
[ 538.807930] retire_playback_urb: 852 callbacks suppressed
[ 543.811897] retire_playback_urb: 852 callbacks suppressed
[ 548.815745] retire_playback_urb: 852 callbacks suppressed
[ 553.819826] retire_playback_urb: 852 callbacks suppressed
So use dev_dbg_ratelimited() instead of this construction.
Signed-off-by: Sander Eikelenboom <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
(backported from commit b7a7723513dc89f83d6df13206df55d4dc26e825)
Signed-off-by: Joseph Salisbury <[email protected]>
---
sound/usb/pcm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index 7bfa7a1..ede4b92 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -1487,9 +1487,9 @@ static void retire_playback_urb(struct snd_usb_substream *subs,
* The error should be lower than 2ms since the estimate relies
* on two reads of a counter updated every ms.
*/
- if (printk_ratelimit() &&
- abs(est_delay - subs->last_delay) * 1000 > runtime->rate * 2)
- snd_printk(KERN_DEBUG "delay: estimated %d, actual %d\n",
+ if (abs(est_delay - subs->last_delay) * 1000 > runtime->rate * 2)
+ dev_dbg_ratelimited(&subs->dev->dev,
+ "delay: estimated %d, actual %d\n",
est_delay, subs->last_delay);
if (!subs->running) {
--
1.9.1
On Wed, Jun 18, 2014 at 01:14:05PM -0400, Joseph Salisbury wrote:
> BugLink: http://bugs.launchpad.net/bugs/1319457
>
> Hello,
>
> Please consider including upstream commit b7a77235 in the next v3.13.y release. It was included upstream as of v3.15-rc5. It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1319457 .
Please get a good email client and wrap your lines :(
> commit b7a7723513dc89f83d6df13206df55d4dc26e825
> Author: Sander Eikelenboom <[email protected]>
> Date: Fri May 2 15:09:27 2014 +0200
>
> ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined
>
>
> This commit does not apply cleanly to v3.13, so I performed a backport, which is in email 1/1.
Any reason this shouldn't also be in 3.14-stable?
thanks,
greg k-h
On 06/18/2014 01:43 PM, Greg KH wrote:
> On Wed, Jun 18, 2014 at 01:14:05PM -0400, Joseph Salisbury wrote:
>> BugLink: http://bugs.launchpad.net/bugs/1319457
>>
>> Hello,
>>
>> Please consider including upstream commit b7a77235 in the next v3.13.y release. It was included upstream as of v3.15-rc5. It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1319457 .
> Please get a good email client and wrap your lines :(
Hmm, not sure why git send-email did that, but I'll fix it.
>
>> commit b7a7723513dc89f83d6df13206df55d4dc26e825
>> Author: Sander Eikelenboom <[email protected]>
>> Date: Fri May 2 15:09:27 2014 +0200
>>
>> ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined
>>
>>
>> This commit does not apply cleanly to v3.13, so I performed a backport, which is in email 1/1.
> Any reason this shouldn't also be in 3.14-stable?
Yes it should also be in 3.14 stable. I'll send a v2 of the patch.
>
> thanks,
>
> greg k-h
Thanks for the feedback.