Why Is Pr_Debug of the Linux Kernel Not Giving Any Output

Why is pr_debug of the Linux kernel not giving any output?

Add following to Makefile, assuming filename.c is the module source file.

CFLAGS_filename.o := -DDEBUG

not

CFLAGS_[filename].o := -DDEBUG

Refer https://www.kernel.org/doc/local/pr_debug.txt

Setting CFLAGS for pr_debug and printk

I don't know about how to activate printk() - what did you search for with Google? Amongst other things, I found this which seems to imply the printk() is almost always available (but you have to mark the messages with an appropriate level, and there is probably a control over which levels are displayed on the console).

The square brackets in a macro name are unorthodox - and therefore probably an extension specific to your system.

Reading between the lines, it is likely that you are talking about the Linux kernel and therefore GNU Make, but you'd help everyone if you stated such things.

The := notation is an immediate assignment to the variable. The RHS is evaluated when the line is read and processed, not when the macro is used as is normally the case. It means that if there are macros referenced on the RHS, subsequent changes to those macros will not affect the value of this macro. Consider:

CFLAGS  = ${OFLAGS} ${IFLAGS} ${DFLAGS} ${WFLAGS}
CFLAGS := ${OFLAGS} ${IFLAGS} ${DFLAGS} ${WFLAGS}

The first variation notes that CFLAGS will be formed from the 4 named macros (well, actually, it simply copies the line ready for later expansion), but does not expand the values until it is used in (presumably) a C compilation command.

The second variation immediately looks for the values of the 4 macros at the time when the line is read and expands them out. Subsequent changes in the 4 referenced macros are not reflected in CFLAGS.

The += notation adds the RHS to the macro, rather than simply replacing it.

Why is the probe function in my kernel module not being called?

Is your purpose just educational? Otherwise the driver is already there and it's called usb-storage. Seems even that driver enumerates your device first. Try to disable usb-storage and load your driver again. Or better use the virtual machine (KVM / Qemu) to try your drivers.

Why do I get console output from ACPID when devtmpfs is mounted and logged when not?

The answer is that I had to restart syslogd and klogd after mounting devtmpfs. Output to syslog that failed when to console due to apcid using LOG_CONS option. This was busybox, kill and trying to start again didn't work, start-stop-daemon worked.

How to get details of all modules / drivers that were initialized / probed during the Linux kernel boot?

Passing the option "initcall_debug" on the kernel command line will cause timing information to be printed to the console for each init routine of built-in drivers. The initcalls are used to initialize statically linked kernel drivers and subsystems and contribute a significant amount of time to the Linux boot process. (Loadable modules are not available until after the root filesystem has been mounted.)

The output looks like:

calling  tty_class_init+0x0/0x44 @ 1
initcall tty_class_init+0x0/0x44 returned 0 after 9765 usecs
calling  spi_init+0x0/0x90 @ 1
initcall spi_init+0x0/0x90 returned 0 after 9765 usecs

Reference: http://elinux.org/Initcall_Debug

Addendum

Specifying the kernel parameter "ignore_loglevel" along with the "initcall_debug" will ensure that the information will be displayed during boot.

How to get the address of a kernel module that was inserted using insmod?

cat /proc/modules should give you a rough guide to where things are loaded. You might get more of a clue about exactly where the kernel crash is by looking at /proc/kallsyms.

---

Related Topics