> Hello Herbert, > > > Herbert Poetzl wrote: > > On Fri, Mar 31, 2006 at 06:27:51PM +0100, Joel Soete wrote: > > > [snip] > >>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). > please read more detailed: with a 32bit kernel (it seems that 64bits kernel up and smp expose some unexpected hang, but that was already repoted to parisc-linux m-l), I never noticed this with parisc-cvs src tree (even if I use vps fs space as a simple chroot). i.e.: 1/ I didn't noticed (the same kernel without vserver patch) hiccup like this 2/ and fwiw I never seen dying the system like this: tones of messages like: oom-killer: gfp_mask=0xd0, order=2
Backtrace: [<10154980>] out_of_memory+0x17c/0x19c [<10156b94>] __alloc_pages+0x348/0x3a8 [<10156fcc>] __get_free_pages+0x2c/0x98 [<10123efc>] copy_process+0x18c/0x1410 [<10103db8>] do_fork+0x78/0x204 [<10109c30>] __kernel_thread+0x30/0x40 [<10121a58>] try_to_wake_up+0xe4/0x1ec [<10120800>] __wake_up_common+0x78/0xc4 [<1013d2dc>] keventd_create_kthread+0x24/0x74 [<101393a8>] run_workqueue+0x84/0x128 [<10139664>] worker_thread+0x124/0x180 [<1013d4e4>] kthread+0x144/0x14c [<10109c5c>] ret_from_kernel_thread+0x1c/0x24 Mem-info: DMA per-cpu: cpu 0 hot: high 90, batch 15 used:11 cpu 0 cold: high 30, batch 7 used:19 DMA32 per-cpu: empty Normal per-cpu: empty HighMem per-cpu: empty Free pages: 11024kB (0kB HighMem) Active:11675 inactive:11965 dirty:2 writeback:2 unstable:0 free:2756 slab:8258 mapped:23361 pagetables:14416 DMA free:11024kB min:2048kB low:2560kB high:3072kB active:46700kB inactive:47860kB present:262144kB pages_scanned:50944 all_unreclai mable? no lowmem_reserve[]: 0 0 0 0 DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 DMA: 2098*4kB 265*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 11024kB DMA32: empty Normal: empty HighMem: empty Swap cache: add 578297, delete 577842, find 50692/109462, race 98+52 Free swap = 0kB Total swap = 517480kB Free swap: 0kB 65536 pages of RAM 1725 reserved pages 232835 pages shared 455 pages swap cached Out of Memory: Kill process 1859 (sendmail) score 4190 and children. Out of memory: Killed process 2708 (exim4). oom-killer: gfp_mask=0xd0, order=2 Backtrace: [<10154980>] out_of_memory+0x17c/0x19c [<10156b94>] __alloc_pages+0x348/0x3a8 [<10156fcc>] __get_free_pages+0x2c/0x98 [<10123efc>] copy_process+0x18c/0x1410 [<10103db8>] do_fork+0x78/0x204 [<10109c30>] __kernel_thread+0x30/0x40 [<10121a58>] try_to_wake_up+0xe4/0x1ec [<10120800>] __wake_up_common+0x78/0xc4 [<1013d2dc>] keventd_create_kthread+0x24/0x74 [<101393a8>] run_workqueue+0x84/0x128 [<10139664>] worker_thread+0x124/0x180 [<1013d4e4>] kthread+0x144/0x14c [<10109c5c>] ret_from_kernel_thread+0x1c/0x24 Mem-info: DMA per-cpu: cpu 0 hot: high 90, batch 15 used:4 cpu 0 cold: high 30, batch 7 used:2 DMA32 per-cpu: empty Normal per-cpu: empty HighMem per-cpu: empty Free pages: 11072kB (0kB HighMem) Active:11803 inactive:11887 dirty:2 writeback:2 unstable:0 free:2768 slab:8253 mapped:23364 pagetables:14416 DMA free:11072kB min:2048kB low:2560kB high:3072kB active:47212kB inactive:47548kB present:262144kB pages_scanned:10295 all_unreclai mable? no lowmem_reserve[]: 0 0 0 0 DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 DMA: 2108*4kB 266*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 11072kB DMA32: empty Normal: empty HighMem: empty Swap cache: add 578352, delete 577897, find 50703/109478, race 98+52 Free swap = 0kB Total swap = 517480kB Free swap: 0kB 65536 pages of RAM 1725 reserved pages 232805 pages shared 455 pages swap cached [...] > > > >>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 > >>to 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 ;-) > So the system die the same way with or without CONFIG_DETECT_SOFTLOCKUP. (the same for 64bit kernel pb) I will check, if I can find something more helpfull? Thanks again, Joel --------------------------------------------------------------- A free anti-spam and anti-virus filter on all Scarlet mailboxes More info on http://www.scarlet.be/ _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver