[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190125203058.GT9224@smile.fi.intel.com>
Date: Fri, 25 Jan 2019 22:30:58 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc: Mogens Jensen <mogens-jensen@...tonmail.com>,
Hans de Goede <hdegoede@...hat.com>,
Dean Wallace <duffydack73@...il.com>,
Stephen Boyd <sboyd@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
linux-clk <linux-clk@...r.kernel.org>,
Stable <stable@...r.kernel.org>,
Johannes Stezenbach <js@...21.net>,
Carlo Caione <carlo@...lessm.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)
On Fri, Jan 25, 2019 at 11:57:57AM -0600, Pierre-Louis Bossart wrote:
>
> > > > The only minor annoyance I'm experiencing now, is a large amount of debug output from something in kernel log when audio is played on the system:
> > > > writing to lpe: 00000000: 01 01 01 01 00 00 08 00 ff ff ff ff 55 00 00 00 ............U...
> > > > writing to lpe: 00000000: 01 01 01 01 00 00 1a 00 ff ff ff ff 75 00 12 00 ............u...
> > > > ...
> > > That's enabled via dynamic debug so that's rather a configuration issue
> > > than a kernel problem?
> > Do you have any suggestions on how to disable it?
> >
> > My kernel is compiled without DYNAMIC_DEBUG, DEBUG_FS and other debug features, so I don't understand why all this debug output is flooding the kernel log.
> >
> > It's a minor issue, but it would be nice to get rid of it.
> I can confirm that this happens without DYNAMIC_DEBUG, and somehow changing
> the log level doesn't seem to matter. I tried changing the console log as a
> kernel parameter or with playing /proc/sys/kernel/printk, no luck. weird.
Are you sure you did a clean build?
The logic behind print_hex_dump_bytes() is following:
- if !CONFIG_PRINTK — nothing should be printed at all
- otherwise if CONFIG_DYNAMIC_DEBUG — it goes thru its facilities
- else if goes to KERN_DEBUG level and thus loglevel should affect this either
thru command line or via procfs
If none of the above works like it should, the couple of possibilities I can see:
- unclean build where previously it was compiled somehow with DEBUG
- ignore_loglevel is in the kernel command line
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists