kernel errors

[DimGR]

hi
what do these errors mean ? I keep getting them pretty often ...
checked RAM and it is fine . It is a new system .. cant figure out whats wrong

Unable to handle kernel paging request at ffffffffffff4010 RIP: 
 [<ffffffff8022dd68>] __wake_up_common+0x28/0x80
PGD 203067 PUD 101e067 PMD 0 
Oops: 0000 [1] PREEMPT SMP 
CPU 2 
Modules linked in: vmnet(P) vmmon(P) nvidia(P) cpufreq_ondemand cpufreq_powersave button ac battery ipv6 xt_state xt_length xt_conntrack ipt_LOG xt_limit xt_tcpudp iptable_mangle iptable_nat nf_nat iptable_filter ip_tables x_tables nf_conntrack_ipv4 nf_conntrack nfnetlink fuse dm_crypt acpi_cpufreq freq_table capability commoncap snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundc
ore atl1 i2c_i801 intel_agp mii snd_page_alloc i2c_core psmouse evdev serio_raw pcspkr ext3 jbd dm_mirror dm_snapshot dm_mod sd_mod sg sr_mod cdrom ata_piix firewire_ohci firewire_core crc_itu_t pata_jmicron usbhid ff_memless ohci1394 ieee1394 ahci ata_generic floppy libata ehci_hcd uhci_hcd usbcore thermal processor fan
Pid: 5533, comm: FahCore_78.exe Tainted: P       2.6.22.7 #1
RIP: 0010:[<ffffffff8022dd68>]  [<ffffffff8022dd68>] __wake_up_common+0x28/0x80
RSP: 0000:ffff81010764db38  EFLAGS: 00010006
RAX: ffffffffffff4010 RBX: ffff810001004008 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff810001004008
RBP: ffff81010764db68 R08: ffff81010764dbb8 R09: 0000000000000000
R10: 0000000000000000 R11: ffffffff88153b40 R12: ffff81010764dbb8
R13: 0000000000000001 R14: ffff810001004010 R15: ffff81010764dbb8
FS:  0000000000000000(0000) GS:ffff81012bd01580(0000) knlGS:0000000000000000
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: ffffffffffff4010 CR3: 0000000123652000 CR4: 00000000000006e0
Process FahCore_78.exe (pid: 5533, threadinfo ffff81010764c000, task ffff81012b53e6e0)
Stack:  0000000300000000 ffff810001004008 ffff81010764dbb8 0000000000000001
 0000000000000202 0000000000000003 ffff81010764dba8 ffffffff8022e473
 ffff81010764dbe8 ffff81012ea11b68 000000000000007b ffffffffffffffff
Call Trace:
 [<ffffffff8022e473>] __wake_up+0x43/0x70
 [<ffffffff8024ded8>] __wake_up_bit+0x28/0x30
 [<ffffffff80275ce6>] truncate_inode_pages_range+0x106/0x330
 [<ffffffff8027e947>] vmtruncate+0xe7/0xf0
 [<ffffffff802b20ce>] inode_setattr+0x2e/0x160
 [<ffffffff88154a7b>] :ext3:ext3_setattr+0x13b/0x280
 [<ffffffff802b2510>] notify_change+0x310/0x3c0
 [<ffffffff80299bee>] do_truncate+0x5e/0x80
 [<ffffffff802a3349>] get_write_access+0x39/0x60
 [<ffffffff802a4c88>] may_open+0x1d8/0x2c0
 [<ffffffff802a75fa>] open_namei+0x9a/0x740
 [<ffffffff8029be35>] file_move+0x25/0x70
 [<ffffffff8029931c>] do_filp_open+0x1c/0x50
 [<ffffffff80298f99>] get_unused_fd+0xe9/0x110
 [<ffffffff802993aa>] do_sys_open+0x5a/0x100
 [<ffffffff80225d62>] ia32_sysret+0x0/0xa


Code: 48 8b 18 75 06 eb 33 90 48 89 d3 48 8d 78 e8 44 8b 60 e8 4c 
RIP  [<ffffffff8022dd68>] __wake_up_common+0x28/0x80
 RSP <ffff81010764db38>
CR2: ffffffffffff4010

[JohnT]

Do a look-up for "ksymoops" install for your distro or download and compile it.

The Linux kernel produces error messages that contain machine specific numbers which are meaningless for debugging. 'ksymoops' reads machine specific files and the error log and does its best to converts the code to instructions and map addresses to kernel symbols.

[bwkaz]

Or ignore JohnT's post, since it looks like he hasn't heard of kksymoops (the old functionality of ksymoops is now built into the kernel: the crash dump that you posted has the decoded stack trace in it already).

From the call trace here, you're (obviously) running into some kind of bug in the code that's running in kernel mode. However, you have three different binary-only kernel modules loaded (vmnet, vmmon, nvidia), which are all executing who-knows-what code in the kernel -- so there's no way to pin this down to either a bug in the kernel itself, or in any particular one of those modules.

You can try to upgrade your kernel; perhaps it's a bug that someone else knows about and has fixed. But I wouldn't be too hopeful unless you can reproduce this crash without loading any of vmnet, vmmon, or nvidia. (Reboot, ensure those modules never load (including from distro bootscripts!), and try to get the kernel to oops.)

[JohnT]

That shows you how often I rebuild my kernel these days or have the oops at all.

[bwkaz]

Yeah, pretty much the only reason I know that is because I read through the "what's new in kernel 2.5" list that was floating around while the early 2.6.0-testX kernels were being hacked on. I think I've seen a couple of stack traces, but usually it's something dumb I've done (as root, of course), not some fault in the kernel.

This case appears to be some fault in the kernel, though the fact that it's tainted with proprietary code (that's the "P", I think) means there's no way to tell for sure where the fault is...