How to understand this dmesg error message?

Question

I have wrote this simple module to handle a device and call some of its power management methods such as .suspend and .resume. At its initialization, t

Answer 1

I will be attempting to explain the massive wall of text that is dmesg bellow. As a note the values in brackets to the left are times I forget with what exactly they are in relation to but for you they don't really matter.

[ 59.545180] MyFirstPowerState: module license 'unspecified' taints kernel. [ 59.545183] Disabling lock debugging due to kernel taint

This is because you did not declare a module license. Usually you will see people put something like this in their code in the same section as the module_init.

MODULE_LICENSE("GPL");

[ 59.546010] LEONZO: I FOUND THE DEVICE OF THE SIZE 8 [ 59.546012] LEONZO: HERE IS ITS DRIVER NAME e1000e [ 59.546013] LEONZO: CALLING IT SUSPEND METHOD

These are your printk messages nothing really special here.

[ 59.546021] BUG: unable to handle kernel NULL pointer dereference at (null)

Here is where the cause for your crash actually lives. The kernel tried to dereference a NULL pointer which causes a seg fault. For more details on what exactly that means see here. As Ian noted in the comments earlier it looks like the cause of your crash is you put *device=dev->dev instead of device=dev->dev. In the code you have you attempted to assign the value device points to to dev->dev however since device=NULL currently you attempted to dereference NULL causing a crash.

[ 59.546051] IP: [] mfps_driver_init+0x7e/0x1000 [MyFirstPowerState] [ 59.546648] task: ffff880241a7b110 ti: ffff880242f68000 task.ti: ffff880242f68000

The chunk of errors contained within those above do not have much valuable to you currently and are more for people who have deployed something and some specific user has a problem. It is listing things like the hardware installed, the module that caused the crash, and modules that is also calling all things that in your case are very well known.

[ 59.546678] RIP: 0010:[] [] mfps_driver_init+0x7e/0x1000 [MyFirstPowerState][ 59.547079] ffff880242f6bd88 ffffffff811cef19 ffffffff810f7aac 0000000000000018

Everything in this section is assembly information which if you have no assembly experience means nothing to you although I would suggest knowing the basics it does help in these cases. The top half is registers and their current values and the bottom half is the current stack frame.

> [   59.547114] Call Trace:
[   59.547131]  [<ffffffff81002144>] do_one_initcall+0xd4/0x210
[   59.547162]  [<ffffffff811cef19>] ? kmem_cache_alloc_trace+0x199/0x220
[   59.547194]  [<ffffffff810f7aac>] ? load_module+0x164c/0x1cc0

Everything within the call trace can be exceptionally helpful especially when the module becomes long and difficult to debug with things like interrupts. Basically it is listing out every single function call (or otherwise) the system has made to lead to this crash. In your case since you went from the load module straight to the crash the trace really only has your load_module along with some wrappers and some deep system calls. However, if say your load module called another function and that caused the crash you could see this call path here.

The last little bit appears to be more registers.

Hopefully that explained the wall of text that you get from dmesg when you cause a kernel issue (not sure if this is a panic someone please correct me). If there is anything that is still vague I'll try to explain although I am by no means an expert on this.