On Sat, Aug 06, 2011 at 01:54:39PM +0200, Urban Loesch wrote:
> Hi Herbert,
> thanks for your fast reponse.
>>> [1462582.761420] general protection fault: 0000 [#1] SMP
>>> [1462582.771684] last sysfs file:
>>> /sys/devices/pci0000:00/0000:00:1c.0/0000:03:00.0/host2/scsi_host/host2/proc_name
>>> [1462582.791973] CPU 5
>>> [1462582.795965] Modules linked in: ufs qnx4 hfsplus hfs
>>> minix ntfs vfat msdos fat jfs xfs exportfs netconsole drbd
>> quite a number of filesystems you have :)
> Thanks for the hint. I must review my hole kernel config asap. I don't
> need them all :-)
> Do you have a custom kernel config which I can use? I only use DELL
> Servers (PEx9xx and PERx10 models).
>>> please try to feed those addresses and the one below (RIP) through
> addr2line -e vmlinux (using the build tree of that kernel)
> I'm not an expert in kernel debugging. So please excuse me if the
> following information is not that what you expect.
> [1462583.323969] Call Trace:
> [1462583.329191] [<ffffffff8105cfbc>] try_to_wake_up+0x3c/0x410
> [1462583.340642] [<ffffffff8105d3e5>] wake_up_process+0x15/0x20
> [1462583.352091] [<ffffffff812710e0>] freeary+0x1e0/0x260
> [1462583.362503] [<ffffffff812721b1>] T.623+0x71/0xf0
> [1462583.372223] [<ffffffff81169685>] ? vfs_write+0x125/0x190
> [1462583.383326] [<ffffffff81272299>] sys_semctl+0x69/0xa0
> [1462583.393911] [<ffffffff8100bf82>] system_call_fastpath+0x16/0x1b
> Result of "addr2line -e vmlinux $ADDRESS":
> ffffffff8105cfbc:
> sched.c:0
> ffffffff8105d3e5:
> ??:0
> ffffffff812710e0:
> sem.c:0
> ffffffff812721b1:
> sem.c:0
> ffffffff81169685:
> ??:0
> ffffffff81272299:
> ??:0
> ffffffff8100bf82:
> signal.c:0
your kernel (or at least the vmlinux) file seems to be
missing the necessary debug information (which isn't
that unusual, as most folks compile the kernel without,
which of course makes debugging the kernel a little
tricker :)
> And the same with RIP:
> [1462583.444912] RIP [<ffffffff8104ecaa>] task_rq_lock+0x4a/0xa0
> [1462583.456545] RSP <ffff88041e259dc8>
> [1462583.464160] ---[ end trace e26d734810b28493 ]---
> Result:
> ffffffff8104ecaa:
> sched.c:0
>> might be fixed in .41 or might just be less likely to
>> happen, after all, 16 days is not something you consider
>> easily reproduceable ...
> Not shure, but my other server with .41 runs since 38 days
> without problems and with a apache installed.
it might be interesting to find what exactly triggers
this and maybe test with some more extreme apache
setups, like for example having a lot more threads or
handling high load (web test or similar)
>> in any case, it doesn't really look Linux-VServer specific,
>> but let's see what the addr2line gives ...
> I think you are right.
> I have running more than 10 servers with kernel 2.6.28.[4-7]
I presume this should be 2.6.38.x ...
> and linux vserver patch. 2 of them are running since 100 days
> without problems. The rest of them are running since 60 days
> or less. The only difference is, that they all have no apache
> running. Only postfix, amavis, mysql 5.1, dovecot 2, etc.
best,
Herbert
> Many thanks,
> Urban
Received on Sat Aug 6 13:06:45 2011