reopen 460331 tags 460331 help thankyou I've BCC'ed you on this email and its gone to the Debian BTS as it does explain the underlying bug quite well. Replies will go there too, I think.
On Mon, Jan 19, 2009 at 12:10:18PM +1100, Tom wrote: > old_Hertz_hack() is summing up FOUR jiffy values. That matches what > Kernel 2.4 did. Kernel 2.6 has SEVEN jiffy values, and if I add them up > manually the problem goes away. That's good! > old_Hertz_hack() is only called from init_libproc on kernels <= 2.4.0. > So on 2.6 kernels old_Hertz_hack() SHOULDN'T BE RUNNING AT ALL and that > looks to be the real bug. old_Hertz_hack() shouldn't be patched (to 2.6 > with 7 parameters) as it is only used for 2.4 kernels as per: Actually you're not correct there, it could be a 2.3 kernel or the note not found, but.. > If the "find_elf_note()" call failed it would be printing the ""2.4+ > kernel w/o ELF notes?" warning as well as the "Unknown HZ value!". you're dead right here. Why isn't it complaining? > Probably because "linux_version_code" isn't valid or set. That is set from: That's exactly the problem. > static void init_libproc(void) __attribute__((constructor)); > static void init_Linux_version(void) __attribute__((constructor)); > > are "magically" called on library startup, and obviously > init_Linux_version() had better be called to set linux_version_code > before init_libproc() is being called to use the result. > > I can't see any guarantee of this in the code. Nothing in any calling > order (there isn't one) and nothing I can find in the Makefile. That may > be the real problem here. Which is still there. In fact depending on what you are using, it is different. On a i386: (gdb) run Starting program: /home/csmall/debian/procps/procps-3.2.7.o/ps/ps Breakpoint 2, init_Linux_version () at proc/version.c:39 39 int x = 0, y = 0, z = 0; /* cleared in case sscanf() < 3 */ (gdb) c Continuing. Breakpoint 1, init_libproc () at proc/sysinfo.c:211 211 have_privs = check_for_privs(); On an Armel (agricola): (gdb) run Starting program: /home/csmall/procps-3.2.7/ps/ps Breakpoint 1, init_libproc () at proc/sysinfo.c:211 211 have_privs = check_for_privs(); (gdb) c Continuing. Breakpoint 2, init_Linux_version () at proc/version.c:41 41 if (uname(&uts) == -1) /* failure implies impending death */ (gdb) So! the million dollar question, is the code wrong or is GCC on an Armel wrong? Is there supposed to be an order here? It seems to be consistently correct for the i386. Setting the priority will fix it, I'm just not sure if the real problem is a GCC bug on the Armel. I wish the GCC documentation was written a little clearer. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
