Re: [Vserver] vserver enter eating cpu and vkill problem
Hey, [...] Could you try http://svn.linux-vserver.org/projects/util-vserver/changeset/2514?format=diffnew=2514 instead? Essentially the same thing, just in the (IMHO) correct function. It works very well. Jarek Dyląg ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] vserver enter eating cpu and vkill problem
Hey
[...]
Yeah, I know where it happens, but why it happens and how to fix it is
still a mystery. Thus far, every solution I've tried has failed.
http://people.linux-vserver.org/~dhozac/p/uv/experimental/delta-vlogin-efds.diff
has two of the things I've tried to fix it.
I added additional check in termina_copy() functon:
--- vlogin.c.old2006-12-09 17:15:22.0 +0100
+++ vlogin.c2007-03-14 13:47:13.0 +0100
@@ -139,6 +139,11 @@
} else if (len == -1)
return;
+ if (len == 0) {
+terminal_kill(SIGTERM);
+exit(1);
+ }
+
/* write activity to user */
EwriteAll(dst, buf, len);
}
It fixes the problem, but i don't know if i haven't broken something else.
Jarek Dylag
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] vserver enter eating cpu and vkill problem
Hey, [...] Apparently it happens when the session is not ended properly (disconnections, etc) I could reproduce the problem as follow: * ssh to the server as normal user * sudo su - * vserver XX enter * now from another term, kill -9 on either of the two su processes (su - or -su) At that point the session in the vserver ends but vcontext is still hooked to the current terminal so cpu is fine. * now quit the current terminal At that point vcontext is not hooked to any terminal (vps ax = ? on the tty column) and using top you see it's running 100% cpu, ~ 80% system and 20% user. I'll look in to it. I am unable to reproduce that here. The vlogin process does stick around, which it probably shouldn't, but its resource usage is the same as it's always been. I can reproduce it on debian sid with 2.6.20.1-vs2.3.0.11 kernel. ps auxf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2716 82.5 0.0 116 40 ?R15:17 7:04 login root 2774 0.0 0.3 5072 1660 pts/6Ss+ 15:17 0:00 \_ /bin/bash -login I straced login process, strace shows: Process 2716 attached - interrupt to quit select(4, [0 3], NULL, NULL, NULL) = 1 (in [0]) read(0, \r, 64) = 1 write(3, \r, 1) = 1 select(4, [0 3], NULL, NULL, NULL) = 1 (in [3]) read(3, \r\n, 64) = 2 write(1, \r\n, 2) = 2 select(4, [0 3], NULL, NULL, NULL) = 1 (in [3]) read(3, \33[1m/ \33[37;0m(\33[32;1m1525\33[37;0m..., 64) = 47 write(1, \33[1m/ \33[37;0m(\33[32;1m1525\33[37;0m..., 47) = 47 Here session ended: select(4, [0 3], NULL, NULL, NULL) = 1 (in [0]) read(0, , 64) = 0 select(4, [0 3], NULL, NULL, NULL) = 1 (in [0]) read(0, , 64) = 0 select(4, [0 3], NULL, NULL, NULL) = 1 (in [0]) read(0, , 64) = 0 select(4, [0 3], NULL, NULL, NULL) = 1 (in [0]) read(0, , 64) = 0 select(4, [0 3], NULL, NULL, NULL) = 1 (in [0]) read(0, , 64) = 0 select(4, [0 3], NULL, NULL, NULL) = 1 (in [0]) read(0, , 64) = 0 select(4, [0 3], NULL, NULL, NULL) = 1 (in [0]) Jarek Dylag ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: quota problem
Hi,
question is, on what filesystem, and with what options
IIRC, ext3 is kind of hairy, as it supports two different
kinds of quote, a journaled one and the 'normal' ext2
quota stuff ...
ext3 with mount options: rw,noatime,usrquota,grpquota
i checked also ext2,
strace output after quotaon command shows:
quotactl(Q_QUOTAON|USRQUOTA, /dev/hdv1, 2, {7022360269181497135,
491328337198, 210453397504, 701898877744431, 7809632559044715890,
3408187388784029541, 4707197592648237900, 7161402270843880775}) = -1
ENODEV (No such device)
I think my issue was that /etc/mtab and /etc/fstab have to be correct.
To get that i put them in /etc/vserver/name/apps/init/ (As far as i
remember, only mail access ehre now).
yes, it _is_ essential to get proper values at mount
(real mount time) and mtab (for the guest)
my configuration:
host fstab:
/dev/hdc6 /vservers ext3noatime,usrquota,grpquota 0 2
host mtab:
/dev/hdc6 /vservers ext3 rw,noatime,usrquota,grpquota 0 0
host /proc/mounts:
/dev/hdc6 /vservers ext3 rw,noatime,usrquota,grpquota 0 0
guest apps/init/mtab:
/dev/hdv1 / ufsnoatime,usrquota,grpquota 0 2
guest /proc/monts:
/dev/root / ext3 rw,noatime,usrquota,grpquota 0 0
guest fstab:
/dev/hdv1 / ext3defaults,usrquota,grpquota1 1
guest mtab:
/dev/hdv1 / ufsnoatime,usrquota,grpquota 0 2
Jarek Dylag
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] kernel panic on vs2.2.0-rc11
Hi, could you do a 'cat /proc/virtual/status' just before and right after the 'evil' exec and also provide the guest config you are using? After exec system crashes, so i can provide only status before exec: UseCnt: 33 Tasks: 14 Flags: 0006020f0310 BCaps: 3fff CCaps: 00100101 Spaces: 0c020200 Thera are all bcapabilities enabled for guests on this system (debian etch guests in early testing status, with cron, syslog-ng, apache2.2 and vsftpd enabled). /etc/vservers/x2136/fstab: none /proc proc defaults,noexec,nosuid 0 0 none /tmp tmpfs size=64m,mode=1777,noexec,nosuid 0 0 none /dev/pts devpts gid=5,mode=620 0 0 /etc/vservers/x2136/schedule: 1 2 500 5 500 -2 /etc/vservers/x2136/apps/init/mark default /etc/vservers/x2136/apps/init/mtab /dev/hdv1 / ufs defaults,noatime,usrquota,grpquota 0 0 Jarek Dylag ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] kernel panic on vs2.2.0-rc11
Hi, [...] That's /proc/virtual/xid/status. /proc/virtual/status will contain use counts for fs_structs, which is most likely what's causing your oops... But without the after shot, it'll be impossible to say if that's what's causing it. Sorry, my status file: cat /proc/virtual/status #CTotal:1 #CActive: 1 #NSProxy: 2 36 1 1 1 Thera are all bcapabilities enabled for guests on this system Why on earth would you do that? This is only test environment, i tryed to find solution of my quota problems (i described it in another mail). Jarek Dylag ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: quota problem
Hey, I still can't get quota working. I made some investigation and problem started after changes in namespace separation implementation made between: patch-2.6.19-vs2.1.x-t4.diff and patch-2.6.19-vs2.1.x-t7.diff Jarek Dylag ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] kernel panic on vs2.2.0-rc11
Hi, My test server crashes after executing : vserver name exec or vserver name enter I tested: patch-2.6.19.2-vs2.2.0-rc9.diff patch-2.6.19.3-vs2.2.0-rc11.diff Last version without this issue is vs2.2.0.rc8.7. Opps in attachement. Jarek Dylag Feb 6 10:16:38 v2139 [ 146.190021] BUG: rwlock bad magic on CPU#0, vcontext/3288, f6afe120 Feb 6 10:16:38 v2139 [ 146.190158] [c010416f] Feb 6 10:16:38 v2139 show_trace_log_lvl+0x2f/0x50 Feb 6 10:16:38 v2139 [ 146.190335] [c01041b7] Feb 6 10:16:38 v2139 show_trace+0x27/0x30 Feb 6 10:16:38 v2139 [ 146.190623] [c01042e6] Feb 6 10:16:38 v2139 dump_stack+0x26/0x30 Feb 6 10:16:38 v2139 [ 146.190929] [c037363a] Feb 6 10:16:38 v2139 rwlock_bug+0x5a/0x60 Feb 6 10:16:38 v2139 [ 146.191206] [c0373676] Feb 6 10:16:38 v2139 _raw_read_lock+0x36/0x40 Feb 6 10:16:38 v2139 [ 146.191512] [c05ffc8e] Feb 6 10:16:38 v2139 _read_lock+0xe/0x10 Feb 6 10:16:38 v2139 [ 146.191784] [c018c292] Feb 6 10:16:38 v2139 do_path_lookup+0x1b2/0x250 Feb 6 10:16:38 v2139 [ 146.192057] [c018c38e] Feb 6 10:16:38 v2139 __path_lookup_intent_open+0x3e/0x90 Feb 6 10:16:38 v2139 [ 146.192364] [c018c415] Feb 6 10:16:38 v2139 path_lookup_open+0x35/0x40 Feb 6 10:16:38 v2139 [ 146.192669] [c0187186] Feb 6 10:16:38 v2139 open_exec+0x36/0xe0 Feb 6 10:16:38 v2139 [ 146.192973] [c0188124] Feb 6 10:16:38 v2139 do_execve+0x34/0x200 Feb 6 10:16:38 v2139 [ 146.193277] [c0101f2f] Feb 6 10:16:38 v2139 sys_execve+0x3f/0xa0 Feb 6 10:16:38 v2139 [ 146.193581] [c0103381] Feb 6 10:16:38 v2139 sysenter_past_esp+0x56/0x79 Feb 6 10:16:38 v2139 [ 146.193886] === Feb 6 10:16:38 v2139 [ 146.194095] BUG: unable to handle kernel paging request Feb 6 10:16:38 v2139 at virtual address a56b6b93 Feb 6 10:16:38 v2139 [ 146.194282] printing eip: Feb 6 10:16:38 v2139 [ 146.194422] c018c2a7 Feb 6 10:16:38 v2139 [ 146.194561] *pde = Feb 6 10:16:38 v2139 [ 146.194707] Oops: 0002 [#1] Feb 6 10:16:38 v2139 [ 146.194854] Feb 6 10:16:38 v2139 SMP Feb 6 10:16:38 v2139 DEBUG_PAGEALLOC Feb 6 10:16:38 v2139 Feb 6 10:16:38 v2139 [ 146.195391] Modules linked in: Feb 6 10:16:38 v2139 ipt_owner Feb 6 10:16:38 v2139 xt_state Feb 6 10:16:38 v2139 xt_tcpudp Feb 6 10:16:38 v2139 iptable_filter Feb 6 10:16:38 v2139 ipt_MASQUERADE Feb 6 10:16:38 v2139 iptable_nat Feb 6 10:16:38 v2139 ip_nat Feb 6 10:16:38 v2139 ip_tables Feb 6 10:16:38 v2139 x_tables Feb 6 10:16:38 v2139 netconsole Feb 6 10:16:38 v2139 ecb Feb 6 10:16:38 v2139 af_key Feb 6 10:16:38 v2139 uhci_hcd Feb 6 10:16:38 v2139 ohci_hcd Feb 6 10:16:38 v2139 ehci_hcd Feb 6 10:16:38 v2139 usbcore Feb 6 10:16:38 v2139 ip_conntrack_ftp Feb 6 10:16:38 v2139 ip_conntrack Feb 6 10:16:38 v2139 nfnetlink Feb 6 10:16:38 v2139 forcedeth Feb 6 10:16:38 v2139 Feb 6 10:16:38 v2139 [ 146.197524] CPU:0 Feb 6 10:16:38 v2139 [ 146.197525] EIP:0060:[c018c2a7]Not tainted VLI Feb 6 10:16:38 v2139 [ 146.197527] EFLAGS: 00010282 (2.6.19.3-vs2.2.0-rc11.p4smp.76 #1) Feb 6 10:16:38 v2139 [ 146.197989] EIP is at do_path_lookup+0x1c7/0x250 Feb 6 10:16:38 v2139 [ 146.198174] eax: a56b6b6b ebx: f6afe120 ecx: 0001 edx: f6c7a000 Feb 6 10:16:38 v2139 [ 146.198334] esi: f6afe11c edi: f6c7bf1c ebp: f6c7becc esp: f6c7beac Feb 6 10:16:38 v2139 [ 146.198493] ds: 007b es: 007b ss: 0068 Feb 6 10:16:38 v2139 [ 146.198648] Process vcontext (pid: 3288[#2136], ti=f6c7a000 task=f75c6ab0 task.ti=f6c7a000) Feb 6 10:16:38 v2139 Feb 6 10:16:38 v2139 [ 146.198809] Stack: Feb 6 10:16:38 v2139 f6c7bebc Feb 6 10:16:38 v2139 c0173336 Feb 6 10:16:38 v2139 Feb 6 10:16:38 v2139 f583 Feb 6 10:16:38 v2139 c186dcd8 Feb 6 10:16:38 v2139 0101 Feb 6 10:16:38 v2139 f6c7bf1c Feb 6 10:16:38 v2139 fff4 Feb 6 10:16:38 v2139 Feb 6 10:16:38 v2139 [ 146.200201] Feb 6 10:16:38 v2139 f6c7bee0 Feb 6 10:16:38 v2139 c018c38e Feb 6 10:16:38 v2139 f6c7bf1c Feb 6 10:16:38 v2139 f583 Feb 6 10:16:38 v2139 f6c7bf1c Feb 6 10:16:38 v2139 f6c7bf00 Feb 6 10:16:38 v2139 c018c415 Feb 6 10:16:38 v2139 ff9c Feb 6 10:16:38 v2139 Feb 6 10:16:38 v2139 [ 146.201600] Feb 6 10:16:38 v2139 f583 Feb 6 10:16:38 v2139 0001 Feb 6 10:16:38 v2139 f6c7bf1c Feb 6 10:16:38 v2139 0011 Feb 6 10:16:38 v2139 Feb 6 10:16:38 v2139 f6c7bf74 Feb 6 10:16:38 v2139 c0187186 Feb 6 10:16:38 v2139 ff9c Feb 6 10:16:38 v2139 Feb 6 10:16:38 v2139 [ 146.202999] Call Trace: Feb 6 10:16:38 v2139 [ 146.203302] [c010416f] Feb 6 10:16:38 v2139 show_trace_log_lvl+0x2f/0x50 Feb 6 10:16:38 v2139 [ 146.203640] [c0104257] Feb 6 10:16:38 v2139 show_stack_log_lvl+0x97/0xc0 Feb 6 10:16:38 v2139 [ 146.203978] [c01044b2] Feb 6 10:16:38 v2139 show_registers+0x1c2/0x270 Feb 6 10:16:38 v2139 [ 146.204315] [c0104776] Feb 6 10:16:38 v2139 die+0x156/0x270 Feb
Re: [Vserver] Strange problem with starting apache
Hi, [...] some strace output: semget(IPC_PRIVATE, 1, IPC_CREAT|0600) = -1 ENOSPC (No space left on device) Do you need the full output? I habe this error before but after a reboot it was gone. Are there any solutions to prevent this error's? it probably means that your system have run out of semaphore arrays. Some apache2 modules use semaphores (2 arrays per apache in my configuration, more If you are using modules like: mod_perl, mod_python. mod_rewrite). You have to check current shared memory and semaphores usage and limits. Jarek Dylag ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] kernel panic patch-2.6.19.1-vs2.1.1.7.diff
Hi, perfect, this provided the essential clue please verify that the following patch fixes the issue for you: http://vserver.13thfloor.at/Experimental/delta-proc-fix04.diff Test server didn't crashed so far. I checked this patch and also new patch-2.6.19.2-vs2.2.0-rc8.7. Thanks for help. Jarek ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: quota problem
Hey After upgrade from: 2.6.17.11-vs2.1.1-rc31 to: 2.6.19.2-vs2.2.0-rc8.7 i noticed, that quota don't work form me anymore. quotaon -a quotaon: using //qquota.group on /dev/hdv1 [/]: No such device quotaon: using //qquota.user on /dev/hdv1 [/]: No such device Use the quota tools by _implicitely_ specifying the _device_ : # quota* --xxx --yyy /dev/hdvX No, it still doesn't work. additional information, maybe it will help: # /usr/sbin/vrsetup /dev/vroot0 /dev/hda6 # ls -la /dev/vroot0 brw--- 1 root root 4, 0 2005-07-22 21:24 /dev/vroot0 # vserver v1890 enter # ls -la /dev/hdv1 brw--- 1 root disk 4, 0 2005-09-15 07:52 /dev/hdv1 # ls -la /aquota* -rw--- 1 root root 12288 2007-01-28 19:36 /aquota.group -rw--- 1 root root 11264 2007-01-28 19:36 /aquota.user # quotacheck -ugm /dev/hdv1 # quotaon -ug /dev/hdv1 quotaon: using //aquota.group on /dev/hdv1 [/]: No such device quotaon: using //aquota.user on /dev/hdv1 [/]: No such device Jarek ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] quota problem
Hey, After upgrade from: 2.6.17.11-vs2.1.1-rc31 to: 2.6.19.2-vs2.2.0-rc8.7 i noticed, that quota don't work form me anymore. I got error message: quotaon -a quotaon: using //qquota.group on /dev/hdv1 [/]: No such device quotaon: using //qquota.user on /dev/hdv1 [/]: No such device /etc/fstab /dev/hdv1 / ext3defaults,usrquota,grpquota1 1 /etc/mtab /dev/hdv1 / ufs defaults,noatime,usrquota,grpquota 0 0 /proc/mounts /dev/root / ext3 rw,tag,data=ordered,usrquota,grpquota 0 0 This problem is similar to this : http://www.paul.sladen.org/vserver/archives/200509/0077.html Jarek ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] kernel panic patch-2.6.19.1-vs2.1.1.7.diff
Hi okay, I think we need some more information, especially the following would be of interest: # gcc --version gcc-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) # as --version GNU assembler 2.15 and the result of this inisde your kernel build tree: (make sure that config and tools are the same as for the oops you reported!!) # make fs/proc/array.s simply provide the resulting fs/proc/array.s results are available at: http://195.149.230.90/array.s PS: does the issue go away if you do not compile with the CONFIG_CC_OPTIMIZE_FOR_SIZE=y (which probably doesn't make any sense on you arch, as it just slows down execution) No, issue still exists. Jarek Dylag ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] kernel panic patch-2.6.19.1-vs2.1.1.7.diff
Hi There is nothing new in kernel log after changes, oops in attachement. very strange ... you constantly omit the kernel lines from the oops traces, could you verify that you actually booted the modified kernel? I sended all information i can find in server logs (from netconsole). Yes, i'm sure it is modified kernel. could you also upload the vmlinux (not vmlinuz) file somewhere where I could access it? Vmlinux file, oops and my config file are available at: http://195.149.230.90/vmlinux http://195.149.230.90/vmlinux.bz2 http://195.149.230.90/.config http://195.149.230.90/oops.txt Jarek Dylag ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] kernel panic patch-2.6.19.1-vs2.1.1.7.diff
Hi, okay, as it seems, I cannot recreate this here please could you make the following changes to get_task_state() There is nothing new in kernel log after changes, oops in attachement. Jarek Dylag Jan 3 13:02:33 v2140 [10966.004095] BUG: unable to handle kernel NULL pointer dereference Jan 3 13:02:33 v2140 at virtual address Jan 3 13:02:33 v2140 [10966.004192] printing eip: Jan 3 13:02:33 v2140 [10966.004227] c01b2498 Jan 3 13:02:33 v2140 [10966.004260] *pde = Jan 3 13:02:33 v2140 [10966.004300] Oops: [#1] Jan 3 13:02:33 v2140 [10966.004341] Jan 3 13:02:33 v2140 SMP Jan 3 13:02:33 v2140 DEBUG_PAGEALLOC Jan 3 13:02:33 v2140 Jan 3 13:02:33 v2140 [10966.004428] Modules linked in: Jan 3 13:02:33 v2140 ipt_LOG Jan 3 13:02:33 v2140 ipt_owner Jan 3 13:02:33 v2140 xt_state Jan 3 13:02:33 v2140 xt_tcpudp Jan 3 13:02:33 v2140 iptable_filter Jan 3 13:02:33 v2140 ipt_MASQUERADE Jan 3 13:02:33 v2140 iptable_nat Jan 3 13:02:33 v2140 ip_nat Jan 3 13:02:33 v2140 ip_tables Jan 3 13:02:33 v2140 x_tables Jan 3 13:02:33 v2140 ecb Jan 3 13:02:33 v2140 af_key Jan 3 13:02:33 v2140 tun Jan 3 13:02:33 v2140 netconsole Jan 3 13:02:33 v2140 e100 Jan 3 13:02:33 v2140 r8169 Jan 3 13:02:33 v2140 crc32 Jan 3 13:02:33 v2140 ip_conntrack_ftp Jan 3 13:02:33 v2140 ip_conntrack Jan 3 13:02:33 v2140 nfnetlink Jan 3 13:02:33 v2140 Jan 3 13:02:33 v2140 [10966.005037] CPU:2 Jan 3 13:02:33 v2140 [10966.005040] EIP:0060:[c01b2498]Not tainted VLI Jan 3 13:02:33 v2140 [10966.005044] EFLAGS: 00010286 (2.6.19.1-vs2.2.0-rc5.p4smp.53 #1) Jan 3 13:02:33 v2140 [10966.005201] EIP is at do_task_stat+0xa5/0x766 Jan 3 13:02:33 v2140 [10966.005253] eax: ebx: d91ef000 ecx: c06ecbb4 edx: 0040 Jan 3 13:02:33 v2140 [10966.005311] esi: dbdf45a0 edi: dbdf45a0 ebp: cc0e9f14 esp: cc0e9dc0 Jan 3 13:02:33 v2140 [10966.005368] ds: 007b es: 007b ss: 0068 Jan 3 13:02:33 v2140 [10966.005418] Process pidof (pid: 23423[#2149], ti=cc0e8000 task=da4e45a0 task.ti=cc0e8000) Jan 3 13:02:33 v2140 Jan 3 13:02:33 v2140 [10966.005473] Stack: Jan 3 13:02:33 v2140 da4e45a0 Jan 3 13:02:33 v2140 c01142ed Jan 3 13:02:33 v2140 cc0e9de8 Jan 3 13:02:33 v2140 c0141f03 Jan 3 13:02:33 v2140 da4e45a0 Jan 3 13:02:33 v2140 da4e45a0 Jan 3 13:02:33 v2140 c0588874 Jan 3 13:02:33 v2140 Jan 3 13:02:33 v2140 Jan 3 13:02:33 v2140 [10966.005788] Jan 3 13:02:33 v2140 cc0e9e00 Jan 3 13:02:33 v2140 c0140dd6 Jan 3 13:02:33 v2140 da4e45a0 Jan 3 13:02:33 v2140 Jan 3 13:02:33 v2140 c0588874 Jan 3 13:02:33 v2140 da4e45a0 Jan 3 13:02:33 v2140 c06e4a44 Jan 3 13:02:33 v2140 0296 Jan 3 13:02:33 v2140 Jan 3 13:02:33 v2140 [10966.006090] Jan 3 13:02:33 v2140 cc0e9e1c Jan 3 13:02:33 v2140 0296 Jan 3 13:02:33 v2140 c06e4a44 Jan 3 13:02:33 v2140 0001 Jan 3 13:02:33 v2140 c01142ed Jan 3 13:02:33 v2140 c151a4c0 Jan 3 13:02:33 v2140 0001 Jan 3 13:02:33 v2140 cc0e9e3c Jan 3 13:02:33 v2140 Jan 3 13:02:33 v2140 [10966.006427] Call Trace: Jan 3 13:02:33 v2140 [10966.006510] [c0103dbd] Jan 3 13:02:33 v2140 show_trace_log_lvl+0x2f/0x45 Jan 3 13:02:33 v2140 [10966.006593] [c0103e9b] Jan 3 13:02:33 v2140 show_stack_log_lvl+0x9f/0xa7 Jan 3 13:02:33 v2140 [10966.006678] [c01040b2] Jan 3 13:02:33 v2140 show_registers+0x1b1/0x242 Jan 3 13:02:33 v2140 [10966.006755] [c0104345] Jan 3 13:02:33 v2140 die+0x151/0x246 Jan 3 13:02:33 v2140 [10966.006829] [c058a68e] Jan 3 13:02:33 v2140 do_page_fault+0x498/0x58a Jan 3 13:02:33 v2140 [10966.006919] [c0588c09] Jan 3 13:02:33 v2140 error_code+0x39/0x40 Jan 3 13:02:33 v2140 [10966.006998] [c01b2b9b] Jan 3 13:02:33 v2140 proc_tgid_stat+0x20/0x22 Jan 3 13:02:33 v2140 [10966.007080] [c01ad6dd] Jan 3 13:02:33 v2140 proc_info_read+0x12f/0x17e Jan 3 13:02:33 v2140 [10966.007166] [c01761f0] Jan 3 13:02:33 v2140 vfs_read+0xa3/0x177 Jan 3 13:02:33 v2140 [10966.007244] [c017658e] Jan 3 13:02:33 v2140 sys_read+0x47/0x6b Jan 3 13:02:33 v2140 [10966.040593] [c0102feb] Jan 3 13:02:33 v2140 syscall_call+0x7/0xb Jan 3 13:02:33 v2140 [10966.040650] === Jan 3 13:02:33 v2140 [10966.040685] Code: Jan 3 13:02:33 v2140 07 Jan 3 13:02:33 v2140 8b Jan 3 13:02:33 v2140 97 Jan 3 13:02:33 v2140 8c Jan 3 13:02:33 v2140 00 Jan 3 13:02:33 v2140 00 Jan 3 13:02:33 v2140 00 Jan 3 13:02:33 v2140 b9 Jan 3 13:02:33 v2140 98 Jan 3 13:02:33 v2140 cb Jan 3 13:02:33 v2140 6e Jan 3 13:02:33 v2140 c0 Jan 3 13:02:33 v2140 83 Jan 3 13:02:33 v2140 e0 Jan 3 13:02:33 v2140 1f Jan 3 13:02:33 v2140 83 Jan 3 13:02:33 v2140 e2 Jan 3 13:02:33 v2140 60 Jan 3 13:02:33 v2140 09 Jan 3 13:02:33 v2140 d0 Jan 3 13:02:33 v2140 74 Jan 3 13:02:33 v2140 13 Jan 3 13:02:33 v2140 83 Jan 3 13:02:33 v2140 c1 Jan 3 13:02:33 v2140 04 Jan 3 13:02:33 v2140 d1 Jan 3 13:02:33 v2140 e8 Jan
Re: [Vserver] kernel panic patch-2.6.19.1-vs2.1.1.7.diff
On 22/12/06, Herbert Poetzl [EMAIL PROTECTED] wrote: On Thu, Dec 21, 2006 at 03:45:45PM +0100, Jarek Dylag wrote: Hi, I've tested: patch-2.6.19.1-vs2.1.1.7.diff patch-2.6.19.1-vs2.2.0-rc5.diff hmm, are you sure? it looks like a bug we fixed in vs2.2.0-rc5, so please try to confirm that version, and if so, please yes, confirmed also with vs2.2.0-rc6 enable kernel debug info and frame pointers so that we can get a meaningful backtrace i turned on all kernel debug options, results in attachments. Jarek Dylag Dec 29 03:16:52 v2140 [ 7366.213758] BUG: unable to handle kernel NULL pointer dereference Dec 29 03:16:52 v2140 at virtual address Dec 29 03:16:52 v2140 [ 7366.213881] printing eip: Dec 29 03:16:52 v2140 [ 7366.213929] c01b2466 Dec 29 03:16:52 v2140 [ 7366.213989] *pde = Dec 29 03:16:52 v2140 [ 7366.214045] Oops: [#1] Dec 29 03:16:52 v2140 [ 7366.214089] Dec 29 03:16:52 v2140 SMP Dec 29 03:16:52 v2140 DEBUG_PAGEALLOC Dec 29 03:16:52 v2140 Dec 29 03:16:52 v2140 [ 7366.214221] Modules linked in: Dec 29 03:16:52 v2140 ipt_LOG Dec 29 03:16:52 v2140 ipt_owner Dec 29 03:16:52 v2140 xt_state Dec 29 03:16:52 v2140 xt_tcpudp Dec 29 03:16:52 v2140 iptable_filter Dec 29 03:16:52 v2140 ipt_MASQUERADE Dec 29 03:16:52 v2140 iptable_nat Dec 29 03:16:52 v2140 ip_nat Dec 29 03:16:52 v2140 ip_tables Dec 29 03:16:52 v2140 x_tables Dec 29 03:16:52 v2140 ecb Dec 29 03:16:52 v2140 af_key Dec 29 03:16:52 v2140 tun Dec 29 03:16:52 v2140 netconsole Dec 29 03:16:52 v2140 e100 Dec 29 03:16:52 v2140 r8169 Dec 29 03:16:52 v2140 crc32 Dec 29 03:16:52 v2140 ip_conntrack_ftp Dec 29 03:16:52 v2140 ip_conntrack Dec 29 03:16:52 v2140 nfnetlink Dec 29 03:16:52 v2140 Dec 29 03:16:52 v2140 [ 7366.214679] CPU:2 Dec 29 03:16:52 v2140 [ 7366.214681] EIP:0060:[c01b2466]Not tainted VLI Dec 29 03:16:52 v2140 [ 7366.214683] EFLAGS: 00010247 (2.6.19.1-vs2.2.0-rc5.p4smp.52 #1) Dec 29 03:16:52 v2140 [ 7366.214799] EIP is at do_task_stat+0x8d/0x74e Dec 29 03:16:52 v2140 [ 7366.214839] eax: ebx: cae2f000 ecx: c06ecbb4 edx: 0040 Dec 29 03:16:52 v2140 [ 7366.214880] esi: c9b5c5a0 edi: c9b5c5a0 ebp: d8221f14 esp: d8221dc0 Dec 29 03:16:52 v2140 [ 7366.214923] ds: 007b es: 007b ss: 0068 Dec 29 03:16:52 v2140 [ 7366.214961] Process pidof (pid: 8231[#2030], ti=d822 task=c5ea65a0 task.ti=d822) Dec 29 03:16:52 v2140 Dec 29 03:16:52 v2140 [ 7366.215004] Stack: Dec 29 03:16:52 v2140 c5ea65a0 Dec 29 03:16:52 v2140 c01142ed Dec 29 03:16:52 v2140 d8221de8 Dec 29 03:16:52 v2140 c0141f03 Dec 29 03:16:52 v2140 c5ea65a0 Dec 29 03:16:52 v2140 c5ea65a0 Dec 29 03:16:52 v2140 c0588844 Dec 29 03:16:52 v2140 Dec 29 03:16:52 v2140 Dec 29 03:16:52 v2140 [ 7366.215228] Dec 29 03:16:52 v2140 d8221e00 Dec 29 03:16:52 v2140 c0140dd6 Dec 29 03:16:52 v2140 c5ea65a0 Dec 29 03:16:52 v2140 Dec 29 03:16:52 v2140 c0588844 Dec 29 03:16:52 v2140 c5ea65a0 Dec 29 03:16:52 v2140 c06e4a44 Dec 29 03:16:52 v2140 0296 Dec 29 03:16:52 v2140 Dec 29 03:16:52 v2140 [ 7366.215409] Dec 29 03:16:52 v2140 d8221e1c Dec 29 03:16:52 v2140 0296 Dec 29 03:16:52 v2140 c06e4a44 Dec 29 03:16:52 v2140 0001 Dec 29 03:16:52 v2140 c01142ed Dec 29 03:16:52 v2140 c12361c0 Dec 29 03:16:52 v2140 0001 Dec 29 03:16:52 v2140 d8221e3c Dec 29 03:16:52 v2140 Dec 29 03:16:52 v2140 [ 7366.215579] Call Trace: Dec 29 03:16:52 v2140 [ 7366.215641] [c0103dbd] Dec 29 03:16:52 v2140 show_trace_log_lvl+0x2f/0x45 Dec 29 03:16:52 v2140 [ 7366.215704] [c0103e9b] Dec 29 03:16:52 v2140 show_stack_log_lvl+0x9f/0xa7 Dec 29 03:16:52 v2140 [ 7366.215778] [c01040b2] Dec 29 03:16:52 v2140 show_registers+0x1b1/0x242 Dec 29 03:16:52 v2140 [ 7366.215834] [c0104345] Dec 29 03:16:52 v2140 die+0x151/0x246 Dec 29 03:16:52 v2140 [ 7366.234644] [c058a65e] Dec 29 03:16:52 v2140 do_page_fault+0x498/0x58a Dec 29 03:16:52 v2140 [ 7366.234711] [c0588bd9] Dec 29 03:16:52 v2140 error_code+0x39/0x40 Dec 29 03:16:52 v2140 [ 7366.234767] [c01b2b69] Dec 29 03:16:52 v2140 proc_tgid_stat+0x20/0x22 Dec 29 03:16:52 v2140 [ 7366.234826] [c01ad6dd] Dec 29 03:16:52 v2140 proc_info_read+0x12f/0x17e Dec 29 03:16:52 v2140 [ 7366.234888] [c01761f0] Dec 29 03:16:52 v2140 vfs_read+0xa3/0x177 Dec 29 03:16:52 v2140 [ 7366.234948] [c017658e] Dec 29 03:16:52 v2140 sys_read+0x47/0x6b Dec 29 03:16:52 v2140 [ 7366.235004] [c0102feb] Dec 29 03:16:52 v2140 syscall_call+0x7/0xb Dec 29 03:16:52 v2140 [ 7366.235062] === Dec 29 03:16:52 v2140 [ 7366.235099] Code: Dec 29 03:16:52 v2140 45 Dec 29 03:16:52 v2140 84 Dec 29 03:16:52 v2140 00 Dec 29 03:16:52 v2140 00 Dec 29 03:16:52 v2140 00 Dec 29 03:16:52 v2140 00 Dec 29 03:16:52 v2140 c7 Dec 29 03:16:52 v2140 85 Dec 29 03:16:52 v2140 70 Dec 29 03:16:52 v2140 ff Dec 29 03:16:52 v2140 ff Dec 29 03:16:52 v2140 ff Dec 29 03:16:52 v2140 00 Dec 29 03:16:52 v2140 00 Dec 29 03:16:52
[Vserver] Kernel panic when running strace inside a vserver
Hello, I'm using kernel 2.6.17.1 with vsever patch vs2.1.1-rc24. Kernel panic when i try to use strace inside vserver (i can reproduce it while straceing qmail-smtpd and/or clamd-queue proces). Oops from netconsole in attachement. Jarek Dylag [42949720.46] [ cut here ] [42949720.46] kernel BUG at kernel/exit.c:732! [42949720.46] invalid opcode: [#1] [42949720.46] SMP [42949720.46] Modules linked in: ipt_LOG ipt_owner xt_state xt_tcpudp iptable_filter ipt_MASQUERADE iptable_nat ip_nat ip_tables x_tables af_key netconsole e100 ip_conntrack_ftp ip_conntrack nfnetlink [42949720.46] CPU:1 [42949720.46] EIP:0060:[c011bc7e]Not tainted VLI [42949720.46] EFLAGS: 00010006 (2.6.17.1p4smp.32 #1) [42949720.46] EIP is at forget_original_parent+0x1b3/0x223 [42949720.46] eax: ebx: d8a3a030 ecx: dde1eadc edx: dde1ea70 [42949720.46] esi: dde1ea70 edi: dfecea70 ebp: d46cdf48 esp: d46cdf34 [42949720.46] ds: 007b es: 007b ss: 0068 [42949720.46] Process clamd-queue (pid: 8139[#2149], threadinfo=d46cc000 task=dde1ea70) [42949720.46] Stack: d46cdf58 dde1eadc c79ade80 dde1ea70 dde1ea70 d46cdf6c c011bdb6 dde1ea70 [42949720.46] d46cdf58 d46cdf58 d46cdf58 c79ade80 d111a2c0 dde1ea70 d46cdf90 c011c2ea [42949720.46] dde1ea70 dde1ea70 0001 4700 ced10b40 4700 d46cc000 d46cdfa8 [42949720.47] Call Trace: [42949720.47] c01035c6 show_stack_log_lvl+0x7f/0x87 c0103724 show_registers+0x11f/0x188 [42949720.47] c010392d die+0x129/0x20f c04fd6b4 do_trap+0x6e/0x8a [42949720.47] c0103bf2 do_invalid_op+0x90/0x97 c0103273 error_code+0x4f/0x54 [42949720.47] c011bdb6 exit_notify+0xc8/0x26c c011c2ea do_exit+0x390/0x3dc [42949720.47] c011c3db sys_exit_group+0x0/0x12 c011c3eb sys_exit_group+0x10/0x12 [42949720.47] c01026d7 syscall_call+0x7/0xb [42949720.47] Code: 08 e9 d1 fe ff ff 8b 55 08 8b 5a 6c 89 d0 8b 0b 89 4d f0 83 c0 6c 39 c3 74 79 83 eb 74 8b 87 90 04 00 00 39 83 90 04 00 00 74 32 unparseable log message: 0f 0b dc 02 69 d6 52 c0 3b 3d 0c 52 5b c0 74 22 50 ff b7 a0 00 [42949720.47] History: SEQ: 49ee NR_CPUS: 8 [42949720.47] (#4903,*0):c048d1cf set_vx_info ca584000[#2149,85.28] @d334cd28 [42949720.47] (#48d6,*1):c048c079 clr_vx_info ca584000[#2149,78.26] @dea76328 [42949720.47] (#48e2,*2):c0116b6a set_vx_info ca584000[#2149,82.28] @d90b9f24 [42949720.47] (#4917,*3):c0116b6a set_vx_info ca584000[#2149,87.26] @dea3e424 [42949720.47] (#49db,*0):c01187e9 claim_vx_info ca584000[#2149,78.24] @ddde8550 [42949720.47] (#49ee,*1):c0103824 oops [42949720.47] (#49e7,*2):c01187e9 claim_vx_info ca584000[#2149,81.25] @dde1ea70 [42949720.47] (#49e8,*3):c0116b6a set_vx_info ca584000[#2149,81.26] @d30d9224 [42949720.47] (#49da,*0):c0116b6a set_vx_info ca584000[#2149,77.24] @dce61aa4 [42949720.47] (#49ed,*1):c012fff4 release_vx_info ca584000[#2149,83.27] @dde1ea70 [42949720.47] (#49e6,*2):c0116b6a set_vx_info ca584000[#2149,80.25] @debb74e4 [42949720.47] (#49e1,*3):c0116b6a set_vx_info ca584000[#2149,80.26] @d30d9c24 [42949720.47] (#49d9,*0):c011789c init_vx_info ca584000[#2149,76.24] @ddde89d8 [42949720.47] (#49ec,*1):c01187e9 claim_vx_info ca584000[#2149,83.26] @d8a3a030 [42949720.47] (#49e5,*2):c011789c init_vx_info ca584000[#2149,79.25] @dde1eef8 [42949720.47] (#49dc,*3):c0116b6a set_vx_info ca584000[#2149,78.25] @df58a2a4 [42949720.47] (#49d4,*0):c048c079 clr_vx_info ca584000[#2149,75.24] @dc756828 [42949720.47] (#49eb,*1):c0116b6a set_vx_info ca584000[#2149,82.26] @d30d9224 [42949720.47] (#49e2,*2):c0116c57 clr_vx_info ca584000[#2149,81.26] @debb74e4 [42949720.47] (#49c6,*3):c01187e9 claim_vx_info ca584000[#2149,76.24] @d75b4030 [42949720.47] (#49d3,*0):c048d1cf set_vx_info ca584000[#2149,74.24] @dc756828 [42949720.47] (#49ea,*1):c011789c init_vx_info ca584000[#2149,81.26] @d8a3a4b8 [42949720.47] (#49e0,*2):c01187e9 claim_vx_info ca584000[#2149,80.25] @df595a70 [42949720.47] (#49c5,*3):c0116b6a set_vx_info ca584000[#2149,75.24] @de43f7e4 [42949720.47] (#49d2,*0):c048c079 clr_vx_info ca584000[#2149,75.24] @dc756828 [42949720.47] (#49e9,*1):c0116c57 clr_vx_info ca584000[#2149,82.26] @d30d9224 [42949720.47] (#49df,*2):c0116b6a set_vx_info ca584000[#2149,79.25] @debb74e4 [42949720.47] (#49c4,*3):c011789c init_vx_info ca584000[#2149,74.24] @d75b44b8 [42949720.47] (#49d1,*0):c048d1cf set_vx_info ca584000[#2149,74.24] @dc756828 [42949720.47] (#49e4,*1):c0116c57 clr_vx_info ca584000[#2149,80.25] @d30d9c24 [42949720.47] (#49de,*2):c011789c init_vx_info ca584000[#2149,78.25] @df595ef8 [42949720.47] (#49c3,*3):c01187e9
