-   Slackware (
-   -   "DEBUG kernel" notice from dmesg output on Slackware64 14.2 with kernel 4.4.157 (

ekinakoglu 10-16-2018 03:21 AM

"DEBUG kernel" notice from dmesg output on Slackware64 14.2 with kernel 4.4.157
I get the notice below from dmesg on Slackware64 14.2 with kernel 4.4.157:


[  76.971614] **********************************************************
[  76.971620] **                                                      **
[  76.971623] ** trace_printk() being used. Allocating extra memory.  **
[  76.971625] **                                                      **
[  76.971628] ** This means that this is a DEBUG kernel and it is    **
[  76.971631] ** unsafe for production use.                          **
[  76.971633] **                                                      **
[  76.971636] ** If you see this message and you are not debugging    **
[  76.971639] ** the kernel, report this immediately to your vendor!  **
[  76.971641] **                                                      **
[  76.971647] **********************************************************

Is there something wrong with the Slackware's latest kernel update? Should we inform Patrick or is this configuration on purpose?

hazel 10-16-2018 05:50 AM

Yes, I think you should report it if the kernel team don't think this option should be set in a production kernel.

It probably slipped through by accident. Patrick has a lot on his plate!

phenixia2003 10-16-2018 08:09 AM


This notice has been introduced by this (old) commit :

trace_printk() is used to debug fast paths within the kernel. Places that gets called in any context (interrupt or NMI) or thousands of times a second. Something you do not want to do with a printk(). In order to make it completely lockless as it needs a temporary buffer to handle some of the string formatting, a page is created per cpu for every context (four per cpu; normal, softirq, irq, NMI). Since trace_printk() should only be used for debugging purposes, there's no reason to waste memory on these buffers on a production system. That means, trace_printk() should never be used unless a developer is debugging their kernel. There's macro magic to allocate the buffers if trace_printk() is used anywhere in the kernel. To help enforce that trace_printk() isn't used outside of development, when it is used, a nasty banner is displayed on bootup (or when a module is loaded that uses trace_printk() and the kernel core does not).
I guess the OP encounters this only because of a module that uses trace_printk().


hazel 10-16-2018 11:08 AM

Well, if it's an in-tree module, it shouldn't be using this function either. So I still think it should be reported.

There is another possibility: that the OP is using a proprietary kernel module which is badly written. There's not much that can be done about that. But I think he'd know if he was. Wouldn't the kernel report itself as tainted?

volkerdi 10-16-2018 12:35 PM


Originally Posted by ekinakoglu (Post 5915300)
I get the notice below from dmesg on Slackware64 14.2 with kernel 4.4.157:

I'm not normally seeing this in dmesg on x86_64 14.2 here, but what modules are you using?

You will get that message if you load the ring_buffer_benchmark module, since that makes use of trace_printk().

ekinakoglu 10-17-2018 01:31 AM

After Patrick's message, I reviewed the modules in use for my kernel.

I am using Intel Parallel Studio (Fortran and C compilers and other tools) and I know that it loads some modules. Inspecting the "dmesg" output in detail I discovered that the "notice" was displayed just after socperf2_0 module had been loaded by Intel VTune Amplifier of the Intel Parallel Studio. I uninstalled the product, restarted the machine and checked again, and the "notice" was gone.

Thank you all for your help.

All times are GMT -5. The time now is 05:11 PM.