F7 clone of bug #215201. +++ This bug was initially created as a clone of Bug #215201 +++ Description of problem: After upgrading to FC6 the following shows up in syslog: > 4gb seg fixup, process compiz (pid 1162), cs:ip 73:008d8cfc > printk: 185714 messages suppressed. The mentioned URL suggests: > echo 'hwcap 0 nosegneg' > /etc/ld.so.conf.d/libc6-xen.conf > Should this go to the fedora folks? > So, yes, it would seem? As the spec file for the xen rpm should make > the ld.so adjustment above, right? For practical purposes I reverted to FC4, so I haven't been able to test it myself. Version-Release number of selected component (if applicable): kernel-xen-2.6.18-1.2798.fc6.i686.rpm How reproducible: 100% Steps to Reproduce: 1. Install FC6 2. Use Compiz 3. Enjoy the syslog messages Actual results: A lot of messages Expected results: No messages Additional info: I searched bugzilla for similar reports, and havent found any. Experience makes me expect however that this will be classified as a duplicate. -- Additional comment from rs.spam.futz.org on 2006-11-15 14:55 EST -- This is also occurring on FC5 (2.6.18-1.2239.fc5xenU), with various components. nash-hotplug and pvscan are the 2 I've seen most recently. This is with /etc/ld.conf.so.d/kernelcap-2.6.18-1.2239.fc5.conf containing hwcap 0 nosegneg -- Additional comment from bugzilla-redhat on 2006-11-25 06:00 EST -- I can confirm seeing this bug on a fresh install of FC6 running Xen kernels. Compiz was the biggest culprit, but after killing the Desktop Effects feature, I still see entries for Xorg at system boot and "gnome-screensav" whenever the screensaver kicks in. I also have "hwcap 0 nosegneg" in the appropriate /etc/ld.conf.so.d/kernelcap-$(uname -r).conf file. Will gladly provide more information as necessary. -- Additional comment from rolf.fokkens on 2006-11-27 03:54 EST -- Currently I have "hwcap 0 nosegneg" in /etc/ld.so.conf.d/libc6-xen.conf: [root@home01 ~]# grep "4gb seg fixup" /var/log/messages | awk '{ print $10 }' | sort | uniq -c 22 beagle-build-in 15481 beagled 1104 beagled-helper 24 compiz 24 gnome-screensav 1 mkinitrd 1 mono 131 prelink 5 sh 18 yum [root@home01 ~]# I just reenabled compiz, which explains the low count. -- Additional comment from jwest on 2006-12-08 00:47 EST -- I also have "hwcap 0 nosegneg" in /etc/ld.so.conf.d/libc6-xen.conf [root@fc6test ~]# grep "4gb seg fixup" /var/log/messages | awk '{ print $10 }'|sort | uniq -c 1 amarokapp 42 beagle-build-in 39128 beagled 3024 beagled-helper 25848 beryl 13 glxinfo 49 gnome-screensav 22 mono 1 mplayer 1 prelink 39 Xorg I've also seen the same messages on RHEL5 Beta2 just as a note. -- Additional comment from jan.kratochvil on 2006-12-22 18:27 EST -- I believe this Bug is a duplicate of RHEL5 glibc Bug 220675. This Bug should get rechecked after its fix. Please check your environment variable `LD_LIBRARY_PATH'. -- Additional comment from redhat on 2007-01-03 06:54 EST -- Apologies for adding to this bug if it is irrelevant, but I get the same messages.. I reckon that my machine has 2GB memory, while 'cat /proc/meminfo' tells me I have only MemTotal of 1020Mb (on Xen0). The LowTotal value tells me I have 4TB (!) of memory. I am curious if this has something to do with this bug report? Otherwise I will report a new bug with more details. -- Additional comment from jan.kratochvil on 2007-01-03 07:02 EST -- (In reply to comment #6) > I am curious if this has something to do with this bug report? Otherwise I will > report a new bug with more details. It looks really unrelated. Please attach all the relevant files, like /var/log/dmesg, /proc/meminfo, /proc/cmdline, /var/log/xen/baloon (?), /etc/grub.conf or others you will find relevant. -- Additional comment from berrange on 2007-01-03 07:22 EST -- wrt to comment #6 > Apologies for adding to this bug if it is irrelevant, > but I get the same messages.. > > I reckon that my machine has 2GB memory, while 'cat /proc/meminfo' > tells me I have only MemTotal of 1020Mb (on Xen0). > > The LowTotal value tells me I have 4TB (!) of memory. This is totally unrelated to the '4gb fixup' messages - please create a separate bug if you wish to pursue your issue in comment #6. -- Additional comment from bjohnson on 2007-02-16 06:13 EST -- It seems that this problem was fixed in RHEL5-rc1 about a week ago. Can we get it propogated to FC6/devel?? -- Additional comment from jan.kratochvil on 2007-02-16 06:57 EST -- (In reply to comment #9) > It seems that this problem was fixed in RHEL5-rc1 about a week ago. Can we get > it propogated to FC6/devel?? Could you be more specific? Running on RawHide (devel) and no messages are seen. glibc-2.5.90-17.i686 kernel-xen-2.6.19-1.2898.2.3.fc7.i686 -- Additional comment from bjohnson on 2007-02-16 07:16 EST -- (In reply to comment #10) > Could you be more specific? Running on RawHide (devel) and no messages are seen. > glibc-2.5.90-17.i686 > kernel-xen-2.6.19-1.2898.2.3.fc7.i686 glibc-2.5-10.fc6 kernel-xen-2.6.19-1.2911.fc6 I haven't checked rawhide, but my FC6 box (fully updated) spits out a continuous stream of messages. By the requirements of http://fedoraproject.org/wiki/Legacy/Mock I had kernel.vdso=0 on my system. I just checked changing that (undefined -> kernel.vdso=1) and that had no effect. Are you implying that this bug should be fixed for FC6? -- Additional comment from jan.kratochvil on 2007-02-16 19:34 EST -- Confirming it is a valid FC6+devel Bug. Fix of Bug 220675 (RHEL5) should be ported. (My Comment 10 was not right.) See the offset 0x490 according to Jakub's Bug 220675 Comment 2: kernel-xen-2.6.18-8.el5.i686 (RHEL5, correct) objdump -s -j .note /tmp/vdso /tmp/vdso: file format elf32-i386 Contents of section .note: 0460 06000000 04000000 00000000 4c696e75 ............Linu 0470 78000000 12060200 04000000 12000000 x............... 0480 02000000 474e5500 01000000 01000000 ....GNU......... 0490 006e6f73 65676e65 67000000 .nosegneg... kernel-xen-2.6.19-1.2911.fc6.i686 (FC6, incorrect) objdump -s -j .note /tmp/vdso /tmp/vdso: file format elf32-i386 Contents of section .note: 0460 06000000 04000000 00000000 4c696e75 ............Linu 0470 78000000 13060200 04000000 12000000 x............... 0480 02000000 474e5500 01000000 01000000 ....GNU......... 0490 016e6f73 65676e65 67000000 .nosegneg... kernel-xen-2.6.19-1.2898.2.3.fc7.i686 (devel, incorrect) objdump -s -j .note /tmp/vdso /tmp/vdso: file format elf32-i386 Contents of section .note: 0460 06000000 04000000 00000000 4c696e75 ............Linu 0470 78000000 13060200 04000000 12000000 x............... 0480 02000000 474e5500 01000000 01000000 ....GNU......... 0490 016e6f73 65676e65 67000000 .nosegneg... -- Additional comment from bjohnson on 2007-03-03 12:45 EST -- *** Bug 230047 has been marked as a duplicate of this bug. *** -- Additional comment from bjohnson on 2007-03-03 12:47 EST -- This is still not resolved in: 2.6.19-1.2911.6.4.fc6 -- Additional comment from hps on 2007-04-14 12:17 EST -- Any news here? I'm seeing the same behaviour using 2.6.20-1.2312.fc5 on a fully patched FC5 machine. I have no LD_LIBRARY_PATH variable and ldconfig reports that I am using correctly the nosegneg versions: /sbin/ldconfig -N -p | grep nosegneg libthread_db.so.1 (libc6, hwcap: 0x0018000000000000, OS ABI: Linux 2.6.9) => /lib/i686/nosegneg/libthread_db.so.1 librt.so.1 (libc6, hwcap: 0x0018000000000000, OS ABI: Linux 2.6.9) => /lib/i686/nosegneg/librt.so.1 libpthread.so.0 (libc6, hwcap: 0x0018000000000000, OS ABI: Linux 2.6.9) => /lib/i686/nosegneg/libpthread.so.0 libm.so.6 (libc6, hwcap: 0x0018000000000000, OS ABI: Linux 2.6.9) => /lib/i686/nosegneg/libm.so.6 libc.so.6 (libc6, hwcap: 0x0018000000000000, OS ABI: Linux 2.6.9) => /lib/i686/nosegneg/libc.so.6 Still the messages appear on the console of the client. Running ldconfig is the easiest way to provoke it: 4gb seg fixup, process ldconfig (pid 1001), cs:ip 73:0805a702 printk: 3604 messages suppressed. 4gb seg fixup, process ldconfig (pid 1024), cs:ip 73:0805a702 4gb seg fixup, process ldconfig (pid 1024), cs:ip 73:0805a702 4gb seg fixup, process ldconfig (pid 1024), cs:ip 73:0805a702 4gb seg fixup, process ldconfig (pid 1024), cs:ip 73:0805a702 printk: 848 messages suppressed. 4gb seg fixup, process ldconfig (pid 1025), cs:ip 73:0805a702 ad infinitum, ad nauseam. -- Additional comment from bjohnson on 2007-06-09 04:30 EST -- Still not resolved in 2.6.20-2925.9.fc7xen
kernel-xen-2.6-2.6.20-2925.11.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
I am still seeing these messages with kernel-xen-2.6-2.6.20-2925.11.fc7, however, the messages only appear for mono applications (ie. beagle-helper, beagled, tomboy). Jun 12 01:17:55 localhost kernel: printk: 60 messages suppressed. Jun 12 01:17:55 localhost kernel: 4gb seg fixup, process beagled-helper (pid 2986), cs:ip 73:081192aa Jun 12 01:18:00 localhost kernel: printk: 11407 messages suppressed. Jun 12 01:18:00 localhost kernel: 4gb seg fixup, process beagled (pid 2655), cs:ip 73:081192aa Jun 12 01:18:05 localhost kernel: printk: 20081 messages suppressed. Jun 12 01:18:05 localhost kernel: 4gb seg fixup, process beagled-helper (pid 2986), cs:ip 73:081192aa Jun 12 01:18:10 localhost kernel: printk: 3676 messages suppressed. Jun 12 01:18:10 localhost kernel: 4gb seg fixup, process beagled (pid 2655), cs:ip 73:081192aa Jun 12 01:18:15 localhost kernel: printk: 239633 messages suppressed. Jun 12 01:18:15 localhost kernel: 4gb seg fixup, process beagled (pid 2655), cs:ip 73:00157514 Jun 12 01:18:20 localhost kernel: printk: 1938 messages suppressed. Jun 12 01:18:20 localhost kernel: 4gb seg fixup, process beagled-helper (pid 2986), cs:ip 73:081192aa
The fix included on 2.6.20-2925.11.fc7 won't solve the problem for the mono applications. The mono problem needs to be solved on mono. I will make a clone of the bug for the mono-specific problem.
No need to clone this bug, there is a bug against mono for this, already. For the mono "4gb seg fixup" problem, see bug #210001.
I am unable to boot kernel-xen-2.6.20-2925.11.fc7 there are lots of "4gb seg fixup" messages for init process during boot and system does not start on my notebook. "hwcap 0 nosegneg" does not help (may be becase system is not booted until this file is read).
Jan, the seg fixup messages for init were already happening when using 2.6.20-2925.9.fc7xen, or 2.6.20-2925.11.fc7 made it worse?
Only for latest updates-testing kernel 2.6.20-2925.11.fc7, but 2.6.20-2925.9.fc7xen does not work too, xend fails to start for me.
Jan, Jan, are you able to get to a shell when using 2.6.20-2925.11.fc7xen? If so, could you show the output of 'ldd /sbin/init' when running 2.6.20-2925.11.fc7xen? Other things that can be checked, just in case: - /etc/ld.so.conf must contain the line: include ld.so.conf.d/*.conf - You must have a *.conf file on /etc/ld.so.conf.d/ containing "hwcap 0 nosegneg" (this should be done automatically by the kernel-xen package %post script) - Run 'ldconfig' to make sure the ld.so.conf files are re-read (this also should be done automatically by the package, but you can run it again, just in case)
Unable to boot to "init=/bin/sh", same problem. It shows aprox. 330000-333333 messages supressed every second. [ondrejj@note ~]$ grep include /etc/ld.so.conf include ld.so.conf.d/*.conf [ondrejj@note ~]$ [ondrejj@note ~]$ grep ^hwcap /etc/ld.so.conf.d/* /etc/ld.so.conf.d/kernelcap-2.6.20-2925.11.fc7.conf:hwcap 0 nosegneg /etc/ld.so.conf.d/kernelcap-2.6.20-2925.9.fc7.conf:hwcap 0 nosegneg /etc/ld.so.conf.d/libc6-xen.conf:hwcap 0 nosegneg ldconfig has been run before, no success. Do you need more information?
This is becoming hard to understand. What is your glibc version, and the output of 'rpm -V glibc' (just to be sure you have the nosegneg libc files intact)? What is the output of 'ldd /sbin/init' when a non-xen kernel was booted? If I can't reproduce the problem here using the same kernel and glibc, we will probably need some trick to figure out which libraries are being loaded for /sbin/init at boot time (and so we know if the problem is at binary loading time, or somewhere else).
[root@note ~]# rpm -V glibc [root@note ~]# uname -a Linux note.salstar.sk 2.6.21-1.3228_1.fc7.cubbi_suspend2 #1 SMP Thu Jun 14 10:07:56 CEST 2007 i686 i686 i386 GNU/Linux [root@note ~]# ldd /sbin/init linux-gate.so.1 => (0x009b0000) libsepol.so.1 => /lib/libsepol.so.1 (0x00336000) libselinux.so.1 => /lib/libselinux.so.1 (0x00248000) libc.so.6 => /lib/libc.so.6 (0x00b78000) libdl.so.2 => /lib/libdl.so.2 (0x00d90000) /lib/ld-linux.so.2 (0x0072a000) [root@note ~]# I am using Matthias Hensler kernels with suspend2 patch for non-xen.
What is the version of the glibc package you are using (rpm -qi glibc)?
I am using all currently available updates with these repositories: fedora, updates, updates-testing, livna, swsuspend2. [root@note ~]# rpm -qi glibc Name : glibc Relocations: (not relocatable) Version : 2.6 Vendor: Koji Release : 3 Build Date: Št 24. máj 2007, 13:23:26 CEST Install Date: St 30. máj 2007, 11:06:09 CEST Build Host: xenbuilder2.fedora.redhat.com Group : System Environment/Libraries Source RPM: glibc-2.6-3.src.rpm Size : 12868833 License: LGPL Signature : DSA/SHA1, Št 24. máj 2007, 20:29:03 CEST, Key ID b44269d04f2a6fd2 Packager : Koji Summary : The GNU libc libraries.
If it is useful, it shows some 4GB seg fixup lines before "Red Hat nash" line. Nash is started always, also if "init=/bin/bash" line is present.
LD_SHOW_AUXV=1 LD_DEBUG=all /bin/echo [formerly suggested by Jakub Jelinek] should show the interesting info; if you are able to run it there at all.
(In reply to comment #14) > If it is useful, it shows some 4GB seg fixup lines before "Red Hat nash" line. > Nash is started always, also if "init=/bin/bash" line is present. > I think we found it. :) The libc being included on the initrd may contain the wrong libc library. Could you attach your 2.6.20-2925.11.fc7xen initrd file to this bug?
Too late. :( /sbin/new-kernel-pkg --package kernel-xen --mkinitrd --depmod --install --multiboot=/boot/xen.gz-2.6.20-2925.11.fc7 2.6.20-2925.11.fc7xen overwrote it, but solved my problem with booting. But xend is still not running. :( Is it a Xen package bug?
(In reply to comment #17) > Too late. :( > > /sbin/new-kernel-pkg --package kernel-xen --mkinitrd --depmod --install > --multiboot=/boot/xen.gz-2.6.20-2925.11.fc7 2.6.20-2925.11.fc7xen > > overwrote it, but solved my problem with booting. No problem. At least we know it was a initrd problem. I will investigate how mkinitrd works regarding nosegneg libraries, and open a bug if needed. > > But xend is still not running. :( Is it a Xen package bug? I would ask you to open a different bug report, for this problem.
kernel-xen-2.6-2.6.20-2925.11.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
Bug #244730 was opened for the initrd problem. Jan, which kernel you were running when you ran /sbin/new-kernel-pkg?
2.6.21-1.3228_1.fc7.cubbi_suspend2 I am using unofficial suspend2 kernels from Matthias Hensler for non Xen environment. I am using Xen kernels only if I want to test virtualization, because Xen kernels does not have ACPI and other CPU freq. scalling and eats more battery power.
Could you attach your 2.6.20-2925.11.fc7xen initrd image? I want to check if it included the right libraries somehow, or the initrd still doesn't have the nosegneg libraries included (that is what I expect, by looking at mkinitrd source). Could you check what is the version of your mkinitrd package, also?
Created attachment 157352 [details] required initrd file
OK, my current (working) initrd image attached. Old (non working one) has been replaced and I have no copy. [root@note ~]# rpm -qi mkinitrd Name : mkinitrd Relocations: (not relocatable) Version : 6.0.9 Vendor: Fedora Project Release : 7.1 Build Date: Ut 12. jún 2007, 00:20:24 CEST Install Date: Št 14. jún 2007, 06:38:48 CEST Build Host: xenbuilder2.fedora.redhat.com Group : System Environment/Base Source RPM: mkinitrd-6.0.9-7.1.src.rpm Size : 95958 License: GPL Signature : DSA/SHA1, Ut 12. jún 2007, 21:16:59 CEST, Key ID da84cbd430c9ecf8 Packager : Fedora Project Summary : Creates an initial ramdisk image for preloading modules.