On 12/09/2011 16:15, Herbert Poetzl wrote: >> Hello, >> I encountered the problem on several servers (mainly dual >> 6cores Istanbul Opteron and Xeon E3 (Sandy Bridge)). >> As the kernel.org bugzilla is down, i dont know in which >> kernel versions the bug has been corrected. > well, the second url linked above says 2.6.35 to 3.0-rc7, > so I'd presume it was fixed in 3.0 final .... > >> Which kernel versions are immune to the bug? > again, handwaving here based on the same url, a kernel > before 2.6.35 or after 3.0 should not expose the issue, > if that's what you call 'immune' ... > >> Are the 3.0x kernels from the psand.info repository safe >> for this (i got the problem on the latest 2.6.36 and 2.6.38)? > once again, if it was fixed in 3.0, the kernels from there > should be as safe as any other, in general the latest > kernel + patch is advised ... > > best, > Herbert > >> Thanks in advance. Unfortunately, i had the problem again on the 3.0.4-vs2.3.1-pre10.1-beng amd_x64 kernel after one day of uptime on a server with only one VServer (an apache2 node) : Sep 14 03:48:36 localhost kernel: [55435.551844] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 Sep 14 03:48:36 localhost kernel: [55435.551901] IP: [<ffffffff81331f32>] mutex_lock+0x22/0x22 Sep 14 03:48:36 localhost kernel: [55435.551936] PGD 10c379067 PUD 1d7faf067 PMD 0 Sep 14 03:48:36 localhost kernel: [55435.551970] Oops: 0002 [#1] SMP Sep 14 03:48:36 localhost kernel: [55435.552000] CPU 0 Sep 14 03:48:36 localhost kernel: [55435.552006] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables nfs lockd auth_rpcgss nfs_acl sunrpc cpufreq_conservative speedstep_lib acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_stats mperf ext3 jbd coretemp ipmi_si ipmi_msghandler loop snd_pcm snd_timer snd i2c_i801 tpm_tis soundcore intel_agp tpm snd_page_alloc tpm_bios intel_gtt i2c_core ghes pcspkr joydev button hed processor evdev thermal_sys psmouse serio_raw ext4 mbcache jbd2 crc16 usbhid hid sd_mod crc_t10dif ahci libahci libata scsi_mod ehci_hcd usbcore e1000e [last unloaded: scsi_wait_scan] Sep 14 03:48:36 localhost kernel: [55435.552408] Sep 14 03:48:36 localhost kernel: [55435.552430] Pid: 28772, comm: httpd Not tainted 3.0.4-vs2.3.1-pre10.1-beng #1 Supermicro X9SCL/X9SCM/X9SCL/X9SCM Sep 14 03:48:36 localhost kernel: [55435.552488] RIP: 0010:[<ffffffff81331f32>] [<ffffffff81331f32>] mutex_lock+0x22/0x22 Sep 14 03:48:36 localhost kernel: [55435.552537] RSP: 0000:ffff88010586be80 EFLAGS: 00010202 Sep 14 03:48:36 localhost kernel: [55435.552565] RAX: 00000000fffffffe RBX: ffff880172e99500 RCX: ffff880085c04d90 Sep 14 03:48:36 localhost kernel: [55435.552597] RDX: 0000000040000200 RSI: ffff880172e99500 RDI: 0000000000000038 Sep 14 03:48:36 localhost kernel: [55435.552629] RBP: ffff8801adbe0618 R08: 0000000031210000 R09: ffffffffa02b5f30 Sep 14 03:48:36 localhost kernel: [55435.552661] R10: ffff880200000003 R11: 0000000000000000 R12: 0000000000000000 Sep 14 03:48:36 localhost kernel: [55435.552692] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Sep 14 03:48:36 localhost kernel: [55435.552725] FS: 0000000000000000(0000) GS:ffff88023fc00000(0063) knlGS:00000000f73f56b0 Sep 14 03:48:36 localhost kernel: [55435.552774] CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b Sep 14 03:48:36 localhost kernel: [55435.552803] CR2: 0000000000000050 CR3: 00000001d7e7a000 CR4: 00000000000406f0 Sep 14 03:48:36 localhost kernel: [55435.552834] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Sep 14 03:48:36 localhost kernel: [55435.552866] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Sep 14 03:48:36 localhost kernel: [55435.552899] Process httpd (pid: 28772, threadinfo ffff88010586a000, task ffff88002f6d6790) Sep 14 03:48:36 localhost kernel: [55435.552946] Stack: Sep 14 03:48:36 localhost kernel: [55435.552968] ffffffff81101a83 000000000acb5084 00000000fffffffe 0000000000000000 Sep 14 03:48:36 localhost kernel: [55435.553022] ffff880172e99500 0000000000000000 ffffffff81104248 ffff88011d0e5ec0 Sep 14 03:48:36 localhost kernel: [55435.553077] ffff88004c84aa80 000000030028e821 ffff880104d6000e 0000000000000000 Sep 14 03:48:36 localhost kernel: [55435.553131] Call Trace: Sep 14 03:48:36 localhost kernel: [55435.553157] [<ffffffff81101a83>] ? vfs_rmdir+0xa8/0xc3 Sep 14 03:48:36 localhost kernel: [55435.553187] [<ffffffff81104248>] ? do_rmdir+0xb2/0xf9 Sep 14 03:48:36 localhost kernel: [55435.553217] [<ffffffff81334c83>] ? ia32_do_call+0x13/0x13 Sep 14 03:48:36 localhost kernel: [55435.553245] Code: 48 83 c4 50 5b 5d 41 5c c3 53 48 89 fb 48 83 ec 08 f0 ff 0f 79 05 e8 e1 01 00 00 65 48 8b 04 25 c0 b5 00 00 48 89 43 18 58 5b c3 Sep 14 03:48:36 localhost kernel: [55435.553491] RIP [<ffffffff81331f32>] mutex_lock+0x22/0x22 Sep 14 03:48:36 localhost kernel: [55435.553522] RSP <ffff88010586be80> Sep 14 03:48:36 localhost kernel: [55435.553545] CR2: 0000000000000050 Sep 14 03:48:36 localhost kernel: [55435.553960] ---[ end trace 57513ff63fad6714 ]--- As always, there is a remaining httpd process that i cannot kill and that makes impossible to correctly stop the VServer (and to restart it, as there is still a running process) : root@cl3-www5:~# vps aux|grep mutu0115 11704 15973 20115 mutu0115 0.0 0.7 78464 57984 ? D 06:11 0:01 /home/apache/bin/httpd -k start root@cl3-www5:~# vkill -s 9 15973 root@cl3-www5:~# vps aux|grep mutu0115 11704 15973 20115 mutu0115 0.0 0.7 78464 57984 ? D 06:11 0:01 /home/apache/bin/httpd -k start Regards.