Re: [patch 11/13] s390: instruction processing damage handling.

[Martin Schwidefsky <schwidefsky@de.ibm.com>]

On Fri, 2006-04-28 at 14:43 +0100, Paulo Marques wrote:
> >>>>+++ linux-2.6-patched/drivers/s390/s390mach.c	2006-04-24 16:47:28.000000000 +0200
> >>>...
> >>>>+#define MAX_IPD_TIME	(5 * 60 * 100 * 1000) /* 5 minutes */
>                                  ^^^^^^^^^^^^^^^^^^^^
> 				Expression A
> 
> >>>I'm no s390 expert, but shouldn't the above use something like HZ?
> >>
> >>Using HZ here feels just wrong to me. MAX_IPD_TIME has nothing to do with the
> >>timer frequency. In this case it's used to tell if there were 30 machine
> >>checks within the last 5 minutes (in a usec granularity). It's just by
> >>accident that this could be expressed using HZ.
> >>(5 * 60 * USEC_PER_SEC) would probably look better...
>    ^^^^^^^^^^^^^^^^^^^^^^^
>    Expression B
> 
> I'm no s390 expert either, but just wanted to point out that expression 
> B is 10 times larger than expression A, so something's fishy here.

Indeed, 5*60*100*1000 is wrong. That should be 5*60*1000*1000. This must
have been the week of stupid bugs.. thanks for spotting this.

> > Using HZ would be wrong. The check that uses MAX_IPD_TIME compares it
> > against the result of a get_clock() call. That uses the TOD Clock
> > directly, there is no dependency on HZ.
> 
> Looking at include/asm-s390/timex.h:
> 
> #define CLOCK_TICK_RATE	1193180 /* Underlying HZ */
> 
> makes me wonder if this should be:
> 
> #define MAX_IPD_TIME	(5 * 60 * CLOCK_TICK_RATE) /* 5 minutes */

No. The CLOCK_TICK_RATE is a really strange beast. It sole purpose is to
satisfy the calculations in include/linux/jiffies.h. The value itself
has no meaning in regard to the TOD clock. 5*60*CLOCK_TICK_RATE
evaluates to about 358 seconds. Not what we want.

-- 
blue skies,
  Martin.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

"Reality continues to ruin my life." - Calvin.