Re: [PATCH] bogoRe: [PATCH] bogo-resource-management for 2.2.15 bios32.c (Miata+SRM+IDE fix)

From: Michal Jaegermann (michal@ellpspace.math.ualberta.ca)
Date: Fri May 12 2000 - 15:06:30 EST


David Huggins-Daines wrote:
>
> Michal Jaegermann <michal@ellpspace.math.ualberta.ca> writes:
>
> > Nothing exciting, I am afraid. An attempt to
> > boot got stuck on "Calibrating delay loop... " with a power switch as
> > the only option out.
>
> Hm, well, I doubt that it's the bios32.c changes that cause that
> problem, since the PCI bus layout happens well after that.

No, it is not bios32. I know now more. The problem turned out to be,
as expected :-), in changes from arch/alpha/kernel/time.c.

If hwrpb->cycle_freq is 0, and it is in UX case, then ppm_error
calculation divides by zero and I was ending up with a pretty
small error of 0 (why not? it can be anything :-). As a result
cycle_freq was left at 0 and a calibrating loop was stuck.

An included modified patch to time.c from 2.2.15 sets ppp_error in
such case above a cutoff value of 1000. This restores an old
behaviour and UX boots with the following messages:

..........................
... Trust DeskStation firmware!
HWRPB cycle frequency (0) seems inaccurate -
                 using the measured value of 599935302 Hz
Console: colour VGA+ 80x25
Calibrating delay loop... 597.69 BogoMIPS
..........................

Comments? I do not know which other boards will be caught in the
same trap.

  Michal
  michal@harddata.com

--- linux-2.2.15/arch/alpha/kernel/time.c.orig Thu May 11 19:07:16 2000
+++ linux-2.2.15/arch/alpha/kernel/time.c Fri May 12 13:30:40 2000
@@ -237,7 +237,8 @@
 {
         void (*irq_handler)(int, void *, struct pt_regs *);
         unsigned int year, mon, day, hour, min, sec, cc1, cc2;
- unsigned long cycle_freq, one_percent;
+ unsigned long cycle_freq, ppm_error = 1024UL;
+ /* force "inaccurate frequency" if cycle_freq is 0 */
         long diff;
 
         /*
@@ -262,17 +263,26 @@
                 cc1 = cc2;
         }
 
- /* If the given value is within 1% of what we calculated,
- accept it. Otherwise, use what we found. */
+ /* This code used to check for a 1% error.
+ * PWS600au reports 598802395 which is way off. (ntpd has problems.)
+ * So I tightened down the check. Hal Murray, Feb 27, 2000.
+ */
         cycle_freq = hwrpb->cycle_freq;
- one_percent = cycle_freq / 100;
- diff = cycle_freq - est_cycle_freq;
- if (diff < 0)
- diff = -diff;
- if (diff > one_percent) {
+ if (0 != cycle_freq) {
+ diff = cycle_freq - est_cycle_freq;
+ if (diff < 0)
+ diff = -diff;
+ ppm_error = (diff * 1000000L) / cycle_freq;
+ }
+#if 0
+ printk("Alpha clock init: HWRPB %lu, Measured %lu, error=%lu ppm.\n",
+ hwrpb->cycle_freq, est_cycle_freq, ppm_error);
+#endif
+ if (ppm_error > 1000) {
+ printk("HWRPB cycle frequency (%lu) seems inaccurate -"
+ " using the measured value of %lu Hz\n",
+ cycle_freq, est_cycle_freq);
                 cycle_freq = est_cycle_freq;
- printk("HWRPB cycle frequency bogus. Estimated %lu Hz\n",
- cycle_freq);
         }
         else {
                 est_cycle_freq = 0;



This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:29 EST