Re: [Vserver] kernel bug

Andreas Baetz wrote:
>> On Tuesday 28 November 2006 15:54, Herbert Poetzl wrote:
>>> On Tue, Nov 28, 2006 at 08:11:35AM +0100, Andreas Baetz wrote:
>>>> On Sunday 26 November 2006 23:22, Herbert Poetzl wrote:
>>>>> On Fri, Nov 24, 2006 at 08:11:39AM +0100, Andreas Baetz wrote:
>>>>>> On Thursday 23 November 2006 18:49, Herbert Poetzl wrote:
>>>>>>> On Thu, Nov 23, 2006 at 02:43:13AM +0100, Herbert Poetzl wrote:
>>>>>>>> thanks, should be fixed in the next release
>>>>>>> vs2.0.2.2-rc8 is out ...
>>>>>> I tried vs2.0.2.2-rc8 with 2.6.18.3, the vserver starts ok, no
>>>>>> errors, but when I stopped it, the whole system freezed.
>>>>>> Right after "Deconfiguring network interfaces...done."
>>>>> okay, maybe you get around, the stack trace of
>>>>> all processes would probably tell us more ...
>>>> I wrote down some of the trace output by hand:
>>> hmm, the numbers of those dumps would be interesting,
>>> especially if you have an unstripped kernel (vmlinux)
>>> available, so we can figure _where_ this happens
>>>
>>> so a serial console or some other means of recording
>>> them would be very helpful, if not available, try
>>> with a photo camera ...
>>>
>> I did some more tests:
>> At console 1:
>> host:~# vserver deb4 enter
>> deb4:/#
>>
>> .. Then I stopped all services in deb4 ..
>>
>> deb4:/# ps ax
>> PID TTY STAT TIME COMMAND
>> 1 ? Ss 0:00 init [2]
>> 4999 ? S+ 0:00 login
>> 5023 pts/0 Ss 0:00 /bin/bash -login
>> 5043 pts/0 R+ 0:00 ps ax
>>
>> At console 2:
>> host:~# vps ax|grep 8004
>> 4999 8004 deb4 tty3 S+ 0:00 login
>>
>> 5023 8004 deb4 pts/0 Ss+ 0:00 /bin/bash -login
>> 5049 0 MAIN tty2 S+ 0:00 grep 8004
>>
>> At console 1:
>> deb4:/# <hit CTRL-D>
>>
>> EIP: [<e2fd8894>] 0xe2fd8894 SS:ESP 0068:e4711f20
>> <1>Fixing recursive fault but reboot is needed!
>> host kernel: Oops: 0002 [#1]
>> host kernel: PREEMPT
>> host kernel: CPU: 0
>> host kernel: EIP is at 0xe2fd8894
>> host kernel: eax: e2fd8888 ebx: e2fd8930 ecx: 00000001 edx: 00000001
>> host kernel: esi: 00000000 edi: e2fd8890 ebp: e4711f48 esp: e4711f20
>> host kernel: ds: 007b es: 007b ss: 0068
>> host kernel: Process vcontext (pid: 4638[#8004], ti=e4710000 task=e4334ab0 task.ti=e4710000)
>> host kernel: Stack: c01195e3 e2fd8888 00000001 00000000 00000000 00000001 00000001 00000000
>> host kernel: 00000001 00000286 e4711f6c c011b1af 00000000 00000000 00000001 e2fd8890
>> host kernel: e4711f9c e4334ab0 00000010 c17efa90 c01224b9 00000000 00000000 c011ac30
>> host kernel: Call Trace:
>> host kernel: Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 94 88 fd e2 <30> 89 fd e2 02 00 00 00 00 00 00 00 2f 65 74 63 2f 76 73 65 72
>> host kernel: EIP: [<e2fd8894>] 0xe2fd8894 SS:ESP 0068:e4711f20
>
> some more info:
> I copied the / of a working vserver and used it as / of deb4.
> "vserver deb4 stop" now works.
> It seems that something inside the / of the old deb4 is causing
> the system to crash when no more processes are running with that xid.
>
> So if a user of a certain vserver manages to create that condition in a vserver,
> then ending all processes in that vserver, the user could manage to crash the host.

And what condition is that, exactly? Without a complete trace or at
least a way to reproduce this, it's going to be pretty much impossible
to fix it. Would it be possible for you to tar up the whole guest and
upload it somewhere? Or setup a serial console so catch the previous
Oops (which would hopefully have a usable stack trace)?

-- 
Daniel Hokka Zakrisson
GPG id: 06723412
GPG fingerprint: A455 4DF3 990A 431F FECA  7947 6136 DDA2 0672 3412
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver