"4gb seg fixup, process X" on FC6 dom0

[Jim McBeath]

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 ~]#

[Asrai khn]

Yes there is a fix for this you can find the solution in the archives

http://www.mail-archive.com/[e-mail]/msg00053.html

Thanks. Askar

On 1/19/07, Jim McBeath  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
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-xen

[Jim McBeath]

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" 
> To: [e-mail]
> 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/[e-mail]/msg00053.html
>    Thanks. Askar
>
> On 1/19/07, Jim McBeath  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]

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" 
> > To: [e-mail]
> > 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/[e-mail]/msg00053.html
> >    Thanks. Askar
> >
> > On 1/19/07, Jim McBeath  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
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-xen

xm list broken in xen 3.0.3-3

[Mike Freemon]

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 
([e-mail]) (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

xm list broken in xen 3.0.3-3

[Daniel P. Berrange]

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.

xm list broken in xen 3.0.3-3

[Asrai khn]

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  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.  [phone]
> -=|
> |=-           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
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-xen

xm list broken in xen 3.0.3-3

[Bill Davidsen]

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.