Zimbra+Centos 5.3 x86 + xen = 4gb seg fixup errorerrors?

[Routers]

This doesn't work
Kernel 2.6.18-128.7.1.el5xen #1 SMP Mon Aug 24 10:08:55 EDT 2009 i686 athlon i386 GNU/Linux
zcs-5.0.18_GA_3011.RHEL5.20090707164432 CentOS5 FOSS

[ilsa]

True... Unfortunately x86_64 kernels arn't an option on Pentium 4 class xeons.

On the up side, now that everything is setup and going using ESXi, it's been very stable. Not *quite* as fast as I would like, but it works.

[Routers]

for this moment i dont know what to do, either have to wait zimbra release 5~20 or wait kernel update or something else , btw no option to downgrade zcs

maybe no harm to ignore this error

[jkstark]

There does not seem to be any irrevocable harm in ignoring the message, but boy, does it cause a heavy load on the logger...

This REALLY needs a fix; from all that I can tell, this could be fixed with a newer release of slapd, or am I wrong in that thought?

Something is really odd about this though since prior to my upgrade to 6.0, this was not a problem in nearly the same way - either that, or I've got a different issue as well... With 5, I was getting the same 'fixup' messages, but they were primarily suppressed by the system (OS) logger, and did not seem to in any way cause issues with ZCS. With 6, logger is eating up a huge chunk of CPU resources that I must almost assume is related to the 'fixup' errors...

Kris

[rolandbreedveld]

After upgrade to Zimbra 6.0 and now 6.01 having the same problem
system is a CentOS Xen-image: 2.6.18-164.el5xen
taking 2 much cpu-time :-(

Sep 28 17:47:47 mailserver kernel: printk: 27 messages suppressed.
Sep 28 17:47:47 mailserver kernel: 4gb seg fixup, process slapd (pid 19397), cs:ip 73:00b727cb
Sep 28 17:47:47 mailserver kernel: 4gb seg fixup, process slapd (pid 19397), cs:ip 73:009ad71f
Sep 28 17:47:47 mailserver kernel: 4gb seg fixup, process slapd (pid 19397), cs:ip 73:00b727cb

echo "hwcap 0 nosegneg" > /etc/ld.so.conf.d/nosegneg.conf
and ldconfig is NOT working, is slapd using this file ??

ldd slapd |grep libc
libcrypto.so.0.9.8 => /opt/zimbra/openssl-0.9.8k/lib/libcrypto.so.0.9.8 (0x00126000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00700000)
libc.so.6 => /lib/i686/nosegneg/libc.so.6 (0x00434000)

i did find 2 libs:
/lib/libc.so.6
/lib/i686/nosegneg/libc.so.6

[Routers]

looks like unresolved problem , upgrading still no luck with this issue

[quanah]

This error is clearly a Xen problem. I'm not sure what the solution is. Have you read over:

LKML: Roland McGrath: Re: [PATCH 03/25] xen: Add nosegneg capability to the vsyscall page notes

and

Troubleshooting - PrgmrWiki

?

[ilsa]

Originally Posted by quanah

This error is clearly a Xen problem. I'm not sure what the solution is. Have you read over:

LKML: Roland McGrath: Re: [PATCH 03/25] xen: Add nosegneg capability to the vsyscall page notes

and

Troubleshooting - PrgmrWiki

?

There's no point complaining to Zimbra about it. Rather than making an effort to help customers deal with the problem, they'd rather just blame someone else or suggest other untenable solutions like "use a 64-bit hypervisor". (If I was able to use a 64-bit HV from the start, don't you think I'd be doing so already?)

[quanah]

Originally Posted by ilsa

There's no point complaining to Zimbra about it. Rather than making an effort to help customers deal with the problem, they'd rather just blame someone else or suggest other untenable solutions like "use a 64-bit hypervisor". (If I was able to use a 64-bit HV from the start, don't you think I'd be doing so already?)

I spent a lot of time researching the issue you reported in Bug 39498 – Xen: 4gb seg fixup, process slapd immediately after install. It is a well known problem with the issue of Xen you choose to use. Since you won't use the stable known good version of Xen, there's not much further that can be done to help you.

[phoenix]

Originally Posted by ilsa

There's no point complaining to Zimbra about it.

Correct, you should complain on the xen mailing lists about the problem. Have you posted your problem there, did you read the links that you've quoted?

Originally Posted by ilsa

Rather than making an effort to help customers deal with the problem, they'd rather just blame someone else or suggest other untenable solutions like "use a 64-bit hypervisor". (If I was able to use a 64-bit HV from the start, don't you think I'd be doing so already?)

There is nothing that can be done with this until, or if, the xen developers fix the problem. You do realise that Zimbra has never been supported on xen and never will be on the 32 bit platform.