I am running a stock FC6 xen, with all yum updates through today, on a Shuttle box with a Core 2 Duo and 2GB of memory. I am getting "4gb seg fixup" for plenty of programs, including X, sh, ls, date, grep, less, ssh, su and vim. This is in dom0, with no domU running. The worst offender is X: in /var/log/messages, every five seconds it consistently logs something like this: Jan 18 19:34:59 gumby kernel: printk: 30302 messages suppressed. Jan 18 19:34:59 gumby kernel: 4gb seg fixup, process X (pid 4383), cs:ip 73:47150f2a 20,000 is typical for the number of messages suppressed. It varies in different five-second intervals from about 10,000 to 89,000. I have poked around on the net and searched through the archives for this group, without finding an answer. I have seen a few posts about 4gb-seg-fixup messages in domU, or from mono programs, or from older OSs that needed a "nosegneg" file in /etc/ld.so.conf.d, but none of those seem to apply here. Any suggestions? -- Jim McBeath [root@gumby ~]# uname -a Linux gumby.local 2.6.19-1.2895.fc6xen #1 SMP Wed Jan 10 19:47:12 EST 2007 i686 i686 i386 GNU/Linux [root@gumby ~]# ls /etc/ld.so.conf.d kernelcap-2.6.18-1.2869.fc6.conf mysql-i386.conf kernelcap-2.6.19-1.2895.fc6.conf qt-i386.conf [root@gumby ~]# cat /etc/ld.so.conf.d/kernelcap-2.6.19-1.2895.fc6.conf # This directive teaches ldconfig to search in nosegneg subdirectories # and cache the DSOs there with extra bit 0 set in their hwcap match # fields. In Xen guest kernels, the vDSO tells the dynamic linker to # search in nosegneg subdirectories and to match this extra hwcap bit # in the ld.so.cache file. hwcap 0 nosegneg [root@gumby ~]#
Yes there is a fix for this you can find the solution in the archives http://www.mail-archive.com/fedora-xen@redhat.com/msg00053.html Thanks. Askar On 1/19/07, Jim McBeath <fedora-xen@j.jimmc.org> wrote:> > I am running a stock FC6 xen, with all yum updates through today, on a > Shuttle box with a Core 2 Duo and 2GB of memory. I am getting "4gb seg > fixup" for plenty of programs, including X, sh, ls, date, grep, less, > ssh, su and vim. This is in dom0, with no domU running. > > The worst offender is X: in /var/log/messages, every five seconds > it consistently logs something like this: > > Jan 18 19:34:59 gumby kernel: printk: 30302 messages suppressed. > Jan 18 19:34:59 gumby kernel: 4gb seg fixup, process X (pid 4383), cs:ip > 73:47150f2a > > 20,000 is typical for the number of messages suppressed. It varies in > different five-second intervals from about 10,000 to 89,000. > > I have poked around on the net and searched through the archives > for this group, without finding an answer. I have seen a few posts > about 4gb-seg-fixup messages in domU, or from mono programs, or from > older OSs that needed a "nosegneg" file in /etc/ld.so.conf.d, but > none of those seem to apply here. > > Any suggestions? > > -- > Jim McBeath > > > [root@gumby ~]# uname -a > Linux gumby.local 2.6.19-1.2895.fc6xen #1 SMP Wed Jan 10 19:47:12 EST 2007 > i686 i686 i386 GNU/Linux > [root@gumby ~]# ls /etc/ld.so.conf.d > kernelcap-2.6.18-1.2869.fc6.conf mysql-i386.conf > kernelcap-2.6.19-1.2895.fc6.conf qt-i386.conf > [root@gumby ~]# cat /etc/ld.so.conf.d/kernelcap-2.6.19-1.2895.fc6.conf > # This directive teaches ldconfig to search in nosegneg subdirectories > # and cache the DSOs there with extra bit 0 set in their hwcap match > # fields. In Xen guest kernels, the vDSO tells the dynamic linker to > # search in nosegneg subdirectories and to match this extra hwcap bit > # in the ld.so.cache file. > hwcap 0 nosegneg > [root@gumby ~]# > > -- > Fedora-xen mailing list > Fedora-xen@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-xen >
Thanks for responding, Askar. I saw that thread, and those fixes
are not working for me. My system already had the nosegneg file in
/etc/ld.so.conf.d (it was installed there along with the kernel, so that
issue has been fixed in the sources), and ldconfig shows that the system
knows about it:
# ldconfig -N -X -p | grep libc.so
libc.so.6 (libc6, hwcap: 0x0018000000000000, OS ABI: Linux 2.6.9) =>
/lib/i686/nosegneg/libc.so.6
libc.so.6 (libc6, OS ABI: Linux 2.6.9) => /lib/libc.so.6
The messages are coming from non-mono processes, so that''s not it
either.
Perhaps a problem with dual cpu being used with Xen and FC6?
Is there anyone else out there running Xen and FC6 on a Core 2 Duo who
can report not having this problem?
--
Jim
On Sun, Jan 21, 2007 at 09:20:02PM +0500, Asrai khn
wrote:> Date: Sun, 21 Jan 2007 21:20:02 +0500
> From: "Asrai khn" <asraikhn@gmail.com>
> To: fedora-xen@redhat.com
> Subject: Re: [Fedora-xen] "4gb seg fixup, process X" on FC6 dom0
>
>
> Yes there is a fix for this you can find the solution in the archives
> http://www.mail-archive.com/fedora-xen@redhat.com/msg00053.html
> Thanks. Askar
>
> On 1/19/07, Jim McBeath <fedora-xen@j.jimmc.org> wrote:
>
> I am running a stock FC6 xen, with all yum updates through today, on a
> Shuttle box with a Core 2 Duo and 2GB of memory. I am getting
"4gb seg
> fixup" for plenty of programs, including X, sh, ls, date, grep,
less,
> ssh, su and vim. This is in dom0, with no domU running.
> The worst offender is X: in /var/log/messages, every five seconds
> it consistently logs something like this:
> Jan 18 19:34:59 gumby kernel: printk: 30302 messages suppressed.
> Jan 18 19:34:59 gumby kernel: 4gb seg fixup, process X (pid 4383),
cs:ip
> 73:47150f2a
> 20,000 is typical for the number of messages suppressed. It varies in
> different five-second intervals from about 10,000 to 89,000.
> I have poked around on the net and searched through the archives
> for this group, without finding an answer. I have seen a few posts
> about 4gb-seg-fixup messages in domU, or from mono programs, or from
> older OSs that needed a "nosegneg" file in
/etc/ld.so.conf.d, but
> none of those seem to apply here.
> Any suggestions?
> --
> Jim McBeath
> [root@gumby ~]# uname -a
> Linux gumby.local 2.6.19-1.2895.fc6xen #1 SMP Wed Jan 10 19:47:12 EST
2007
> i686 i686 i386 GNU/Linux
> [root@gumby ~]# ls /etc/ld.so.conf.d
> kernelcap-2.6.18-1.2869.fc6.conf mysql-i386.conf
> kernelcap-2.6.19-1.2895.fc6.conf qt-i386.conf
> [root@gumby ~]# cat /etc/ld.so.conf.d/kernelcap-2.6.19-1.2895.fc6.conf
> # This directive teaches ldconfig to search in nosegneg subdirectories
> # and cache the DSOs there with extra bit 0 set in their hwcap match
> # fields. In Xen guest kernels, the vDSO tells the dynamic linker to
> # search in nosegneg subdirectories and to match this extra hwcap bit
> # in the ld.so.cache file.
> hwcap 0 nosegneg
> [root@gumby ~]#
Mike Freemon
2007-Jan-22 17:13 UTC
Re: [Fedora-xen] "4gb seg fixup, process X" on FC6 dom0
At 1/21/2007 02:49 PM Sunday, Jim McBeath wrote:>Thanks for responding, Askar. I saw that thread, and those fixes >are not working for me. My system already had the nosegneg file in >/etc/ld.so.conf.d (it was installed there along with the kernel, so that >issue has been fixed in the sources), and ldconfig shows that the system >knows about it: > ># ldconfig -N -X -p | grep libc.so > libc.so.6 (libc6, hwcap: 0x0018000000000000, OS ABI: Linux 2.6.9) => > /lib/i686/nosegneg/libc.so.6 > libc.so.6 (libc6, OS ABI: Linux 2.6.9) => /lib/libc.so.6 > >The messages are coming from non-mono processes, so that''s not it either. > >Perhaps a problem with dual cpu being used with Xen and FC6? > >Is there anyone else out there running Xen and FC6 on a Core 2 Duo who >can report not having this problem? > >-- >Jim > >On Sun, Jan 21, 2007 at 09:20:02PM +0500, Asrai khn wrote: > > Date: Sun, 21 Jan 2007 21:20:02 +0500 > > From: "Asrai khn" <asraikhn@gmail.com> > > To: fedora-xen@redhat.com > > Subject: Re: [Fedora-xen] "4gb seg fixup, process X" on FC6 dom0 > > > > > > Yes there is a fix for this you can find the solution in the archives > > http://www.mail-archive.com/fedora-xen@redhat.com/msg00053.html > > Thanks. Askar > > > > On 1/19/07, Jim McBeath <fedora-xen@j.jimmc.org> wrote: > > > > I am running a stock FC6 xen, with all yum updates through today, on a > > Shuttle box with a Core 2 Duo and 2GB of memory. I am getting > "4gb seg > > fixup" for plenty of programs, including X, sh, ls, date, grep, less, > > ssh, su and vim. This is in dom0, with no domU running. > > The worst offender is X: in /var/log/messages, every five seconds > > it consistently logs something like this: > > Jan 18 19:34:59 gumby kernel: printk: 30302 messages suppressed. > > Jan 18 19:34:59 gumby kernel: 4gb seg fixup, process X (pid > 4383), cs:ip > > 73:47150f2a > > 20,000 is typical for the number of messages suppressed. It varies in > > different five-second intervals from about 10,000 to 89,000. > > I have poked around on the net and searched through the archives > > for this group, without finding an answer. I have seen a few posts > > about 4gb-seg-fixup messages in domU, or from mono programs, or from > > older OSs that needed a "nosegneg" file in /etc/ld.so.conf.d, but > > none of those seem to apply here. > > Any suggestions? > > -- > > Jim McBeath > > [root@gumby ~]# uname -a > > Linux gumby.local 2.6.19-1.2895.fc6xen #1 SMP Wed Jan 10 19:47:12 > EST 2007 > > i686 i686 i386 GNU/Linux > > [root@gumby ~]# ls /etc/ld.so.conf.d > > kernelcap-2.6.18-1.2869.fc6.conf mysql-i386.conf > > kernelcap-2.6.19-1.2895.fc6.conf qt-i386.conf > > [root@gumby ~]# cat /etc/ld.so.conf.d/kernelcap-2.6.19-1.2895.fc6.conf > > # This directive teaches ldconfig to search in nosegneg subdirectories > > # and cache the DSOs there with extra bit 0 set in their hwcap match > > # fields. In Xen guest kernels, the vDSO tells the dynamic linker to > > # search in nosegneg subdirectories and to match this extra hwcap bit > > # in the ld.so.cache file. > > hwcap 0 nosegneg > > [root@gumby ~]# > >-- >Fedora-xen mailing list >Fedora-xen@redhat.com >https://www.redhat.com/mailman/listinfo/fedora-xen
When upgrading from xen-3.0.3-2 to xen-3.0.3-3, the xm list command breaks with the following error: # xm list Name ID Mem(MiB) VCPUs State Time(s) Error: method "xend.domain.getSysMem" is not supported Usage: xm list [options] [Domain, ...] List information about all/some domains. -l, --long Output all VM details in SXP --label Include security labels It looks like the getSysMem functionality changed. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=649 Is there a new version of the xen-3.0.3 package in updates-testing planned? # rpm -qa|grep xen kernel-xen0-2.6.18-1.2239.fc5 kernel-xen0-2.6.18-1.2257.fc5 xen-3.0.3-3.fc5 # rpm -qa|grep libvirt libvirt-python-0.1.7-3.FC5 libvirt-0.1.7-3.FC5 # dmesg|head Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00 rhgb quiet) Linux version 2.6.18-1.2257.fc5xen0 (brewbuilder@ls20-bc1-13.build.redhat.com) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Fri Dec 15 17:06:13 EST 2006 BIOS-provided physical RAM map: Xen: 0000000000000000 - 00000001f0e11000 (usable) On node 0 totalpages: 2035217 DMA zone: 2035217 pages, LIFO batch:31 DMI 2.4 present. ACPI: RSDP (v002 DELL ) @ 0x00000000000f2a00 ACPI: XSDT (v001 DELL PE_SC3 0x00000001 DELL 0x00000001) @ 0x00000000000f2a80 ACPI: FADT (v003 DELL PE_SC3 0x00000001 DELL 0x00000001) @ 0x00000000000f2b88 TIA, - Mike
On Mon, Jan 22, 2007 at 11:18:16AM -0600, Mike Freemon wrote:> When upgrading from xen-3.0.3-2 to xen-3.0.3-3, the xm list command breaks > with the following error:You need to restart XenD (or reboot the host). We didn''t automatically resart XenD in the %post script because that doesn''t play nicely if you have any fullvirt guests running :-(> Name ID Mem(MiB) VCPUs State Time(s) > Error: method "xend.domain.getSysMem" is not supported > Usage: xm list [options] [Domain, ...] > > List information about all/some domains. > -l, --long Output all VM details in SXP > --label Include security labels > > It looks like the getSysMem functionality changed.Its a new function actually - previous ''xm list'' just reported what you''d told XenD to give the guest - this was not the same as what the guest was actually allocated by the HV. The new getSysMem function is used to make xm list show the correct (actual) allocation Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Exactly need to reboot xend service, this happend to me also but when i ... service xend restart xm list starting working fine Thanks. Askar On 1/22/07, Daniel P. Berrange <berrange@redhat.com> wrote:> > On Mon, Jan 22, 2007 at 11:18:16AM -0600, Mike Freemon wrote: > > When upgrading from xen-3.0.3-2 to xen-3.0.3-3, the xm list command > breaks > > with the following error: > > You need to restart XenD (or reboot the host). We didn''t automatically > resart > XenD in the %post script because that doesn''t play nicely if you have any > fullvirt guests running :-( > > > Name ID Mem(MiB) VCPUs State > Time(s) > > Error: method "xend.domain.getSysMem" is not supported > > Usage: xm list [options] [Domain, ...] > > > > List information about all/some domains. > > -l, --long Output all VM details in SXP > > --label Include security labels > > > > It looks like the getSysMem functionality changed. > > Its a new function actually - previous ''xm list'' just reported what you''d > told XenD to give the guest - this was not the same as what the guest was > actually allocated by the HV. The new getSysMem function is used to make > xm list show the correct (actual) allocation > > Dan. > -- > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 > -=| > |=- Perl modules: http://search.cpan.org/~danberr/ > -=| > |=- Projects: http://freshmeat.net/~danielpb/ > -=| > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B > 9505 -=| > > -- > Fedora-xen mailing list > Fedora-xen@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-xen >
Daniel P. Berrange wrote:> On Mon, Jan 22, 2007 at 11:18:16AM -0600, Mike Freemon wrote: > >> When upgrading from xen-3.0.3-2 to xen-3.0.3-3, the xm list command breaks >> with the following error: >> > Its a new function actually - previous ''xm list'' just reported what you''d > told XenD to give the guest - this was not the same as what the guest was > actually allocated by the HV. The new getSysMem function is used to make > xm list show the correct (actual) allocation >Dan, thanks much for the reason behind the solution. "Just reboot" is so Windows, it''s nice to understand why in this case it really is needed. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979