Herbert Poetzl wrote:
> On Fri, Mar 31, 2006 at 06:27:51PM +0100, Joel Soete wrote:
>>That said do you remember how much 'new' is this option (I don't have
>>enough space to save all kernel and config ;<( )?
>>Well some time ago (I find back: around 2.6.12-rc1), I already
>>did 'just disable' a debug option, in the hope that works better:
>>the actual effect was just disable to printout "BUG ..." but the
>>underground bug effect was always there and kernel still missbehave.
> not disabling the de'bug' option, but the hang check
> and probably submitting something to lkml so that
> folks there could look into it ...
> at least I assume this happens with a vanilla kernel
> too, if not, please let me know ...
I never noticed this with parisc cvs tree, even when I use vps as a simple chroot (with just starting cron).
>>But that's a long time ago and as you're the second to 'just want to
>>disable this feature', I need to test.
>>The first thing is that, the system behaviour is still heratic:
>> 1/ at the console a return can answer immediately or about 30s later?
>> 2/ the same in a ssh connection: ls, vserver-stat ; sometime immediate
>>answer, sometime wait (even in the midle of the type of the cmdl)
>> 3/ I reach to enter a vps (awaiting about 20min) but responding from time
>> 4/ but the system is still alive.... let it run the w-e
> sounds like a major scheduling issue ...
Not sure what hapen: when the system was a bit responsive, I launch a top and some time showing me about 50 cron child process,
and/or more then 20 logcheck process, also even before I started a vps server (so I presume to be a pb related to kernel, don't know
exactely what, much then the fact that I use glibc, dietlibc not availble for parisc, to build utils-vserver tools)?
I will check on monday if system is still alive ;-)
Vserver mailing list
Received on Sat Apr 1 18:59:18 2006