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

Martin Schwidefsky
2006-04-28T14:53:25Z

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.