Olaf Hering wrote:
Upcoming glibc header files have no visible definition of HZ anymore.
A
glibc macro exist to query the current tick rate. This macro will likely
work for all other apps, Unfortunately crash wants to know the HZ value
of the crashed kernel.
My patch makes the assumption that the dump file is analyzed on a system
similar to the crashed one. I dont know how accurate that is.
If I read the source right, HZ is currently forced to be 1000 which is
not true either. Newer kernels can be configured for 100, 250 and 1000.
Ideally, the core file exports HZ in some way. I see cfq_slice_async is
used to get the HZ value in task_init().
Hi Olaf,
Ok, what I'm doing is using Troy's IKCONFIG-read functionality to
get CONFIG_HZ if it's available -- and that gets done before any
of the machdep_init() calls. If that fails (i.e., machdep->hz is still 0),
then all of the processor types will initialize machdep->hz in
the same way that they do now. However, if HZ is not defined,
I've added this to defs.h:
#ifndef HZ
#define HZ sysconf(_SC_CLK_TCK)
#endif
So I believe this addresses all of our concerns for now.
Dave