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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
