unknown HZ value message still appears in procps utils
Hi all,
I have noticed the unknown HZ value message still appears at boot time and
under some unpredictable circumstances when running the ps command, even after
applying the procps-3.2.8-fix_HZ_errors-1.patch (I currently use a SMP,
2.6.38.4 tickless kernel).
So after looking inside the procps code and patch, I deduced the
linux_version_code variable was not correctly valued. After starting to make my
own patch, I came across a similar issue when looking over the net (seen on
http://www.linuxquestions.org/questions/slackware-14/slackware-13-37-rc-unknown-hz-value-after-procps-upgrade-871679/).
It seems the constructor functions don't run as the package expect on recent
libgcc.
After applying it, the message definitively disappeared. The patch is attached
(another solution is to prioritize the constructor functions).
It works well since quite a while for me now, so may it be taken into account
for those who have encountered the same inconvenience. Have a look ?
Thanks for reading,
Bertrand.
Initial Package Version: 3.2.8
Description: Fixes Unknown HZ value! (##) errors in procps utils.
--- procps-3.2.8/proc/sysinfo.c 2008-03-24 05:33:43.0 +0100
+++ procps-3.2.8/proc/sysinfo.c 2011-04-05 15:52:36.0 +0200
@@ -212,6 +212,7 @@ static int check_for_privs(void){
static void init_libproc(void) __attribute__((constructor));
static void init_libproc(void){
have_privs = check_for_privs();
+ init_Linux_version();
// ought to count CPUs in /proc/stat instead of relying
// on glibc, which foolishly tries to parse /proc/cpuinfo
//
--- procps-3.2.8/proc/version.c 2003-01-29 02:11:43.0 +0100
+++ procps-3.2.8/proc/version.c 2011-04-05 15:52:36.0 +0200
@@ -33,8 +33,7 @@ void display_version(void) {
int linux_version_code;
-static void init_Linux_version(void) __attribute__((constructor));
-static void init_Linux_version(void) {
+void init_Linux_version(void) {
static struct utsname uts;
int x = 0, y = 0, z = 0; /* cleared in case sscanf() 3 */
--- procps-3.2.8/proc/version.h 2002-12-15 01:08:32.0 +0100
+++ procps-3.2.8/proc/version.h 2011-04-05 15:52:36.0 +0200
@@ -14,6 +14,7 @@
EXTERN_C_BEGIN
+extern void init_Linux_version(void);
extern void display_version(void); /* display suite version */
extern const char procps_version[];/* global buf for suite version
*/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: unknown HZ value message still appears in procps utils
Selon LANOUX Bertrand lano...@yahoo.fr: Hi all, I have noticed the unknown HZ value message still appears at boot time and under some unpredictable circumstances when running the ps command, even after applying the procps-3.2.8-fix_HZ_errors-1.patch (I currently use a SMP, 2.6.38.4 tickless kernel). So after looking inside the procps code and patch, I deduced the linux_version_code variable was not correctly valued. After starting to make my own patch, I came across a similar issue when looking over the net (seen on http://www.linuxquestions.org/questions/slackware-14/slackware-13-37-rc-unknown-hz-value-after-procps-upgrade-871679/). It seems the constructor functions don't run as the package expect on recent libgcc. After applying it, the message definitively disappeared. The patch is attached (another solution is to prioritize the constructor functions). It works well since quite a while for me now, so may it be taken into account for those who have encountered the same inconvenience. Have a look ? Thanks for reading, Bertrand. the upstream code does not use the changes in http://www.linuxfromscratch.org/patches/lfs/development/procps-3.2.8-fix_HZ_errors-1.patch only the __attribute__((constructor)) fix http://procps.cvs.sourceforge.net/viewvc/procps/procps/proc/ I was mostly ready to report too, had a diff made from cvs upstream but this disk crashed 2 days ago. Gilles -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: unknown HZ value message still appears in procps utils
You're right, the change is upstream. I've not checked in since I made my own. Consider a cvs fix may be more appropriate now. Bertrand. 2011/6/7 Gilles Espinasse g@free.fr Selon LANOUX Bertrand lano...@yahoo.fr: Hi all, I have noticed the unknown HZ value message still appears at boot time and under some unpredictable circumstances when running the ps command, even after applying the procps-3.2.8-fix_HZ_errors-1.patch (I currently use a SMP, 2.6.38.4 tickless kernel). So after looking inside the procps code and patch, I deduced the linux_version_code variable was not correctly valued. After starting to make my own patch, I came across a similar issue when looking over the net (seen on http://www.linuxquestions.org/questions/slackware-14/slackware-13-37-rc-unknown-hz-value-after-procps-upgrade-871679/ ). It seems the constructor functions don't run as the package expect on recent libgcc. After applying it, the message definitively disappeared. The patch is attached (another solution is to prioritize the constructor functions). It works well since quite a while for me now, so may it be taken into account for those who have encountered the same inconvenience. Have a look ? Thanks for reading, Bertrand. the upstream code does not use the changes in http://www.linuxfromscratch.org/patches/lfs/development/procps-3.2.8-fix_HZ_errors-1.patch only the __attribute__((constructor)) fix http://procps.cvs.sourceforge.net/viewvc/procps/procps/proc/ I was mostly ready to report too, had a diff made from cvs upstream but this disk crashed 2 days ago. Gilles -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc-2.14 issues
On Mon, 06 Jun 2011 18:14:59 -0500, DJ Lucas d...@linuxfromscratch.org wrote:
On 06/06/2011 03:07 PM, Matthew Burgess wrote:
I'd prefer for us not to use HJL's binutils
Then don't. That patch doesn't look all that invasive..no need to add
tests for local build fix, just the 3 corrected files (bottom of the
list).
Yep, right you are. The 1st 2nd hunk of the elf64-x86_64.c file needed
to be fixed up, but the attached patch now applies cleanly for me. Obviously,
I can't test it myself, so if you or Andy would be so kind, I'll get it
added to the book along with the Glibc upgrade.
Also, can you confirm that the Glibc issue mentioned by Bruce at
http://wiki.linuxfromscratch.org/lfs/ticket/2883#comment:1 hits you as well,
and we'll need to add the trivial sed to fix that too? Again, I didn't hit
this during my build.
Ta,
Matt.Submitted By:Matt Burgess matthew_at_linuxfromscratch_dot_org
Date:2011-06-07
Initial Package Version: 2.21
Upstream Status: Already in upstream patch repo
Origin: Upstream
Description: Fixes build failures in Glibc on x86_64 machines.
diff -Naur binutils-2.21.orig/bfd/elf-ifunc.c binutils-2.21/bfd/elf-ifunc.c
--- binutils-2.21.orig/bfd/elf-ifunc.c 2010-07-13 16:59:10.0 +
+++ binutils-2.21/bfd/elf-ifunc.c 2011-06-07 14:19:09.236113186 +
@@ -190,10 +190,29 @@
/* Support garbage collection against STT_GNU_IFUNC symbols. */
if (h-plt.refcount = 0 h-got.refcount = 0)
{
- h-got = htab-init_got_offset;
- h-plt = htab-init_plt_offset;
- *head = NULL;
- return TRUE;
+ /* When building shared library, we need to handle the case
+ where it is marked with regular reference, but not non-GOT
+ reference. It may happen if we didn't see STT_GNU_IFUNC
+ symbol at the time when checking relocations. */
+ bfd_size_type count = 0;
+
+ if (info-shared
+ !h-non_got_ref
+ h-ref_regular)
+ {
+ for (p = *head; p != NULL; p = p-next)
+ count += p-count;
+ if (count != 0)
+ h-non_got_ref = 1;
+ }
+
+ if (count == 0)
+ {
+ h-got = htab-init_got_offset;
+ h-plt = htab-init_plt_offset;
+ *head = NULL;
+ return TRUE;
+ }
}
/* Return and discard space for dynamic relocations against it if
diff -Naur binutils-2.21.orig/bfd/elf32-i386.c binutils-2.21/bfd/elf32-i386.c
--- binutils-2.21.orig/bfd/elf32-i386.c 2010-10-21 12:29:02.0 +
+++ binutils-2.21/bfd/elf32-i386.c 2011-06-07 14:19:12.469299499 +
@@ -1807,23 +1807,10 @@
r_symndx = ELF32_R_SYM (rel-r_info);
if (r_symndx = symtab_hdr-sh_info)
{
- struct elf_i386_link_hash_entry *eh;
- struct elf_dyn_relocs **pp;
- struct elf_dyn_relocs *p;
-
h = sym_hashes[r_symndx - symtab_hdr-sh_info];
while (h-root.type == bfd_link_hash_indirect
|| h-root.type == bfd_link_hash_warning)
h = (struct elf_link_hash_entry *) h-root.u.i.link;
- eh = (struct elf_i386_link_hash_entry *) h;
-
- for (pp = eh-dyn_relocs; (p = *pp) != NULL; pp = p-next)
- if (p-sec == sec)
- {
- /* Everything must go for SEC. */
- *pp = p-next;
- break;
- }
}
else
{
@@ -1843,6 +1830,22 @@
}
}
+ if (h)
+ {
+ struct elf_i386_link_hash_entry *eh;
+ struct elf_dyn_relocs **pp;
+ struct elf_dyn_relocs *p;
+
+ eh = (struct elf_i386_link_hash_entry *) h;
+ for (pp = eh-dyn_relocs; (p = *pp) != NULL; pp = p-next)
+ if (p-sec == sec)
+ {
+ /* Everything must go for SEC. */
+ *pp = p-next;
+ break;
+ }
+ }
+
r_type = ELF32_R_TYPE (rel-r_info);
if (! elf_i386_tls_transition (info, abfd, sec, NULL,
symtab_hdr, sym_hashes,
@@ -1883,7 +1886,8 @@
case R_386_32:
case R_386_PC32:
- if (info-shared)
+ if (info-shared
+ (h == NULL || h-type != STT_GNU_IFUNC))
break;
/* Fall through */
diff -Naur binutils-2.21.orig/bfd/elf64-x86-64.c binutils-2.21/bfd/elf64-x86-64.c
--- binutils-2.21.orig/bfd/elf64-x86-64.c 2010-10-21 12:29:02.0 +
+++ binutils-2.21/bfd/elf64-x86-64.c 2011-06-07 14:31:57.009124359 +
@@ -1645,23 +1645,10 @@
r_symndx = ELF64_R_SYM (rel-r_info);
if (r_symndx = symtab_hdr-sh_info)
{
- struct elf64_x86_64_link_hash_entry *eh;
- struct elf_dyn_relocs **pp;
- struct elf_dyn_relocs *p;
-
h = sym_hashes[r_symndx - symtab_hdr-sh_info];
while (h-root.type == bfd_link_hash_indirect
|| h-root.type == bfd_link_hash_warning)
h = (struct elf_link_hash_entry *) h-root.u.i.link;
- eh = (struct elf64_x86_64_link_hash_entry *) h;
-
- for (pp = eh-dyn_relocs; (p = *pp) != NULL; pp = p-next)
- if (p-sec == sec)
- {
- /* Everything must go for SEC. */
- *pp = p-next;
- break;
- }
}
else
{
@@ -1682,6 +1669,23 @@
}
}
+ if (h)
+ {
+ struct elf_x86_64_link_hash_entry *eh;
+ struct elf_dyn_relocs **pp;
+ struct elf_dyn_relocs *p;
+
+ eh = (struct
Re: Problem: glibc 2.14 and Linux-PAM cannot work together!
(this issue is really more relevant to the LFS development list) On Tue, Jun 7, 2011 at 5:19 PM, Joel Bion j-c...@westvi.com wrote: Has anyone had experience trying to see if Linux-PAM works with TI-RPC, and even if TI-RPC can be built in an LFS/BLFS system? I really haven't. In fact, I didn't know what TI-RPC even was until it has been brought to my attention. A quick google shows that it is Sun's more recent implementation of it's RPC, that is transfer independent (hence the name TI-RPC), supports IPv6, and other good stuff. It's home page is here: http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php and you can download it from here: lhttp://downloads.sourceforge.net/libtirpc/ibtirpc-0.2.2.tar.bz2 I really haven't built this, but once I can give it a try, I'll give it a try. -- William Immendorf The ultimate in free computing. Messages in plain text, please, no HTML. GPG key ID: 1697BE98 If it's not signed, it's not from me. -- Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- Are you a Gmail user? Please read this important notice: http://www.fsf.org/campaigns/jstrap/gmail?31450. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
svn bootscript regression
Network interface configuration used to be either a file or a directory named ifconfig.interface. With the latest lsb-compliant bootscripts, it seems that the bootscript won't accept a file and neither will ifup unless using -c. Is this intentional? -- Archaic -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscript regression
On 06/07/2011 06:20 PM, Archaic wrote: Network interface configuration used to be either a file or a directory named ifconfig.interface. With the latest lsb-compliant bootscripts, it seems that the bootscript won't accept a file and neither will ifup unless using -c. Is this intentional? It was done intentionally. I was not aware that anyone had ever used a file named ifconfig.interface and this was not documented anywhere. I removed it because it simply because it was one more test case in ifup and ifdown. I could certainly put it back. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscript regression
On Tue, Jun 7, 2011 at 4:32 PM, DJ Lucas d...@linuxfromscratch.org wrote: On 06/07/2011 06:20 PM, Archaic wrote: Network interface configuration used to be either a file or a directory named ifconfig.interface. With the latest lsb-compliant bootscripts, it seems that the bootscript won't accept a file and neither will ifup unless using -c. Is this intentional? It was done intentionally. I was not aware that anyone had ever used a file named ifconfig.interface and this was not documented anywhere. I removed it because it simply because it was one more test case in ifup and ifdown. I could certainly put it back. -- DJ Lucas Many of the configuration directories end in .d, I wonder if we should switch to ifconfig.eth0.d? -- Nathan Coulson (conathan) -- Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: unknown HZ value message still appears in procps utils
On 06/07/2011 05:42 AM, Gilles Espinasse wrote: the upstream code does not use the changes in http://www.linuxfromscratch.org/patches/lfs/development/procps-3.2.8-fix_HZ_errors-1.patch only the __attribute__((constructor)) fix http://procps.cvs.sourceforge.net/viewvc/procps/procps/proc/ Actually, LFS should probably take into consideration the the Debian/Fedora/openSUSE fork once a stable release is made. http://gitorious.org/procps Many, many more fixes in there...was some talk of procp-ng. There were a couple of interesting items in there last time I looked, but I do not recall specifics. Not really sure why gitorious was chosen over alioth for project home either...curious. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscript regression
Archaic wrote: On Tue, Jun 07, 2011 at 06:32:56PM -0500, DJ Lucas wrote: It was done intentionally. I was not aware that anyone had ever used a file named ifconfig.interface and this was not documented anywhere. I removed it because it simply because it was one more test case in ifup and ifdown. I could certainly put it back. The file feature was added because 99% of the cases you are setting up one IP for one interface. Redhat was likely an inspiration for it since it is very similar to theirs, but it has been so long ago I can't remember what exactly we were thinking. :) The directory feature is actually the corner case for specifying multiple configurations for a single interface. You are right. That's the way I remember it too. I never liked it though. A single file that is edited would be better for LFS. The system is designed so a distribution package manager can just drop in files. That's easier for a distro, but harder for a person to understand. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscript regression
On 06/07/2011 11:33 PM, Bruce Dubbs wrote: You are right. That's the way I remember it too. I never liked it though. A single file that is edited would be better for LFS. The system is designed so a distribution package manager can just drop in files. That's easier for a distro, but harder for a person to understand. It was much easier for BLFS too! BTW, aren't we a distro yet? ;-) I'll add the functionality back in this weekend. I'm also not going to get the other changes in until tomorrow night as my new directory server has been a little bit more of a PITA than anticipated. I was having a bit of difficulty in getting my custom attributes to play nicely, but it is all resolved now, or at least I hope it is. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscript regression
DJ Lucas wrote: On 06/07/2011 11:33 PM, Bruce Dubbs wrote: You are right. That's the way I remember it too. I never liked it though. A single file that is edited would be better for LFS. The system is designed so a distribution package manager can just drop in files. That's easier for a distro, but harder for a person to understand. It was much easier for BLFS too! BTW, aren't we a distro yet? ;-) Only if you download the sources from us. That's not the default. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
