From: matt m. <ma...@cs...> - 2003-06-10 21:01:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 lars- you know.. my problem was that i've not heard of user-mode linux before.. i thought you were talking about the unified modeling language. :) we've had problems getting the cpu speed on amd chips in the past for the very same reason. if you have a patch to workaround the problem, can you submit it to the ganglia-developers list? if not, giving the developers the cpuinfo file will at least give us a shot at supporting uml. we should at minimum be checking the return values. sorry for the hassle. - -matt Today, Lars Kellogg-Stedman wrote forth saying... > From: Lars Kellogg-Stedman <la...@de...> > To: matt massie <ma...@cs...> > Cc: "gan...@li..." > <gan...@li...> > Date: Tue, 10 Jun 2003 16:45:29 -0400 (EDT) > Subject: Re: [Ganglia-developers] Problems with cpu_speed_func() > > > can you give a little more details about how ganglia is failing? the left > > thing to do is for us to try and fix the cpu speed function to not crash. > > I think you'll find most of your questions answered in my first email, but > I'll take another shot. > > I'm running UML (user mode linux), with a minimal installation (e.g., > busybox + a few misc. utils and the LAM MPI library). cpu_speed_func() is > failing because it calls strstr() and strchr() but doesn't check the return > values. > > Under UML, /proc/cpuinfo does not contain the same information as normal > i386 Linux. It looks something like this: > > processor : 0 > vendor_id : User Mode Linux > model name : UML > mode : tt > host : Linux wolery 2.4.9-34 #1 Sat Jun 1 06:25:16 EDT 2002 > i686 > bogomips : 817.20 > > When the code is compiled, __i386__ is defined -- because UML binaries are, > at least in this instance, i386 binaries. Gmond attempts to do this: > > p = strstr(p, "cpu MHz"); > p = strchr(p, ':'); > > The first call to strstr() fails, returning a NULL pointer. The second > call to strchr() attempts to access a NULL pointer, thus causing a > segfault. > > My proposal was to add error checking in cpu_speed_func() so that it looks > like this: > > p = proc_cpuinfo; > p = strstr( p, "cpu MHz" ); > if (! p) return val; // check strstr() return value. > > p = strchr( p, ':' ); > if (! p) return val; // check strchr() return value. > > And so forth for the other processor types. > > My alternate proposal was to allow the user to specify a return value for > cpu_speed_func() in gmond.conf that would be used in place of the automatic > detection code. This would require a little more work, but might be a > better solution. > > -- Lars > > > lars- > > > > what cpu(s) are you running? > > what os? > > what does you /proc/cpuinfo look like (i guess you are running linux)? > > do you have any ideas how the current function is failing to parse it? > > > > sorry there are more questions here than answers. > > - -matt > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+5kcvVmIXr0CKtmERAgleAJ9kcffNu5OP0GHDDmpo10i5NaxPvACfWszO WLcpphBrHKrBZqw4KTqU0Rs= =WWD1 -----END PGP SIGNATURE----- |